Azure Functions et Serverless Backend : à propos…

Azure Functions et Serverless Backend : à propos…

Serverless backend for mobile apps… Vous vous rappelez ? J’en ai parlé dans un article en Février dernier. James Montemagno discute de ces fonctionnalités dans le Xamarin Show. A cette occasion, il a invité la Program Manager en charge des fonctions Azure : Donna Malayeri. Nous avons ainsi le droit à une excellente présentation des Azure Functions permettant de créer des « backend sans serveur pour applications mobiles », ou « serverless backend for mobile app ».

 

Azure Functions, mais à quoi cela peut servir ?

Vous souhaitez créer une application mobile connectée sans avoir à développer et gérer un serveur entier ? Vous souhaitez bénéficier des API Azure telles que l’authentification, l’analyse et la reconnaissance d’image, la reconnaissance vocale, la synchronisation de base de données (serveur-mobile) ou autres ? Vous ne souhaitez pas payer avant que vos applications ne soient rentables ? Alors vous devez visionner cette vidéo !

Je n’ai pas l’habitude de relayer ce genre de contenu brut. Je préfère le tester moi même afin d’en faire un article accessible. Mais la vidéo est vraiment riche et j’ai utilisé cette technique pour le développement de l’application iOS Gotago. C’est pourquoi je recommande vraiment de se pencher sur cette technologie.

 

 

 

Alors, qu’en dites vous ?

 

Développer une application mobile iOS et Android de qualité et à moindre coût avec Xamarin et Microsoft Azure

Développer une application mobile iOS et Android de qualité et à moindre coût avec Xamarin et Microsoft Azure

J’ai écris cet article pour 123Presta dans le but de présenter Xamarin et Microsoft Azure à ses clients. J’ai le plaisir de le partager également sur mon blog. Bonne lecture 🙂

 

Aujourd’hui, créer une application mobile est presque indispensable à tout projet. Vous avez un site e-commerce ? Y associer une application mobile permettra de booster les ventes grâce à une meilleure expérience utilisateur. C’est vrai pour tous vos projets, que ce soit un site internet, un service de prestation B2B ou B2C, ou tout simplement une application mobile seule.

Seulement, développer une application mobile est complexe et peut s’avérer très coûteux. Il faut s’adapter à Android, iOS, et/ou Windows Phone, aux petits écrans ou aux tablettes. Parfois, il faut même se connecter à un serveur distant afin d’échanger des données via internet.

Il existe des dizaines de technologies pour développer des applications mobiles, chacune ayant ses avantages et ses inconvénients. Dans cet article je m’attarderai plus en détails sur une solution proposée par Microsoft. Celle-ci permet de répondre de manière très adaptée à toutes ces contraintes : Xamarin et Microsoft Azure.

 

Vous avez besoin d’une application mobile ? Il faut en créer trois !

Aujourd’hui, d’après le cabinet d’étude Kantar, plus de 73% des smartphones possédés par les français sont Android. 24% sont iOS et seulement 2.5% Windows Phone. C’est pourquoi il est important, pour tout projet d’application mobile, de viser au minimum les systèmes d’exploitation Android et iOS.

 

xamarin microsoft azure ios android

Android et iOS sont deux systèmes différents. De ce fait, le développement d’application mobile ne se fait pas avec les mêmes technologies, ni de la même manière. De plus, le design des applications sont également différents entre Android et iOS. Un utilisateur Android a l’habitude d’avoir le bouton de l’action principale de la page courante en bas à droite. Au contraire, l’utilisateur iOS a l’habitude de l’avoir en haut à droite. De même, un utilisateur Android a l’habitude de voir les onglets affichés en haut. Alors qu’ils sont affichés en bas sur iOS.

Il existe de nombreuses différences, tant sur l’emplacement des contrôles que sur les choix des couleurs et des apparences. D’ailleurs, Google et iOS ont leur propre Guidelines (Material Design pour Android contre HIG pour iOS). Et pour garantir la meilleure expérience utilisateur possible à 100% de vos utilisateurs, il faut respecter ces Guidelines. L’image suivante présente la même application, avec un design adapté à chaque plateforme :

xamarin microsoft azure ios android

 

Une application mobile ne se suffit rarement à elle seule

Une application mobile doit généralement être accompagnée par un serveur. Ce dernier va stocker des données et permettre aux applications (mobiles ou web) d’accéder et de modifier ces données. Par exemple, une application mobile « réveil matin » n’a pas besoin de serveur et d’accès internet pour fonctionner. Mais une application associée à un site e-commerce, ou à un site d’actualités aura besoin d’un serveur. En effet, c’est ce serveur qui va envoyer les articles, via internet, que l’application mobile doit afficher à l’utilisateur.

xamarin microsoft azure ios android

Résumons. Pour un projet mobile, il faut :

  • designer et développer l’application sur Android,
  • designer et développer l’application sur iOS,
  • mettre en place et développer le serveur.

Toutes ces différentes actions nécessitent des connaissances et des savoir-faire techniques différents. Elles représentent chacunes des métiers différents : designer, développeur Android, développeur iOS, ingénieur système et réseau et développeur « back-end » pour le serveur.

 

Quelles compétences et savoir-faire pour créer une application mobile ?

La technologie pour développer une application mobile native Android est le Java. Pour iOS, il s’agit de Swift. Pour le serveur, il faut des connaissances en sécurité informatique, infrastructure et matériel informatique. Il faut également connaître les bases de données et un langage de programmation tel que PHP par exemple. Lorsque vous êtes entrepreneurs, vous n’avez pas les moyens de former trois équipes disposant de toutes ces compétences. Heureusement, il existe de nombreux moyens de procéder. Je vais vous en présenter un que j’estime excellent tant pour les entrepreneurs ou PME que pour les grands groupes.

Cette technologie est appelée Xamarin. Elle permet de coder une seule fois pour avoir une application mobile native Android, iOS, et Windows Phone. Ajoutez à cela Microsoft Azure pour votre serveur et vous répondez à tous les critères. Le bonus est que vous n’utilisez qu’une seule technologie : celle de Microsoft et son langage de programmation C# .NET.

 

