[4/4] Architecture Cross-Plateformes Xamarin : couche plateforme

Auteur du billet de blog : Rudy Spano - Neotech Solutions

Rudy Spano

Consultant .Net
  Publié le mercredi 1 février 2017

Expert technique .Net passionné par tout ce qui est innovant en environnement Microsoft. De la mobilité, du client lourd (Xaml Applications) mais aussi une petite pointe de Web...

Contexte

 

Les couches spécifiques BookStore.Droid, BookStore.iOS, BookStore.UWP (…) fournissent du code .Net (portages de Mono) ne pouvant pas être mutualisé par Xamarin. Cette fonctionnalité avancée reste néanmoins essentielle à la pertinence de la technologie.

Dans notre exemple d’application, on trouve les différents namespaces détaillés ci-dessous.

 

Namespace Platform

Dans ce namespace se trouvent les implémentations spécifiques à chaque plateforme lorsque des solutions Cross-Plateformes n'existent pas. A noter que Xamarin propose un simple mécanisme nommé DependencyService permettant de fournir ces implémentations aux couches basses. Vous pouvez aussi passer par votre conterneur IOC. Dans notre exemple AndroidLocationProvider utilise du code spécifique Android pour récupérer la localisation de l’utilisateur.

 

?? Considérer isoler ces briques dans une assembly séparée si la compléxité et le découpage du projet le justifie.

 

Namespace Renderers

En Xamarin Forms, les renderers sont partout en interne : ils permettent de spécifier l’affichage associé d’un contrôle pour chaque plateforme. Ils sont aussi une porte ouverte à la customisation par plateforme en mode avancé car nécessitent la connaissance de chaque système à l’encontre du principe même d’application cross-plateforme. Dans notre exemple ImportantEntryRenderer permet de définir le control natif associé au Control Xamarin Forms ImportantEntry pour chaque plateforme.

 

?? Si le but est juste d’appliquer des propriétés différentes à un contrôle semblable pour chaque plateforme, songez à utiliser les propriétés OnPlatform à la place de votre renderer. Cela améliorera grandement la mutualisation => la maintenabilité de votre code.

 

Dossier Assets

Il est possible et conseillé de définir des médias cross-plateformes, cependant c’est l’emplacement prévu si certains ne concernent qu’une plateforme car spécifiques ou retravaillés pour des raisons de performance ou adaptation à la plateforme.

?? Il est souvent utile de grouper les assets dans des sous répertoires pour des raisons évidentes d’organisation.

++ Maintenez une précision et cohérence sur le nommage de vos assets.

-- Ne pas garder les assets par défaut des plateformes. Cela décrédibilise votre application et est une raison courante de refus de publication de votre application sur le Store.

 

Autres mécanismes « platform-specific »

Comme dit précédemment, il est dommage que votre application Cross-Plateformes repose sur du code natif… Malheureusement, le contexte de l’industrie du développement informatique veut qu’on ait souvent des contraintes. Il se peut que vous deviez réutiliser du code natif existant pour une plateforme car trop spécifique ou souvent trop coûteux à migrer.

Les mécanismes cités dans mon exemple peuvent ne pas suffire.

Sachez qu’il est depuis peu possible d’intégrer des contrôles natifs dans une vue Xamarin Forms. Pour plus de détails : https://blog.xamarin.com/embedding-native-controls-into-xamarin-forms/

De plus, comme vous avez pu le remarquer, nous avons accès aux différents points d’accès de notre application : App.xaml.cs pour les applications WinRT et UWP, MainActivity.cs pour Android et AppDelegate.cs pour iOS. Ils constituent avec le mécanisme de DependencyService des points d’entrée pour jouer du code natif : appel à des méthodes, lancement de tâches de fond natives, création d’éléments spécifiques à une plateforme (tuile ModernUI, AppShortcut Android, …), voir affichage d’écran natifs.

 

Conclusion générale

Dans ces 4 billets, j’ai tenté de faire un petit tour d’horizon sur les différentes problématiques que l’on peut rencontrer lorsque l’on part sur un développement à base de Xamarin Forms ou de tout autre application.

D’un point de vue général, ne sous-estimez pas le temps de conception de l’architecture d’une application. Il est nécessaire de connaitre à la fois ce qui se fait en termes de bonnes pratiques mais cela ne suffit pas du tout ! Il faut bien maitriser les enjeux techniques et le contexte du projet afin d’adapter notre solution. Mais aussi soumettre cette solution à la critique à minima avec l’équipe de développement qui devra comprendre les différents choix pour bien les respecter quoi qu’il en soit…

Quant au cross-plateformes, c’est puissant, c’est pratique, c’est rapide ? c’est économique ? mais ça n’est pas magique :( sans parler des problématiques de validation sur les différents devices qui n’est en aucun cas plus facile que lorsque l’on part sur des développement natifs.