Join Mark Smith for an in-depth discussion in this video Using platform-specific code, part of Introduction to Xamarin.Forms.
- [Instructor] In Xamarin forms, remember that each of our applications is made up from two components. Shared code, the portable class library, which holds our logic and UI definition, and the platform specific projects, which are the actual applications we will deploy to the devices and app stores. The PCL is great, because it's shared, but it has significant limitations in terms of the APIs we can use. Many platform features which make iOS, Android, and Windows phone unique are unavailable to us.
First, there's a built in API in Xamarin forms for fine tuning the UI on a per platform basis. It has two variations, Device.OnPlatform takes four delegate methods, one for each platform, and one for the default case, if you don't supply a platform specific delegate. Each parameter defaults to null. This style allows you to execute a block of code uniquely based on the platform the app is running on. So if we were on iOS, then only the iOS delegate would be executed, or if it is null then the default delegate is executed.
No result is returned from this method. The second variation is a generic Device.OnPlatform<T>, which takes three T parameters and returns a T. The three parameters correspond to iOS, Android, and Windows phone. There is no default parameter case here, we must supply all three values. This method is useful if you want to change a parameter or property based on the platform you happen to be running on. For example, we are adjusting the top of the thickness class based on the iOS platform, returning only 20 for that case.
Again, the important thing here, is we are putting this into our shared code, but making it execute a specific branch or return a specific value based on the platform we are executing on at run time. Xamarin forms exposes a few other features that most applications need. The static device class has several other useful methods for invoking platform specific functionality. You saw Device.OnPlatform just a moment ago, which lets you invoke different logic on each platform.
It also has a Device.OS and a Device.Idiom property to identify the platform and foot print. You could use these in conditional branches. The important thing to remember here is that you use this sort of logic your shared code. It does not allow for any additional platform specific APIs here, it simply lets you execute logic based on the platform and form factor of the device. Xamarin forms has support for dealing with a few very common platform specific features.
There is a Device.OpenUri to open a URI using the platform handler. For example, if you pass in an http URL, each platform will open that browser app and launch that page. The Page.DisplayAlert instance method can be used to show two button modal message box. There is also a Page.DisplayActionSheet that supports more buttons. Device.StartTimer can be used to create a timer.
Return false from the delegate to stop the timer. You can use Device.BeginInvokeOnMainThread to marshal the UI thread if you were on a background thread. This will use the appropriate platform specific method. Alternatively, you can also use the .NET SynchronizationContext. This is particularly useful for classes you are sharing with non-Xamarin forms platforms, such as ASP.NET or a desktop app. Finally, there is also support for cross platform mapping with the Xamarin.Forms.Maps component, which is an optional install.
This abstracts out the mapping support from Google, Apple, and Microsoft into a component that is cross platform.
This course was created by Xamarin University. We are honored to host this training in our library.