Xamarin : une technologie de développement unique pour vos applications mobiles

Xamarin est né du projet Mono. C’est une société américaine fondée en 2011 et qui a été rachetée par Microsoft en 2016. Ce rachat a rendu l’utilisation de Xamarin complètement gratuite, alors qu’une licence de 2000$ / an était requise auparavant. Xamarin a donc l’avantage d’être gratuit, mature, enrichi et maintenu par des équipes d’ingénieurs de pointe.

Le principe de Xamarin est de permettre de développer des applications mobiles natives avec une seule technologie et en écrivant le code une seule fois. Pour cela, l’offre de Xamarin se divise en deux principes : Xamarin, et Xamarin.Forms. Avec Xamarin, 80% du code est partagé entre les projets Android, iOS, et autre. Les 20% restant sont à produire spécifiquement pour chaque plateforme et concernent l’interface graphique de l’application. Avec Xamarin.Forms, 100% du code est partagé.

xamarin microsoft azure ios android

Choisissez Xamarin.Forms si votre application mobile ne demande pas beaucoup de personnalisation sur l’interface graphique. Généralement, ce sont les applications destinées aux professionnels, dont la valeur n’est pas dans l’effet « waouh ! » mais dans les données affichées. Au contraire, si votre application demande une personnalisation avancée de l’interface graphique, choisissez Xamarin classique. Voici un exemple d’application créée avec Xamarin.Forms : 1 seul code, 3 plateformes, 3 affichages différents et adaptés :

xamarin microsoft azure ios android

Xamarin pour des applications performantes

Avec une seule technologie et un seul code, on peut produire une application pour Android, iOS, et Window Phone. Le coût de développement et de maintenance est donc amoindri, presque divisé par trois. Et contrairement aux technologies hybrides, les applications mobiles créées avec Xamarin sont des applications natives. En effet, Ionic ou React Nativ embarquent une surcouche dans l’application mobile pour fonctionner. Quant à Xamarin, il applique sa surcouche au moment de la compilation afin de « traduire » le code Xamarin en code natif. Grâce à cela le résultat est identique qu’avec une application codée en natif. La fluidité et les performances de l’application ne sont pas impactées et sont optimales.

Xamarin comporte tout de même un inconvénient. Afin de fonctionner, les ingénieurs de Microsoft doivent faire le lien entre le code Xamarin et le code natif de chaque plateforme. Cela engendre parfois des problèmes techniques pour les développeurs. Par exemple pour des fonctionnalités encore non gérées par Xamarin mais existantes dans Android ou iOS. Toutefois, avec le temps cet inconvénient s’estompe et il est très rare de tomber dans un tel cas aujourd’hui.

 

Azure : connectez vos applications mobiles au Cloud à moindre coût

Nous venons de voir comment développer une application mobile multi-plateformes à moindre coût. Voyons maintenant comment connecter cette application à un serveur, ou au Cloud. La solution que je souhaite vous présenter consiste à utiliser Microsoft Azure. Azure est le Cloud de Microsoft. Avec Azure, vous pouvez héberger des sites web ou des bases de données. Egalement, vous pouvez accéder à des fonctionnalités pré-construites telles que l’identification d’utilisateur ou la reconnaissance vocale. Enfin, Azure permet de créer vos propres fonctionnalités répondant à votre problématique métier.

Microsoft Azure est utilisable gratuitement, et propose des services payants afin d’améliorer la puissance et les capacités des serveurs loués. C’est très pratique : pendant le développement de votre projet, vous n’avez pas de trafique, donc pas besoin de serveurs puissants. Une fois que votre projet est terminé et rencontre un succès fou, vous pouvez choisir d’augmenter la puissance des serveurs. Cela permet de rendre vos sites ou applications plus robustes face aux centaines ou milliers d’utilisations simultanées.

Xamarin optimisé pour s’interfacer avec Azure

Xamarin et Azure sont deux technologies différentes, mais appartenant à Microsoft. Grâce à cela, un développeur Xamarin peut intégrer des fonctionnalités Azure dans son application mobile en quelques clics. Et ce, sans avoir besoin d’apprendre un autre langage de programmation ! Les notifications push, l’identification d’utilisateur via plusieurs réseaux sociaux, ou encore la pagination des données pour des transferts plus rapides sont là quelques exemples de fonctionnalités qui ne coûtent plus que quelques clics à mettre en oeuvre, contre plusieurs heures de développement avec des applications natives.

Une fonctionnalité que j’apprécie tout particulièrement est la synchronisation des données entre le serveur et l’application mobile. Azure et Xamarin vous permettent de gérer très facilement le fonctionnement hors ligne des applications. Il est possible de configurer une base de données sur le serveur qui sera partiellement ou entièrement dupliquée sur l’application mobile et synchronisée de manière automatique. Cela permet à vos utilisateurs de naviguer sur l’application sans connexion internet. Tout cela, toujours en quelques clics pour votre développeur, contre des jours entiers de travail en natif.

 

Mise en oeuvre et retour d’expérience avec le projet Moovenow

L’application Moovenow, destinée au grand public, a été développée avec Xamarin classique. C’est une application Android et iOS, qui fait effet de réseau social, d’annuaire, et d’organisateur d’événements dédiés aux sportifs. L’application a été développée en interne par une start-up Grenobloise en 400 jours/homme. Le serveur n’utilise pas

Le choix s’est porté vers Xamarin classique car les interfaces graphiques devaient être très personnalisées. En effet, le design demandait des couleurs ou des formes spécifiques, et des animations. La start-up disposait de peu de moyen. C’est pourquoi il n’était pas envisageable de recruter un développeur Android et un développeur iOS pour ce projet. Il n’était pas non plus envisageable de payer la formation à un développeur pour l’une ou l’autre plateforme.

Un projet réussi grâce à Xamarin

Voici une capture d’écran de Moovenow sur iOS, et deux captures d’écran de Moovenow sur Android. On peut remarquer les interfaces graphiques complètement personnalisées pour une image de marque mise en valeur. Les applications suivent bien les guidelines Android et iOS.

    xamarin microsoft azure ios android

