Xamarin - Native & Forms

Currently a place-holder issue for commits / branches and discussion about what adding support for the new platforms will look like.

All platforms

• Configure nuget packages
• Caliburn.Micro.Platform.Mobile needs xml and build dir docs
• Xml docs
• It looks like we’ll need to introduce a third assembly for shared platform types, breaking change for the ABI. Should we update all projects including ones that shouldn’t be affected such as WPF and SL5? We can’t have a PCL that covers .NET 4.0 and SL5 so may leave them as it.
• Website documentation
• More samples

Xamarin.iOS

• Implement navigation service.
• Does the view model locator conventions make sense with the current bugs in the storyboard editor?
• Determine what should be in the extensions project.

Xamarin.Android

• Implement navigation service.
• Determine what should be in the extensions project.

Xamain.Forms

This is going to be interesting as it’s essentially a platform on top of a platform. Most likely we’ll treat it as a Platform assembly that’s Portable across iOS and Android. This stuff may end up in it’s own namespace so that works well with Xamarin native.

• No progammatic access to the value of x:Name, Confirmed.
• VisualElement does not have Loaded, Unloaded events. This can potentially cause some memory leaks as we can’t clean up properly.
• Doesn’t appear to be a way to check to see if a BindableProperty is bound, Confirmed. Affects Action.HasTargetSet.
• How do we structure this so we can have ViewModelLocator for both Xamarin Native & Xamarin Forms at the same time? We’re using a multi platform approach where Xamarin.Forms classes live in Caliburn.Micro.Xamarin.Forms.
• On NavigationPage.Pushed the NavigationEventArgs.Page and CurrentPage are the same, so we can’t get access to the previous page for deactivate, potentially could store our own reference. Imagine the same will be with Popped.
• NavigationPage doesn’t have the concept of a navigation parameter, makes things interesting.
• Triggers are a property on VisualElement and not an attached dependency property. This could have implications on where cm:Message.Attach could be used.
• TriggerAction<T> doesn’t inherit from BindableObject. While ActionMessage does have some dependency properties we may be able to get around them.
• Doesn’t appear that the TriggerBase passes any data to the TriggerAction via Invoke. This is very problematic as it means we won’t have ActionExecutionContext.EventArgs.
• Xamarin Forms has a custom Application Delegate, would collide with what we’ve done for Xamarin Native. Technically the CaliburnApplicationDelegate doesn’t actually need to inherit from UIApplicationDelegate but does it for completeness with the other platforms where we subclass Application. This does mean we can hack around it with just instantiating our second app delegate within the first. Crude and need a better solution for release. If we create a CaliburnApplicationDelegate that inherits from the correct Xamarin one then we would need a Caliburn.Micro.Platform.Forms.iOS assembly. Not ideal for one type. This could be ok if we start to get rid of the extensions assemblies.
• Have another look at FormsApplication is there a better way?
• Navigation Service should handle the close guards.
• Rename methods to be more consistent with the other navigation services.
• Determine what should be in the extensions project.
• How can we leverage DependencyService for those automatic registrations

[nigel-sampson]

Xamarin Forms support in 3.0.0 released.

[nigel-sampson]

I’ve contacted one of the Xamarin Forms devs a while ago about these, these were mentioned as low hanging fruit but haven’t seen any progress yet.