Dire que la paysage du développement d’application multiplateforme a évolué ces dernières années serait un euphémisme, tant sur le plan mobile que back-end ou front-end. Et toujours à la clé, le défi de la performance en termes de développement (développer le plus rapidement possible et à moindre coût pour le client) et de la performance de l’application multiplateforme livrée qui ne se résorbent pas au fil du temps, bien au contraire.
Le nouveau paradigme de développement d’application multiplateforme confronte les développeurs à un environnement hétéroclite multi-OS et multi-appareils (iOS, Android, PC, Web). Et bien sûr, la demande exige un livrable multiplateforme et multi-appareils performant !!!
Du développement mobile au multi-appareil au développement d’application multiplateforme
Avant, le développeur codait selon son expertise et sa philosophie de programmation et la profonde connaissance d’un environnement donné, vous étiez Java, Open Source, Windows, iOS ou BlackBerry ; bref, vous codiez pour une et une seule plateforme.
Avec l’avènement du BYOD, l’explosion de la Mobilité et la multiplicité des applications mobiles ; le développeur était confronté à la multiplicité des OS et à choisir une stratégie de déploiement / codage car il devait coder pour 2-3 OS différents et leurs UI, bien sûr. Deux écoles de pensée se sont affrontées : le natif versus le web mobile avec ses différents fureteurs.
Le défi des développeurs consistait aussi à rencontrer des contraintes de prix imposées par la compétition outre-mer et outre-continent tout en codant… 2 à 3 fois plus de code !
Ajoutez à cela que le monde de la Mobilité a introduit un nouveau modèle d’Affaires dans le marché, soit la gratuité du logiciel (application) quitte à trouver une façon de monétiser plus tard le trafic (les abonnements & téléchargements) dont beaucoup ont surestimé la valeur ou n’ont jamais réussi à le monétiser adéquatement pour faire leurs frais ou des profits.
Ainsi, les « Purs Mobiles » ont opté initialement pour la stratégie de développer / déployer une application native complète uniquement pour l’OS du marché principal visé (et plus tard, pour chaque OS / marché); ce qui vous coupait de certains marchés mais qui, en théorie, délivrait des applications très performantes. Les autres moins puristes se sont tournés vers le développement web mobile auquel on a souvent reproché son manque de charme (design moins sexy) en contrepartie de son adaptabilité à plusieurs OS ! Cependant, le développement web mobile offrait un avantage indéniable en termes de coûts de développement et de déploiement.
Voyez grand mais codez petit
Ainsi, dans ce contexte, face au défi de coder à moindre coût tout en accédant à toutes les plateformes (OS), certains ont cherché une pierre d’assise sur laquelle appuyer leur développement sans toutefois pénaliser la performance de leurs applications ; en l’occurrence, le Serveur.
C’est l’angle sous lequel Analystik a choisi de regarder, ou si vous voulez, l’actif sur lequel elle a choisi de capitaliser ; ainsi dans le design de nos applications multiplateformes, nous gardons toute la logique d’affaires de l’entreprise, les principaux calculs et traitements ainsi que les données du côté « Serveur ». Oui, c’est vrai, on parle encore et toujours de la bonne vieille Architecture Serveur / Client, comme dans le temps où les caractères affichés sur les écrans étaient verts. La grande différence aujourd’hui est dans la façon de « parler » aux différents Clients; cela nécessite un protocole de communication adéquat qui est en mesure de bien répondre aux besoins d’affaires et ce, sur différentes plateformes et différents OS (différents Clients).
Pour la communication Serveur – Client, Analystik a choisi REST (Representational State Transfer), un protocole HTTP très performant et polyvalent, ce qui lui permet de « parler » avec Java, JavaScript, C#, Swift, Objective C, etc.; bref, nous voyons grand ! REST est très performant car il transfère les données d’une façon peu verbeuse (contrairement à SOAP).
Conséquemment, dans notre philosophie de design d’applications, nous avons convenu de coder petit sur le plan des Clients / UIs, soit de restreindre la nature et la quantité des instructions exécutées à des instructions d’affichage, de couleurs, etc.
En un mot, ce qui est unique à chaque Client sera codé côté « Client » et tout ce qui est commun à tous les Clients sera codé côté « Serveur ».
Exemple : Pour les taxes et les frais d’expédition d’un site eCommerce, les données seront téléchargées sur le Serveur et les calculs (sommes et taxes) se feront aussi du côté Serveur, puis les données seront mises en cache et affichées côté Client seulement lorsque requises.
Assumer ses choix…
Cette approche nous a amené à faire preuve d’ingéniosité car elle capitalise aussi beaucoup sur le protocole de communication REST en lui imposant parfois la charge d’un haut débit de transfert de données entre le Serveur et les Différents Clients, ce qui eut été impossible il n’y a que quelques années encore. Il a donc fallu en tenir compte et s’y adapter.
…et développer de bonnes pratiques
Conséquemment, nous avons appris et développé quelques bonnes pratiques :
- Limiter la quantité d’instructions exécutées du côté Client
- Développer son flair pour le timing d’exécution
- Choisir le bon moment pour transférer les données aux Clients / UIs
- Donner les bonnes instructions de mise en cache pour chaque Client / UI
- Savoir identifier et profiter des capacités et performance de chaque Client
Vous vous attaquez au développement d’application multiplateforme ; suivez ces bonnes pratiques, voyez grand mais codez petit et votre code devrait durer… longtemps, longtemps !
Bon développement d’application multiplateforme,
Denis Paul & Michel
Laisser un commentaire