Le projet a été réussi, bien que le temps de développement prévu pour l’application iOS ait été dépassé. Ce retard était dû au manque de connaissance de la plateforme iOS par le développeur. La technologie est la même pour toutes les plateformes. Malgré tout, un point clef de réussite est une bonne culture générale de chaque plateforme pour le développeur.

Si c’était à refaire, il faudrait s’assurer que le client a réellement besoin d’un design élaboré justifiant l’utilisation de Xamarin au détriment de Xamarin.Forms. En effet, cela augmente tout de même de ¼ le temps de développement, donc le coût de production. Il faudrait également s’assurer de l’expérience du ou des développeurs avec les technologie Microsoft C# .NET et de leur culture générale sur chaque plateforme visée (Android, iOS, …).

 

Et vous, quels sont vos projets d’application mobile ?

 

Xamarin Android – Regrouper des markers Google Map avec le « Clustering »

Xamarin Android – Regrouper des markers Google Map avec le « Clustering »

L’idée d’écrire un article sur le Clustering de Google Map m’est venue suite à une problématique que j’ai rencontrée en développant l’application Moovenow. Moovenow, entre autre, affiche une carte Google Map répertoriant toutes les infrastructures sportives de France, toutes les associations sportives de France, ainsi que les événements sportifs organisés sur la plateforme. Cela représente potentiellement plus de 300 000 markers à afficher sur un écran de smartphone !

La problématique est double : non seulement le temps de chargement ne doit pas affecter l’utilisateur, mais surtout les informations doivent être compréhensibles par l’utilisateur ! Afficher 300 000 markers n’est pas anodin, d’autant plus que chaque marker ne représente pas le même type de donnée.

Pour répondre à cette problématique, j’ai décidé d’utiliser l’API de Google Map. Elle est accessible sur Xamarin grâce à un package Nuget.

 

Initialisation, configuration

Pour commencer, ajoutez les package Nuget Xamarin.Android.Support.Design et Xamarin.Android.Maps.Utils à votre projet Android.

Pour utiliser l’API Google Map, il vous faut créer un ID d’API Google Map : https://developers.google.com/maps/documentation/android-api/signup?hl=fr, paragraphe Obtenir une clef d’API. Ajoutez ensuite cette clef dans le manifest comme ci-dessous, à la place de [api_key_value]. Profitez-en également pour ajouter les permissions et le thème Appcompat :

Vous devrez peut être activer le Multi Dex si votre solution comprend plus de 64 000 méthodes. Cela se manifeste par une erreur « Java exit with code 2 » lors de la compilation.

 

Comment afficher une carte Google Map ?

L’API Google Map accessible via le package Nuget ajouté précédemment nous permet d’afficher très facilement une carte Google Map. Il faut simplement ajouter une vue nommée MapView à un Layout. Cette MapView est configurable à souhait, mais je ne rentrerai pas dans ces détails ici. Si cela vous intéresse, tout est très bien expliqué dans la documentation développeur. Voici le fichier AXML de l’activité qui va afficher la carte :

 

Et voici maintenant le code de cette activité :

Il n’y a plus qu’à compiler et déployer sur votre smartphone, et voici le résultat :
Google Map Android

 

Comment ajouter des markers qui se regroupent lorsqu’ils sont trop nombreux au même endroit ?

Ajouter un marker sur une carte se fait très facilement, en une seule ligne de code :

Mais ce qui nous intéresse, c’est d’ajouter de nombreux markers sur une carte. Et quand ces markers sont trop nombreux au même endroit, on veut les regrouper pour garder une carte propre et lisible. Cela s’appelle faire du « Clustering » (regroupement en français).

Pour faire cela, nous utiliserons la classe ClusterManager proposée par l’API de Google Map. Et au lieu d’ajouter des objets MarkerOptions à notre MapView, nous ajouterons des ClusterItem à notre ClusterManager. Ce dernier gérera tout seul l’affichage de marker ou de regroupement de marker.

Voici le code de la classe ClusterItem, qui doit impérativement implémenter l’interface IClusterItem :

 

Pour mettre en place le ClusterManager et y ajouter des ClusterItem, il faut retourner dans le code de notre Activité. Pour l’exemple, j’ajoute des markers en spirale en partant du centre de Grenoble, d’où les quelques lignes de code de mathématique (mais il ne faut pas prendre peur 😉 ) :

Comme je vous le disais plus haut, le ClusterManager fait tout le boulot tout seul !!

Il n’y a rien de plus à faire. Compilez, déployez sur notre téléphone, et amusez-vous à zoomer/dézoomer pour voir les markers se regrouper :

Google Map Android Clustering Markers

 

Comment personnaliser le rendu graphique des markers et markers regroupés ?

Nous sommes d’accord ! Il est impensable de garder l’affichage par défaut des markers de Google. Il faut les personnaliser pour améliorer l’image de marque de votre application. Pas d’inquiétude, cela se fait très bien et nous allons voir comment.

Pour commencer, comprenez que tous les éléments affichés dans une carte sont des images. Pour les markers simple, cela ne pause pas de problème : l’image est toujours la même. Mais pour les regroupements de markers, le texte change en fonction du nombre de marker regroupés, et là ça pause un problème ! Mais tout va bien, les ingénieurs de Google ont pensé à nous 🙂

Pour modifier le rendu visuel des regroupements de markers, nous allons créer une vue composée d’une ImageView et d’une TextView, configurer cette vue avec l’image de notre choix et le text de notre choix (ici le nombre de markers regroupés), et nous transformerons cette vue en image afin que la MapView l’affiche correctement par le biais de notre ClusterManager. Voici le code AXML :

 

Pour que notre ClusterManager utilise le rendu visuel personnalisé, nous devons créer un ClusterRenderer. C’est grâce à ce renderer que nous pourrons spécifier au ClusterManager quelle image afficher dans quel cas. Par exemple, quand il faut afficher un marker simple, nous voulons afficher l’image nommée « marker ». Et quand il faut afficher un regroupement de marker, il faut afficher l’image « marker_cluster_grouped » + le texte indiquant le nombre de marker regroupés. Tout est disponible dans mon Github si vous souhaitez récupérer les images.

