miércoles, 23 de noviembre de 2016

XAML support, Platform specificity and A cross-platform panacea? - Xamarin

1. XAML support

Xamarin.Forms also supports XAML (pronounced “zammel” to rhyme with “camel”), the XML-based Extensible Application Markup Language developed at Microsoft as a general-purpose markup lan-guage for instantiating and initializing objects. XAML isn’t limited to defining initial layouts of user interfaces, but historically that’s how it’s been used the most, and that’s what it’s used for in Xamarin-.Forms.

Here’s the XAML file for the program whose screenshots you’ve just seen:

<ContentPage xmlns="http://xamarin.com/schemas/2014/forms" 
<StackLayout Padding="10,0"> 
<Label Text="Hello, Xamarin.Forms!" 
HorizontalOptions="Center" /> 
<Button Text = "Click Me!" 
HorizontalOptions="Center" /> 
<Switch VerticalOptions="CenterAndExpand" 
HorizontalOptions="Center" /> 
<Slider VerticalOptions="CenterAndExpand" /> 
<ToolbarItem Text="edit" Order="Primary"> 
<OnPlatform x:TypeArguments="FileImageSource" 
WinPhone="Images/edit.png" /> 
<ToolbarItem Text="search" Order="Primary"> 
<OnPlatform x:TypeArguments="FileImageSource" 
WinPhone="Images/feature.search.png" /> 
<ToolbarItem Text="refresh" Order="Primary"> 
<OnPlatform x:TypeArguments="FileImageSource" 
WinPhone="Images/refresh.png" /> 
<ToolbarItem Text="explore" Order="Secondary" /> 
<ToolbarItem Text="discover" Order="Secondary" /> 
<ToolbarItem Text="evolve" Order="Secondary" /> 

Unless you have experience with XAML, some syntax details might be a little obscure. (Don’t worry; you’ll learn all about them later on in this book.) But even so, you can see the Label, Button, Switch, and Slider tags. In a real program, the Button, Switch, and Slider would probably have event handlers attached that would be implemented in a C# code file. Here they do not. The VerticalOp-tions and HorizontalOptions attributes assist in layout; they are discussed in the next chapter.

2. Platform specificity

In the section of that XAML file involving the ToolbarItem, you can also see a tag named OnPlat-form. This is one of several techniques in Xamarin.Forms that allow introducing some platform speci-ficity in otherwise platform-independent code or markup. It’s used here because each of the separate platforms has somewhat different image format and size requirements associated with these icons.

A similar facility exists in code with the Device class. It’s possible to determine what platform the code is running on and to choose values or objects based on the platform. For example, you can spec-ify different font sizes for each platform or run different blocks of code based on the platform. You might want to let the user manipulate a Slider to select a value in one platform but pick a number from a set of explicit values in another platform.

In some applications, deeper platform specificities might be desired. For example, suppose your ap-plication requires the GPS coordinates of the user’s phone. This is not something that Xamarin.Forms provides, so you’d need to write your own code specific to each platform to obtain this information.

The DependencyService class provides a way to do this in a structured manner. You define an in-terface with the methods you need (for example, IGetCurrentLocation) and then implement that interface with a class in each of the platform projects. You can then call the methods in that interface from the Xamarin.Forms project almost as easily as if it were part of the API.

Each of the standard Xamarin.Forms visual objects—such as Label, Button, Switch, and Slider—are supported by a renderer class in the various Xamarin.Forms.Platform libraries. Each renderer class implements the platform-specific object that maps to the Xamarin.Forms object.

You can create your own custom visual objects with your own custom renderers. The custom visual object goes in the common code project, and the custom renderers go in the individual platform pro-jects. To make it a bit easier, generally you’ll want to derive from an existing class. Within the individual Xamarin.Forms platform libraries, all the corresponding renderers are public classes, and you can derive from them as well.

Xamarin.Forms allows you to be as platform independent or as platform specific as you need to be. Xamarin.Forms doesn’t replace Xamarin.iOS and Xamarin.Android; rather, it integrates with them.

3. A cross-platform panacea?

For the most part, Xamarin.Forms defines its abstractions with a focus on areas of the mobile user in-terface that are common to the iOS, Android, and Windows Runtime APIs. These Xamarin.Forms visual objects are mapped to platform-specific objects, but Xamarin.Forms has tended to avoid implementing anything that is unique to a particular platform.

For this reason, despite the enormous help that Xamarin.Forms can offer in creating platform- independent applications, it is not a complete replacement for native API programming. If your appli-cation relies heavily on native API features such as particular types of controls or widgets, then you might want to stick with Xamarin.iOS, Xamarin.Android, and the native Windows Phone API.

You’ll probably also want to stick with the native APIs for applications that require vector graphics or complex touch interaction. The current version of Xamarin.Forms is not quite ready for these scenarios.

On the other hand, Xamarin.Forms is great for prototyping or making a quick proof-of-concept ap-plication. And after you’ve done that, you might just find that you can continue using Xamarin.Forms features to build the entire application. Xamarin.Forms is ideal for line-of-business applications.

Even if you begin building an application with Xamarin.Forms and then implement major parts of it with platform APIs, you’re doing so within a framework that allows you to share code and that offers structured ways to make platform-specific visuals.

I hope I have helped in something. Until the next opportunity!



No hay comentarios:

Publicar un comentario en la entrada