id | title |
---|---|
9EF6D1BE-652F-D130-BD03-AE58FE226F14 |
MonoTouch 5.3 |
Many developers creating multi-threaded applications and using Grand Central Dispatch have historically called methods on the UI thread from a background thread accidentally corrupting the state of UIKit.
This leads to strange behavior in the best case and to hard to track down crashes in the worst case.
MonoTouch will now check calls made to UIKit APIs that are not thread safe are only performed from the main thread. This will help developer identify parts of their code that should be using BeginInvokeOnMainThread.
The check is only performed on debug builds and is stripped out from release binaries. This behavior can be changed by using the --force-thread-check and --disable-thread-check to mtouch.
You can alter the behavior at runtime for debug builds by setting the UIApplication.CheckForIllegalCrossThreadCalls which defaults to true.
You can now pass parameters to applications by adding the parameters in the Run/General section in the project preferences as well as setting environment variables. You can use this to set environment variables in your application as well, in particular you can use this to control the behavior of the Mono runtime by using the options documented in the mono manual page.
This release comes with a complete binding to the CoreMIDI APIs on iOS and MacOS X.
The API now allows a delegate that will be invoked upon a match to be passed directly in the constructor instead of using the AddTarget method later or using selectors/objects.
The linker is now able to rewrite the IL of the bindings libraries, including it’s own, to remove extraneous checks for Runtime.Arch and calls to UIApplication.EnsureUIThread (see Cross-thread UI checks) [ as well as the IsNewRefcountEnabled and MarkDirty methods.
There is now a new OpenTK-1.0 assembly which provides the OpenTK 1.0 API. The reason for this change is that the OpenTK 1.0 API is not backwards compatible with our existing OpenTK.dll. In the future we will keep OpenTK.dll for backwards compatibility, while OpenTK-1.0.dll should be used in new projects. See the API differences document for details on the actual changes.
You can review the API changes from MonoTouch 5.2.5 to MonoTouch 5.3.0 in our API differences page.
This release incorporates the same set of bug fixes that were done for MonoTouch 5.2.10.
We have improved the way that our generated code accesses Mono's built-in functionality. This allows the native linker to eliminate unused code and removes a level of indirection in the code. Savings can be as big as 250k with simple applications, while larger applications, which require more parts of the Mono runtime, tend to be about 100k smaller.
We continue to expand the set of LINQ operations that can be used on device.
- It is now possible to use orderby with reference types
- Join support (#3627)
- Support for Any on enumerations (#3735)
GLKViewController now exposes an "Update" method that is invoked to update the display. This allows GLKit code to be smaller and not require a GLKViewControllerDelegate implementation to exist.
Added CVOpenGLTextureCache support that allows binding CoreVideo pixel buffers to OpenGL textures, see the samples in the monotouch-5.4 branch:
https://github.com/xamarin/monotouch-samples/tree/monotouch-5.4
For example the GLCameraRipple
https://github.com/xamarin/monotouch-samples/tree/monotouch-5.4/GLCameraRipple
MonoTouch will now use the iOS CommonCrypto libraries to provide some of the functionality exposed by its APIs. This replaces our managed implementations with the native versions. It is now used for for digest (hash) and symmetric ciphers, leveraging the hardware acceleration for SHA-1 and AES under the right circumstances.
The effect of the use of CommonCrypto to replace the managed implementation reduced the size of the generated binaries.
Our benchmarking application size compiled with LLVM, ARMv7 and in Release
mode is reduced by 99.5KB due to smaller mscorlib.dll
, System.Core.dll
and Mono.Security.dll
assemblies.
The removal of some PRNG internal calls also reduce the application size. With all other 5.3.x changes the application is 219KB smaller (compared to the stable version of MonoTouch, 5.2.11) even considering the additional code required for the new specialized trampolines.
The performance gains from MonoTouch 5.3.2 and 5.3.3 start at 2.1x and go up to to 35.4x (the later likely unattainable in real life, an upcoming blog post will discuss the topic).
We now use specialized Objective-C to C# bridges instead of the previous generics trampolines.
This lead to a significant speed increase when going from Objective-C to Managed code (2-4x speedup, depending on the number and type of arguments to the method).
The tradeoff is that the executable size is somewhat bigger, but this depends significantly on the application type. For reference, this change added 49k to the size to TweetStation.
If you find a bug and need to disable the new trampolines, add --noregistrar
to the additional mtouch
arguments and file a bug.
Console (Out and Error) output is now remapped to NSLog
Faster string marshaling: We no longer create temporary objects when passing strings from C# to Objective-C, increasing the speed to pass strings up to 13 times.
Touch.Unit now loads the test suites asynchronously - allowing larger test suites on devices (i.e. the iOS watchdog won’t interrupt their loading)
It’s now possible to use NSUrlProtocol
to register custom url
protocols. A sample has been created to show how ( ImageProtocol).
Properties [Export]ed can now be animated by CoreAnimation. A sample has been added.
The linker will now optimize the IsDirectBinding checks, from generated bindings when a type is never subclassed in the application.
This removes a lot of checks/branch code (biggest gain) and it also reduce the size of the executable a bit (e.g. 22 KB for TweetStation).
A new --xml
options allow developers to provide their own
descriptors to be preserved. This can include types and methods inside the SDK
assemblies.
MonoTouch now exposes a nested class "Notifications" that allows developers to add observers to iOS notifications using strong types. The strongly typed "AddObserver" method allows developers to take the guesswork out and reduce their trips to the documentation. With strongly typed notifications the parameters and their types are available to you from the IDE. This is how they work:
Calling Dispose()
on a notification token will now unregister
the notification.
Examples:
//
// Lambda style
//
// listening
notification = UIKeyboard.Notifications.ObserveObserveWillShow ((sender, args) => {
/* Access strongly typed args */
Console.WriteLine ("Notification: {0}", args.Notification);
Console.WriteLine ("FrameBegin", args.FrameBegin);
Console.WriteLine ("FrameEnd", args.FrameEnd);
Console.WriteLine ("AnimationDuration", args.AnimationDuration);
Console.WriteLine ("AnimationCurve", args.AnimationCurve);
});
// To stop listening:
notification.Dispose ();
//
//Method style
//
NSObject notification;
void Callback (object sender, ObserveWillShow args)
{
// Access strongly typed args
Console.WriteLine ("Notification: {0}", args.Notification);
Console.WriteLine ("FrameBegin", args.FrameBegin);
Console.WriteLine ("FrameEnd", args.FrameEnd);
Console.WriteLine ("AnimationDuration", args.AnimationDuration);
Console.WriteLine ("AnimationCurve", args.AnimationCurve);
}
void Setup ()
{
notification = UIKeyboard.Notifications.ObserveObserveWillShow (Callback);
}
void Teardown ()
{
notification.Dispose ();
}
The MidiObject class no longer exposes all of the properties that are common to all of its subclasses. Instead specific properties are exposed on each kind of MidiObject, this makes the API easier to navigate from the IDE, and eliminates ugly displays in the debugger.
See our new CoreMidiSample
For a detailed list of the changes in the API, see our detailed API changes from 5.3.2 to 5.3.3.
For a detailed list of the changes in the API, see our detailed API changes from 5.3.3 to 5.3.4.
The following bugs have been fixed:
- #3668
- #3969
- #4587
- #4677
- #4678
- #4695
- #4715
- #4717
- #4736
- #4784
- #4792
- #4811
- #4834
- #4854
- #4856
- #4871
- #4871
- #4929
- #4972
- #4988
- #4990
- #4997
- #5005
- #5036
- #5036
- #5053
- #5058
- #5078
- #5093
- #5160
- #992
- New methods for AVCaptureDevice
- Added ipv6 support for NetworkReachability
- NetworkReachability can now use IP address pairs
- New strongly typed accessors for MPMediaItem
- Improved linker error messages
- Registrar handles more types
- Extended the set of thread-safe UIKit methods based on new data from Apple:
- UISlider has new appearance properties, based on new data from Apple
- Allow null dictionary on MKPlacemark ctor and add Obsolete on (removed since 3.2) media player properties
- Removed some constructors that would lead to crashes (use factory methods)
- Lighter System.Uri parser that no longer uses regular expressions to parse expressions, making it faster and reducing the amount of code that needs to be imported from System,
- Bring a long standing Regex bug fix
- Improved web service interop for dates and times
- Support for newer iOS SDKs (no new APIs on this release)
- Support to turn unmanaged function pointers into managed delegates using
Marshal.GetDelegateForFunctionPointer (ptrToFunc, typeof
(SomeDelegate)).
For this to work with Mono's static compiler, developers must decorate the delegate type with the MonoNativeFunctionWrapper attribute, like this:[MonoNativeFunctionWrapper] public delegate int SimpleDelegate (int a);
- The binding generator now supports delegates in delegates. This allows
callbacks invoked by Objective-C to pass callbacks to C# that you can then
invoke.
For example:delegate void PostFunc (int value); delegate void Filter (PostFunc func)
[BaseType (typeof (NSObject)] interface MyMapReduce { [Export ("callbackTakesCallback:")] void Run (Filter filterFunc); }
- 3444 - JIT compile exception when using ConcurrentDictionary in SplitOrderedList ctor()
- 5231 - class_addProperty doesn't exist in iOS4
- 5272 - Monotouch does not correctly link referenced DLLs
- 5311 - LockRecursionException is defined in mscorlib and System.Core
- 5314 - MonoTouch.Dialog.StyledStringElement throws if cell has no imageview
- 5337 - INotifyPropertyChanging and PropertyChangingEventArgs not included in MonoTouch
- 5410 - AudioUnit Dispose method throws EntryPointNotFound exception
- 5543 - Linker fails with XmlElement attribute on generic type
- 5543 - Linker fails with XmlElement attribute on generic type
- 5546 - ServicePointManager.ServerCertificateValidationCallback does not validate certificate chain in MonoTouch
- 5567 - Enum.ToString behaves incorrectly in corner cases
- 5581 - UIDatePicker's MaximumDate/MinimumDate should allow null set
- 5610 - ADInterstitialAdDelegate - wrong Export
- 5615 - NSFileCoordinatorWritingOptions missing ForReplacing
- 5625 - Https Get results in System.NullReferenceException: Object reference not set to an instance of an object at Mono.Security.X509.X509Certificate.Parse (System.Byte[] data)
- 5638 - UITableViewSource::SectionIndexTitles trampoline call results in _sigtramp signalled.
- 5646 - UIAlertView showing params entry two times
- 5696 - App hangs on resume when calling CLLocationManager.StartMonitoringSignificantLocationChanges
- 5714 - Long compile times for very large methods when using LLVM.
- 5755 - Can't increase trampolines
- 5755 - Can't increase trampolines
- 5767 - Typo in CGPath.AddElipseInRect(...)
- 5768 - InvalidCastException when retrieving a boolean value from sqlite reader
- 5776 - AMDeviceTransferApplication returned: 0x0 (kAMDSuccess).
- 5805 - CoreMotion bug in StartDeviceMotionUpdates
- 5808 - CBCentralManager.ScanForPeripherals(null, null) not working as expected
- 5898 - UIButton -setTitle:forState: null ref exception
- 5903 - UITableView Source property is always null
- 6086 - GKSession constructor should allow null for sessionID and displayName
- 6118 - [OSX] File.GetCreationTime returns last modified time instead
- 6172 - For Application 'SharedResources' and 'MonoDevelop-MonoCatalog', 'Cancel' and 'Done buttons under 'Contacts' crashes the application and throw error in application output " MonoTouch.UIKit.UIApplication.Main"
The 5.3.4 to 5.3.5 page contains the detailed API changes since the last beta release.
This version contains the same fix that prevents applications from crashing in iOS 6 that was released as part of MonoTouch 5.2.13. Details about this fix are in our blog.
The CoreBluetooth APIs have been fixed and now allow MonoTouch.CoreBluetooth.CBUUID objects to be used as UUIDs in addition to System.UUID.
UIPageViewController.SetViewController now allows null as a completion handler.
AVCaptureOutput.Connections returns a strongly typed array instead of NSObject [].
Native debug builds now contain line number information that allows existing C tools to map executable code to C# source code.
This is particularly useful when using Instruments and crashes.
MonoTouch.Dialog no longer uses the System.Web stack for its JsonElement, which drops a dependency on the entire System.Web stack and instead uses NSUrlConnection, making your binaries smaller.
The 5.3.5 to 5.3.6 page contains the detailed API changes since the last beta release.