Tout à l’heure je vous disais que les ingénieurs de Google avaient pensé à nous. Ils mettent à votre disposition la classe IconGenerator afin de nous faciliter la tâche. Grâce à notre IconGenerator, nous pouvons créer l’image de regroupement de marker très facilement à partir du AXML créé précédement. Je vous laisse prendre quelques minutes pour tout comprendre avec le code ci-dessous :

 

Maintenant que le ClusterRenderer est prêt, il faut configurer notre ClusterManager pour qu’il utilise ce renderer :

 

Vous pouvez maintenant admirer le fruit de votre travail ! C’est quand même plus sympa que les images par défaut n’est-ce pas ?

Google Map Android Clustering Markers

 

Comment personnaliser les InfoWindow ?

Les InfoWindows sont les petites fenêtres qui apparaissent lorsqu’un utilisateur clique sur un marker. Par défaut, ces fenêtres affichent le titre et la description associés au Marker. Vous vous rappelez ? Ils sont en paramètre de la classe ClusterItem.

En revanche, lorsqu’un utilisateur clique sur un regroupement de marker, il ne faut pas afficher d’InfoWindow. Au lieu de cela, il faut centrer la carte autour de ce point.

Comment afficher une InfoWindow par défaut ?

Voici un exemple très rapide pour illustrer mes explications précédentes. Le code ci-dessous permet au ClusterRenderer de modifier le MarkerOptions qui est sur le point d’être affiché sur la carte afin de valoriser son titre et sa description. De ce fait, lorsque l’utilisateur cliquera sur un marker, une InfoWindow apparaîtra afin d’afficher le titre et la description :

Google Map Android Clustering Markers

 

Comment afficher une InfoWindow personnalisée ?

Vous souhaitez afficher une image particulière dans votre InfoWindow ? Ou une RatingBar par exemple ? Aucun problème ! Il est possible de personnaliser l’InfoWindow avec notre propre vue basée sur un fichier AXML. Nous allons voir pas à pas comment mettre cela en place avec notre ClusterManager.

Pour commencer, voici le fichier AXML que je vais utiliser. Il affiche une image, un titre, du texte et une RatingBar :

 

Voici maintenant le code pour l’InfoWindowAdapter, qui permet de valoriser notre fichier AXML créé précédemment :

 

En temps normal (hors Clustering) pour utiliser une InfoWindow personnalisée, il faut créer un InfoWindowAdapter puis configurer notre MapView pour qu’elle utilise cet adapter. En Clustering, si nous faisons cela, l’InfoWindow apparaitra même si l’utilisateur clique sur un regroupement de marker. Ce n’est pas bon !

C’est pourquoi l’astuce consiste à laisser notre ClusterManager gérer les InfoWindows. Avec le code ci-dessous, nous allons dire à notre ClusterManager qu’il doit utiliser notre InfoWindowAdapter personnalisé créé précédemment, pour les markers simples uniquement. Puis nous allons dire à notre MapView qu’elle doit utiliser le ClusterManager comme InfoWindowAdapter. Ce sont les deux lignes de code 20 et 21.

Ensuite, afin de gérer les cliques sur l’InfoWindow, nous allons implémenter l’interface IOnClusterItemInfoWindowClickListener avec notre Activité :

 

Et voici le résultat ! Une carte avec des markers complètement personnalisés et un clustering animé 🙂

Google Map Android Clustering Markers

 

Comment afficher des informations spécifiques dans l’InfoWindow ?

Dans le paragraphe précédent, nous avons vu comment ajouter une InfoWindow personnalisée. Mais nous n’avons pas vu comment modifier les informations affichées en fonction de chaque ClusterItem ! Si mes markers représentaient des personnes, je voudrai que l’InfoWindow affiche leur nom, prénom, et leur score sur 5 étoiles par exemple. C’est ce que nous allons voir dans ce paragraphe.

Pour l’exemple, je vais simplement ajouter une chaîne de caractère spécifique à chaque marker. Pour cela, il faut ajouter une prorpiété à ma classe ClusterItem :

 

La modification du texte affiché dans les InfoWindow se fait dans le InfoWindowAdapter. Malheureusement, ce dernier n’a connaissance que du Marker cliqué, et non des ClusterItems. Nous allons donc utiliser un dictionnaire qui répertorie tous les Markers et leur ClusterItem associé. Pour cela, rendez-vous dans le ClusterRenderer. A chaque fois que ce dernier afficher un Marker sur la carte, on va ajouter l’association Marker-ClusterItem à notre dictionnaire :

 

Maintenant que nous avons notre dictionnaire reliant les Markers à leur ClusterItems associés, il suffit que notre InfoWindowAdapter garde une référence à ce dictionnaire et le tour est joué !

 

De retour dans notre Activité, créez le fameux dictionnaire et modifiez les constructeurs de l’InfoWindowAdapter et du ClusterRenderer :

Vous pouvez maintenant compiler et déployer sur votre téléphone. Les InfoWindows affichent correctement l’information spécifique contenue dans un Clusteritem :

Google Map Android Clustering Markers

 

Comment limiter le cluster par type de marker ?

Encore envie d’aller plus loin ? Pas de problème ! Je vous l’expliquais au tout début de mon article, dans Moovenow, on affiche des infrastructures, des associations, et des événements sportifs sur la carte. Nous avons donc trois types de markers différents, et nous voulions donc trois regroupements différents ! Ça se fait, ça fait mal au crâne mais vous verrez, on y arrive 🙂

Pour l’exemple, je vais rajouter une catégories de marker « favoris ». Ces markers seront jaunes (et non vert comme les autres). Et les regroupements de markers jaunes et verts seront indépendant. De même, les InfoWindows seront indépendants ainsi que les actions à faire suite à un clique sur l’InfoWindow.

