Avoir une machine vous permettant de faire du développement sur le cloud à laquelle vous pouvez accéder de n’importe quel device (pc, tablette, …) , de n’importe où (tant que vous avez une connexion internet), peut s’avérer intéressant pour différentes raisons: facilité, accessibilité, stockage, puissance, …. C’est d’autant plus vrai lorsque vous souhaitez faire du développement mobile UWP ou Xamarin (d’ailleurs on dit Xamarin[ə] et pas Xamar1 ! Si si je vous promet… ).

Enfin bref, le développement mobile est gourmand en ressources… Il faut un PC robuste pour que Visual Studio ne peine pas trop à afficher les designer XAML, pour faire de la compilation .Net native ou de la « transpilation » Xamarin. Autre point, l’utilisation des émulateurs et simulateurs est un gouffre à mémoire vive…

Le problème jusqu’à peu est qu’il n’était pas possible d’activer Hyper-V sur les machines virtuelles Azure. Du coup impossible de tester les applications UWP sur Windows 10 mobile, les émulateurs reposant dessus. Impossible aussi, d’utiliser les excellents émulateurs Android de Visual Studio… C’est désormais possible grâce à la Nested Virtualization annoncée le mois dernier !

Let’s Go !

• Création de la VM dans Azure

La possibilité de créer une VM avec la bonne configuration (Dv3, Ev3) gérant la Nested Virtualization est limitée à certains OS de machines virtuelles (Windows Server 2016 ou Windows 10) pour certaines régions (disponible en West Europe )…

Dans mon cas, j’ai créé une machine sous Windows 10 grâce au wizard Azure habituel : Virtual Machines -> Add -> Compute -> Create

Le nombre important de terminaux mobiles rend le développement et la validation d’une application mobile très complexe. En effet, il parait utopique pour un développeur ou même pour une grande boite de certifier que son application sera 100% fonctionnelle sur tous les téléphones et tablettes de différentes résolutions, versions d’OS, performances, configurations, etc …

Tests UI ?

Tests unitaires, tests d’intégration, … Différentes stratégies de test tentent de valider le bon fonctionnement d’une application lors des phases de développement et de maintenance (tests de non régression notamment).

Un utilisateur qui télécharge une application mobile, qui se retrouve avec une application qui ne s’affiche pas ou mal, abandonnera rapidement et laissera dans le pire des cas une mauvaise appréciation sur le Store… Ce qui découragera les futures personnes intéressées par votre application.

L’idée des « Tests UI » est de faire des tests de surface sur les différents écrans de votre application sur le plus possible de configurations compatibles afin d’éviter ce phénomène…

Dans cette démonstration, j’ai choisi d’utiliser Xamarin Tests UI pour tester mon application.

A noter que ce framework d’écriture de tests ne se limite pas à Xamarin et permet de tester toutes les applications mobiles Android et iOs (natives, Cross-plateformes, Cross-plateformes Web, …).

Xamarin Test UI

La création d’un projet « UI Test App » via Visual Studio 2015/2017 est accessible via la section Cross-Platform :

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.

Contexte

La librairie BookStore.Forms est notre couche de présentation Cross-Platformes respectant notamment le pattern MVVM.

On y trouve différents namespaces détaillés ci-dessous.

Contexte

L’assembly BookStore.Business est une dll de type Portable Class Library (l’une des solutions plébiscitées pour partager du code Cross-plateforme).

On y trouve différents namespaces détaillés ci-dessous.

Namespaces Providers, DAL

Ce namespace contient des classes à l’image de BookProvider qui servent d’intermédiaire entre le « Front » de l’application et la couche d’accès aux données/la source de données.

++ Ajouter le code métier de votre application à cet endroit.

– Ne pas dupliquer le code métier. Utiliser des méthodes privées chargées de mutualiser ces règles : ValidateBook partagée entre AddBook et UpdateBook.

– Ne pas dupliquer les traitements entre les appels de méthodes via l’utilisation des champs privés en tirant pleinement profit des concepts de la POO : méthode d’initialisation si nécessaire à ne jouer qu’une fois, gestion d’état, cache…

?? Ne pas nécessairement compléxifier votre architecture en créant des librairies métiers de plus bas niveau ou couches d’accès aux données isolées si la complexité de votre application ne le justifie pas. Beaucoup d’applications mobiles se contentent d’appeler des Api Web…

++ Abstraire la couche d’accès aux données afin que les consommateurs puissent simuler les dépendances fortes pour des besoins de tests automatisés.

Contexte

Le but de cet ensemble de billets est de vous présenter le type d’architecture applicative type que je mets en place sur des projets mobiles cross-plateformes Xamarin Forms toutefois la plupart des principes s’appliquent aussi de façon plus large aux applications XAML « classiques » (WPF, WinRT, UWP, …) à base de MVVM et d’autres principes plus généralement à tous types d’applications .NET.

Comme toujours, il n’y a pas de vérités absolues ! L’idée est de partager avec vous ce que je considère être de bonnes pratiques basées sur diverses littératures et acquises au fur et à mesure de mes expériences (références en fin d’article).

Partons sur un cas classique : Une application mobile simple permettant de lister des livres et de les ajouter à un panier.

Voici un schéma détaillé non exhaustif des différents Assemblies=>Namespaces=>Classes qui définissent cette application fictive :

Afin de vous expliquer mes choix, je vais au fil de ces billets vous introduire chaque partie. De plus, pour chacune d’entre-elles : je partagerai avec-vous quelques bonnes pratiques, mauvaises pratiques et pratiques à considérer en respectant le formalisme suivant :

++ {Description bonne pratique}

– {Description mauvaise pratique}

?? {Description pratique à considérer}