Modifions d’abord notre classe Clusteritem. Si m_bIsFav est vrai, alors le marker sera jaune. Sinon, il sera vert.

 

Il faut ensuite modifier le ClusterRenderer, car c’est lui qui s’occupe de l’affichage des images :

 

Pour personnaliser le contenu des InfoWindows en fonction des types de marker, c’est comme tout à l’heure :

 

Tout va bien ? Respirez un bon coup, c’est là que tout se joue ! Dans notre Activité, on va créer plusieurs instances de ClusterManager afin d’avoir des regroupements indépendants. De même, il y aura plusieurs instances de ClusterRenderer. En revanche, on garde une seule instance de InfoWindowAdapter, qui sera réutilisée par les différents ClusterManager et ClusterRenderer.

De plus, comme il y a plusieurs instances de ClusterManager, on ne peut plus utiliser la ligne de code « m_map.SetOnCameraIdleListener(m_ClusterManager); ». Nous devons déclencher manuellement les événements OnCameraIdle des ClusterManagers. C’est pour cela que l’Activité doit implémenter l’interface IOnCameraIdleListener.

Voilà tout :

 

A vos téléphones pour le résultat tant attendu !

Google Map Android Clustering Markers

 

Comment organiser mon code pour gérer différents types de markers ?

Dans l’exemple précédent, j’ai utilisé un ClusterItem pour tous mes types de markers (favoris et non favoris). Pour un exemple, c’est suffisant. Mais pour un code durable et évolutif, je conseillerai plutôt de se pencher vers une classe abstraite, et une classe implémentant cette classe abstraite pour chaque type de marker. De ce fait, les classes personnalisées InfoWindowAdapter et ClusterRenderer ne seront créées qu’une seule fois, quelque-soit le nombre de types de markers.

 

Google Map Android Clustering Markers

 

 

J’espère que cet article vous a plut et vous a permis d’avancer dans vos projets ! Comment avez-vous réussi à implémenter l’API Google Map ? Quelle architecture avez-vous utilisé ? Partagez vos expériences 🙂

Xamarin.Android – Améliorer l’expérience utilisateur avec une ActionBar

Xamarin.Android – Améliorer l’expérience utilisateur avec une ActionBar

J’ai eu l’idée de ce post après avoir répondu à une question de Stackoverflow. Lorsque l’on créé une application Android, il est presque obligatoire d’avoir une ActionBar afin de procurer une bonne expérience de navigation à l’utilisateur.

 

Mais c’est quoi une ActionBar ?

Une ActionBar est propre à chaque Activité de votre application. C’est la partie tout en haut de l’écran, celle où se trouve le titre de votre page et votre menu :

ActionBar

Vous pouvez changer de fragment autant que vous voulez, cette ActionBar restera la même tant que vous êtes dans la même activité. Bien entendu, vous pourrez la configurer à tout moment pour changer son menu, son icône, son texte, sa couleur, ou même (et surtout) les actions effectuées suivant le bouton cliqué par l’utilisateur.

 

Comment ajouter une ActionBar à mon application mobile ?

Rien de plus simple ! Elle est déjà ajoutée en fait 🙂 Nous allons simplement voir comment configurer votre propre ActionBar pas à pas.

Si ce n’est pas déjà le cas, téléchargez et installez le package Nuget Xamarin Android Support Design. Cela permet de faciliter la retrocompatibilité de vos applications mobiles avec les anciennes versions d’Android. Copiez ensuite le code ci-dessous dans vos fichiers MainActivity.cs et MainActivity.axml. Je vous fais grâce du fichier Strings.xml. Si son contenu vous intéresse, tout est disponible sur mon Github !

Ce code n’a rien d’extra-ordinaire : il configure uniquement le Titre de l’objet SupportActionBar de l’activité. C’est tout ! C’est facile non ?

 

Avant de compiler pour admirer votre travail, vous devez tout de même spécifier que votre Activité doit utiliser un thème correspondant à AppCompat (eh oui, votre activité est une AppCompatActivity). Rajoutez cette information dans votre manifest, dans le tag Application (android:theme=….) :

 

Vous pouvez maintenant compiler et déployer sur votre téléphone :

ActionBar

 

Comment ajouter un menu en haut à droite de mon ActionBar ?

Le but principale d’une ActionBar est de faciliter la navigation de votre utilisateur. Lui dire dans quelle page il se trouve grâce au Titre, c’est bien ! Mais lui permettre de faire des actions communes en 1 clic, c’est vraiment beaucoup mieux !! Par exemple, pour pourrez permettre à votre utilisateur de partager du contenu sur les réseaux sociaux en 1 clic. Intéressant n’est-ce pas ?!

Commençons par créer un dossier « menu » dans le dossier « Resources » de votre projet Android :

ActionBar solution explorer

Puis, copiez le code ci-dessous dans le fichier top_menus.xml que vous aurez créé dans le dossier précédemment ajouté. Ce dernier déclare deux options pour votre menus. Il y aura 1 icône pour partager du contenu sur les réseaux sociaux, et 1 icône « More » (en forme de 3 points), dans lequel une option supplémentaire « more option… » sera affichée.

 

Maintenant que le fichier XML de votre menu est prêt, il faut indiquer à votre activité qu’elle doit l’utiliser. Cela se passe dans la méthode OnCreateOptionsMenu().

Ensuite, Il faut indiquer quelles actions l’activité doit effectuer lorsque l’utilisateur clique sur l’une de vos entrées du menu. Cela se passe dans la méthode OnOptionsItemSelected().

Rajoutez ces deux méthodes à votre activité, et le tour est joué ! N’oubliez pas le mot clef override 🙂

Avec ce code, lorsque l’utilisateur clique sur l’icône de partage sur les réseaux sociaux, il obtient la liste des applications avec laquelle il peut partager du contenu. Et lorsqu’il clique sur l’entrée « more option… », le titre de l’ActionBar est modifié.

                    ActionBar exemple 1                    ActionBar exemple 2 : partage sur les réseaux sociaux                    ActionBar exemple 3

 

Comment personnaliser la couleur de mon ActionBar ?

Pour personnaliser la couleur de votre ActionBar, il faut utiliser un thème. Imaginons que nous voulons une barre bleue et des écritures / icônes blanches. Nous allons étendre le thème par défaut et changer uniquement les valeurs qui nous intéressent. Le thème par défaut que nous utilisons est Theme.AppCompat.Light. Comme nous voulons une couleur de texte et d’icône blanche, nous utiliserons le thème Theme.AppCompat.Light.DarkActionBar. Voici un aperçut récupéré depuis la doc développeur pour vous montrer la différence entre ces deux thèmes :

ActionBar thème : Dark vs Light theme

 

Pour étendre et personnaliser un thème, il faut créer un fichier « styles.xml » dans le répertoire « values » du dossier « Resources » de votre projet Android. Copiez le code ci-dessous afin de paramétrer les couleurs de votre choix. Je vous épargne le fichier colors.xml mais s’il vous intéresse, tout est disponible sur mon Github !

 

Maintenant, comme tout à l’heure, il faut spécifier dans le manifest que notre activité va utiliser le thème ActionBarSampleTheme :

Il manque un dernier détail. Il faut encore modifier les icônes personnalisées du menu en haut à droite. Nous avions une image noire pour le partage sur les réseaux sociaux. Il faut maintenant une image blanche. Il faut simplement ajouter l’image dans le dossier « drawable » du répertoire « Resources » (et modifier le fichier top_menus.xml si le nom de votre image est différent de l’ancienne).

Voila le résultat :

ActionBar avec couleur / thème personnalisé

 

Pourquoi modifier le thème plutôt que la propriété de l’ActionBar ?

Précédemment, nous avons vu comment modifier le thème de l’application afin de changer la couleur de l’ActionBar. Il est pourtant possible de modifier la couleur de votre ActionBar en utilisant une méthode appelée SetBackgroundDrawable() associé à un objet de type ColorDrawable. A mon sens, ce n’est pas une bonne pratique de modifier la couleur d’un élément graphique de manière isolé.

En effet, le bon côté avec les modifications de style que nous avons fait, est que tout le reste de l’application sera impacté. C’est très efficace pour garder une image de marque identique et cohérente tout au long de l’expérience utilisateur. Pas d’oubli ni d’erreur possible, les couleurs sont spécifiées 1 fois, et réutilisées automatiquement partout dans l’application.

 

Comment ajouter un menu sandwich à mon ActionBar ?

Ajouter une icône pour ouvrir le menu

Nous savons maintenant que le principe d’une ActionBar est de faciliter la navigation de notre utilisateur afin d’améliorer son expérience. Mais jusqu’ici, il nous manque un élément important pour faciliter la navigation ! Un menu complet ! Nous allons voir comment ajouter un icône « menu sandwich » à notre ActionBar et comment afficher un menu sur la partie gauche de l’écran.

Pour commencer, il faut ajouter le code ci-dessous dans la méthode OnCreate de notre Activité. Il faut également ajouter une icône de menu dans votre dossier Resources/drawable nommé ic_menu_white_24dp.png.

Rien d’autre à faire ! Vous pouvez compiler et admirer le résultat… Une superbe icône de menu apparaît à gauche de votre ActionBar :

ActionBar avec menu sandwich

 

Pour détecter un clique de l’utilisateur sur ce bouton, il faut compléter la méthode OnOptionsItemSelected() de notre activité :

 

Afficher un menu sur le côté gauche de l’écran

C’est bien, on a réussi à afficher notre icône permettant à l’utilisateur d’accéder au menu complet de l’application. Il faut maintenant savoir comment afficher ce menu ! Pour cela, nous allons utiliser une NavigationView intégrée dans un DrawerLayout. Pas de panique, nous allons voir comment faire cela pas à pas. Pour commencer, il faut modifier le fichier AXML de notre activité :

Notre LinearLayout a été remplacé par un DrawerLayout. Nous y avons ajouté un élément NavigationView, comme si nous ajoutions n’importe quelle vue à un layout habituellement.

Vous remarquerez peut-être que le code XML ci-dessus affecte un menu à l’élément visuel NavigationView. Comme nous avions fait au début de ce tutoriel pour le menu de droite de notre ActionBar, il faut créer un fichier XML dans le dossier Resources/menu, nommé left_menus.xml :

N’oubliez pas de compléter votre fichier Strings.xml avec les valeurs de vos entrées de menu, et d’ajouter des images pour les icônes associés. Si vous ne voulez pas trop réfléchir, toutes les sources de ce tutoriel sont disponibles sur mon Github 🙂

Maintenant que nous avons fait toutes les configurations pour afficher notre menu, il faut compléter le code de notre Activité. Car c’est l’Activité qui va contrôler l’affichage de notre menu en fonction des cliques de l’utilisateur. Voici ci-dessous le code à rajouter dans votre fichier MainActivity.cs :

Et voici le résultat, le menu s’affiche de la gauche vers la droite soit en cliquant sur l’icône menu sandwich, soit en glissant le doigt du bord gauche de l’écran vers la droite :

ActionBar avec menu sandwich et NavigationView

 

Personnaliser l’affichage du menu avec les informations de l’utilisateur

Nous arrivons presque au bout de ce tutoriel. Il manque tout de même une petite chose à notre menu, vous ne trouvez pas ? Il manque « un header », c’est à dire une partie qui s’affiche au dessus des items du menu et qui permet d’afficher ce que l’on veut. Ce header est très utile pour valoriser l’image de marque de votre application tout en affichant des informations supplémentaires. Habituellement, ces informations concernent l’utilisateur connecté : la photo et le login par exemple. Vous le savez, il ne faut pas perturber les habitudes de nos chers utilisateurs ! 🙂 Alors voyons comment afficher ces informations.

Le header d’une NavigationView est en fait une vue classique, créée avec un fichier AXML. Une fois la vue créée, il suffit de spécifier à notre NavigationView que son header doit être égal à cette vue.

Dans un premier temps, créons notre vue. Je souhaite afficher une image de fond, ainsi que la photo de l’utilisateur actuel, son pseudo, et sa description. Ajoutez un fichier mainActivity_navigationView_header.axml dans le dossier Resources/layout de votre projet :

Si vous souhaitez reprendre les images que j’ai utilisées, tout est disponible sur mon Github 🙂

Maintenant que notre vue est créée, il faut paramétrer les textes et images en fonction de l’utilisateur actuel, puis spécifier à notre NavigationView que son header doit utiliser cette vue. Pour faire cela, il faut compléter le fichier MainActivity.cs :

Voila ! Rien d’autre à faire, vous pouvez compiler, déployer, et admirer le résultat de votre dur labeur :

ActionBar avec menu sandwich et NavigationView avec header personnalisé

 

Ajouter des badges de notification aux items de la NavigationView

Parfois vous souhaitez notifier votre utilisateur qu’il a de nouveaux messages à lire, ou plus généralement qu’une chose importante nécessite son intention. Pour cela, Android propose divers outils tels que les notifications push. Vous pouvez également notifier l’utilisateur directement via le menu, c’est très efficace. Lorsqu’un utilisateur voit un badge rouge avec un chiffre à l’intérieur, il comprend immédiatement qu’une chose nouvelle nécessite son intention. Nous allons voir comment mettre cela en oeuvre avec notre menu.

Commencez par compléter votre fichier left_menus.xml en rajoutant l’information app:actionViewClass à chaque item de votre menu :

C’est cette TextView qui va vous servir à afficher vos badges de notification.

 

Dans votre fichier MainAcitivity.cs, rajoutez maintenant le code permettant de styliser et afficher (ou pas) votre badge de notification. Pour ma part, j’affiche un carré rouge aux bords arrondis avec un numéro blanc à l’intérieur. Pour l’exemple, le badge de notification sera affiché ou caché à chaque clique effectué sur une entrée du menu, de manière dynamique. A vous de définir votre logique métier, en vous basant sur des requêtes API et/ou sur une base de données SQLite bien entendu 🙂

Et voici le contenu du fichier XML left_menus_itemBadge.xml, à rajouter dans le dossier Resources/drawable. Ce fichier sert à définir le carré rouge aux bords arrondis pour le background de notre TextView. Je ne copie pas mon fichier de couleurs, les sources complètes sont disponibles sur mon Github 🙂

Et le résultat :

ActionBar et NavigationView avec des badges de notification

 

 

J’espère que ces petits tips vous aurons aidé dans le développement de vos applications ! N’hésitez pas à commenter, poser des questions, proposer d’autres solutions, et surtout à montrer votre résultat 🙂

 

Réaliser une application mobile connectée sans se soucier du serveur back-end

Réaliser une application mobile connectée sans se soucier du serveur back-end

Avez-vous déjà entendu parlé de la méthode Serverless Mobile Application ? Dans ce post je vous présente une technique pour connecter votre application mobile au cloud à moindre effort.

 

Vous souhaitez créer votre application mobile connectée

Vous connaissez déjà le développement mobile ou vous n’avez encore jamais compilé votre propre application ? Peu importe, je vais cadrer le contexte pour que tout le monde comprenne.

Pour développer une application mobile, il existe plusieurs technologies. Je les détaillerai dans un poste ultérieurement, ce n’est pas ce qui nous intéresse ici. Ce qu’il faut retenir c’est qu’une application mobile, pour être connectée, c’est comme un site web : il faut un serveur qui centralise les données. Et la problématique dans tout ça ? Développer une application mobile et développer un serveur c’est comme une vache et une mouche : c’est complètement différent et pourtant ça va toujours ensemble.

 

Quel est le rôle du serveur back-end vis à vis de l’application mobile ?

Le serveur back-end sert à stocker et fournir les données à l’application mobile. Toutes les données sont recensées au même endroit, dans le serveur, et l’application mobile n’a qu’à interroger le serveur pour obtenir les données puis les afficher correctement à l’utilisateur.

De même, toute l’intelligence métier et tous les algorithmes doivent être fait par le serveur, et non par l’application mobile. Cela pour diverses raisons :

  • La première et la plus importante : pour centraliser l’effort. Si demain j’associe un site web à mon application mobile, je n’aurai qu’à brancher le site sur le même serveur que mon application, sans avoir à recréer les algorithmes de logique métier. De même avec une application Android, et une iOS.
  • La seconde, et pas moins importante que la première : les algorithmes métier ne seront codés qu’une seule fois, dans le serveur. S’il y a un bug ou des modifications à effectuer, le travail sera fait une seule fois, à un seul endroit, et sera répercuté partout (applications mobiles, éventuels sites web, etc…)
  • Enfin, un serveur est une machine disposant de puissant moyens de calculs, contrairement à un smartphone qui a des capacités de calculs bien inférieurs : donc plus lent.

En résumer : le serveur back-end est le cerveau, c’est lui qui réfléchie. Quand à l’application mobile, elle n’est là que pour servir d’interface entre l’utilisateur et les données.

 

 Comment fonctionne un serveur back-end classique ?

Qu'est ce qu'un serveur back-endDe manière très classique, un serveur back-end est constitué d’une base de données, et d’une API faisant le lien entre la base de données et l’extérieur du serveur. En disant l’extérieur, j’entends votre application mobile, votre site web, ou n’importe quelle autre requête isolée. N’oubliez pas que des robots de pirates tournent en permanence pour essayer des adresses au hasard, et une fois qu’ils ont trouvé une adresse valide, essaient les failles de sécurité connues pour tenter de pirater vos données.

Techniquement, l’extérieur peut accéder directement à la base de données en disposant des identifiants adéquats, sans passer par une API. Cela permet d’économiser le coup de production d’une API. Mais cela est fortement déconseillé ! D’une part car cela force le développeur à créer la logique métier en dehors du serveur, mais surtout car cela ouvre des portes permettant de pirater la base de données.

En résumé : un serveur back-end comprend une base de données, et une API qui sert de porte d’entrée et/ou de sortie.

 

Quel moyen pour réduire l’effort de mise en place d’un serveur back-end ?

Je souhaite vous parler ici d’une technique particulière, appelée « Serverless Backend for Mobile Application ». James Montemagno l’a parfaitement détaillé sur le blog Xamarin. Cette technique n’invente rien, elle permet juste d’utiliser les derniers outils de Microsoft  afin de s’affranchir d’un maximum de travail, tant lors de la création que pour le développement ou la maintenance.

Il s’agit d’utiliser les derniers outils du moment, à savoir Microsoft Azure, afin de ne coder que le stricte nécessaire. Tout le reste étant pris en charge automatiquement par Azure. Je m’explique : des actions comme « vérifier les droits d’un utilisateur » ou « gérer un pull de thread permettant de traiter les unes à la suite des autres toutes les requêtes entrantes dans le serveur » sont des actions génériques à tout projet. Cela ne sert à rien de les re-développer à chaque fois. Au contraire, le stricte nécessaire pour une application est la logique métier, les algorithmes propre à l’application, les accès à la base de données etc…

Utiliser la méthode Serverless Backend for Mobile Application permet de ne coder que la logique métier. Tout le reste étant pris en charge automatiquement par Microsoft Azure. Il n’y a même pas besoin de coder sur son ordinateur et mettre le code en ligne : on peut coder directement dans le navigateur internet ! Cela simplifie et accélère considérablement la création d’API pour son projet d’application mobile.

 

C’est parti, je veux essayer ! Par où commencer ?

Bravo ! Je suis content de vous avoir convaincue d’essayer ! Mais avant tout, je vous invite à lire mon retour d’expérience sur le projet Gotago pour avoir un aperçu des avantages et des inconvénients de cette méthode. Toute méthode est indiquée dans certain cas de figure, comme elle peut être contre-indiquée dans d’autres circonstances. Celle-ci, en particulier, est conseillée pour des projets plutôt court, ou des POC.

Pour commencer, il faut avoir un compte Microsoft Azure. Tout est gratuit jusqu’à un certain seuil (que je n’ai pas dépassé en plusieurs mois de développement).

Dans Azure, vous pourrez créer, héberger, et administrer votre base de données en SQL Server. Vous pourrez utiliser un outils de visualisation de base de données de votre choix. Personnellement, j’utilise Visual Studio.

Pour ce qui va vous servir d’API, vous créerez une Function App. Cette dernière sera constituée d’HTTP Triggers. Un Http Trigger est un script exécuté, comme son nom l’indique, par une requête Http à une URL précise. On peut faire un GET ou un POST, et utiliser du JSon pour transférer des données par exemple. Vous créerez votre logique métier dans ces Http Triggers, et vous utiliserez les URL depuis vos applications mobiles ou vos sites web pour envoyer ou récupérer du JSon. Et voilà, c’est tout ! Rien de plus à faire.

 

Un petit exemple avant de finir

Voici un petit exemple d’un Http Trigger dans Azure. Je vais réaliser une API permettant de vérifier la validité d’une adresse email d’utilisateur. Par exemple quand un utilisateur s’inscrit dans votre application, il ne doit pas utiliser une adresse mail déjà utilisée.

Je vais avoir une URL : https://api-monexemple.azurewebsites.net/api/isemailvalid

En POST, je vais passer une chaine JSON : { email : « mon@email.com » }

En résultat, l’URL renverra une chaîne JSON avec l’adresse email vérifiée, et le résultat de la vérification : { email : « mon@email.com », isValid : true }

Je pourrais ensuite effectuer une requête HTTP vers l’URL depuis n’importe où ! Mon application Android, mon application iOS, mon site web… De plus, l’algorithme de vérification d’email peut changer à tout moment, la seule modification à faire sera sur l’API.

 

   Interface de codage directement dans le navigateur

La fenêtre ci-dessous représente mon navigateur internet dans lequel j’ai codé mon HTTP Trigger. On voit le code en haut à gauche, la fenêtre de test à droite, et la console en bas à gauche.

Exemple d'une function app d'Azure

 

La fenêtre de code me permet, comme vous l’aurez deviné, de coder mon API. Je fais les « includes », je décrypte le body si c’est une requête POST, j’appelle la fonction pour le code métier, et j’envoie une réponse avec le résultat du code métier.

La fenêtre de test me permet de simuler un appel à l’API complètement personnalisé. C’est très pratique pour tester son développement ! Sans cette fenêtre, je devrai lancer mon application Android ou iOS et cliquer le bouton qui effectue l’appel API… Une fois que l’appel a été effectué en test, j’ai directement le résultat en dessous, en vers, avec la chaîne de retour associée.

La fenêtre de console, quant à elle, donne toutes les informations sur le code. Si le code compile ou pas, où sont les erreurs… On a également les traces en cas d’appel à l’API. On pourra retrouver ces traces à un autre endroit : dans la fenêtre de monitoring. Cette dernière offre un historique de tous les appels effectués à l’API. C’est indispensable pour maintenir son service.

 

   Code métier de l’API

La fenêtre ci-dessous présente le code métier qui vérifier mon adresse email. J’ai retiré les fenêtre de test et la console pour plus de lisibilité :

Exemple d'une function app d'Azure

Le code vérifie dans un premier temps le format de l’adresse email.

Ensuite, l’API se connecte à une base de données, et effectue une requête SQL permettant de vérifier si un utilisateur avec la même adresse email existe déjà. La base de données SQL peut être hébergé, gratuitement jusqu’à un certain seuil, sur Azure. Elle peut tout à fait être hébergée ailleurs aussi.

Enfin, voici la classe permettant de gérer le JSON de la requête HTTP :

Exemple d'une function app d'Azure

En utilisant cette classe et le package Nuget Newtonsoft.Json, je peux sérialiser et desserialiser du JSON en une simple ligne ! Extrêmement pratique n’est ce pas ?!

 

 

Et vous, quelles méthodes utilisez-vous pour vos créer API ? Quelles architectures utilisez-vous pour vos plateformes web et/ou mobile ?