Le paysage informatique actuel est très hétérogène. Nous avons affaire à différentes plateformes, types d'appareils, facteurs de forme, systèmes d'exploitation et langages de programmation. Un aperçu très intéressant à ce sujet est donné par le State of the Developer Nation Q1 2016 Report<\/A> sur visionmobile.com. La disponibilité complète d'une application propre pour tous les utilisateurs n'est en fait plus réalisable dans ce paysage. Plus la disponibilité doit être élevée, plus cela devient coûteux ou plus de compromis doivent être faits.<\/P>Pour atteindre une disponibilité optimale pour une application Native mobile, celle-ci devrait être développée au moins trois fois ! pour les plateformes mobiles dominantes actuelles iOS, Android et Windows Phone. Cela coûte cher. Pour économiser sur les coûts de développement, le développeur pourrait choisir moins de plateformes, mais il atteindrait alors également moins d'utilisateurs.<\/P>Cet exemple montre clairement qu'en phase de planification d'une application, des concepts devraient être développés afin d'atteindre une disponibilité aussi élevée que possible des applications sur différentes plateformes avec un faible effort de développement – et donc des coûts moindres. Nous en arrivons ainsi au sujet du développement multiplateforme, l'un des problèmes les plus importants auxquels les développeurs doivent faire face aujourd'hui.<\/P>Le développement multiplateforme signifie développer le code d'une application une seule fois et la déployer sur plusieurs plateformes généralement incompatibles entre elles. Le développement multiplateforme signifie également toujours trouver un compromis entre le public cible visé, l'effort de développement, l'expérience utilisateur (UI\/UX) et la fonctionnalité.<\/P> <\/P><\/A><\/P> <\/P>Comme on peut le voir dans le graphique, il existe différentes approches avec leurs avantages et inconvénients respectifs pour la programmation multiplateforme. Une bonne option est certainement la mise à disposition en tant que Web-App. Le code est écrit une seule fois et hébergé sur un serveur web. La Web-App fonctionne ensuite dans le navigateur sur presque tous les appareils actuels. Avec JavaScript\/HTML5, il est désormais possible de créer des applications très puissantes et performantes. Outre l'obligation permanente d'être en ligne, la limite technique est le navigateur lui-même, qui ne permet pas l'accès à de nombreux capteurs des appareils, aux carnets d'adresses, à toute la mémoire locale, etc. Par exemple, il n'est pas possible de réaliser ainsi des applications pour le travail sur le terrain avec utilisation hors ligne de grandes quantités de données.<\/P>En revanche, les Native-Apps sont spécialement adaptées à chaque plateforme respective et peuvent ainsi accéder à toute la puissance du matériel, aux composants UI, à la mémoire et aux fonctionnalités des appareils. Ce serait l'approche correcte pour une application mobile avec fonctionnalité hors ligne pour le travail sur le terrain. En raison de cette « spécialisation », le développement multiplateforme des Native-Apps n'est possible qu'avec des outils spéciaux tels que Qt\/QML<\/A>, Microsoft UWP<\/A> ou Xamarin<\/A>. Le code des applications développées avec les SDK natifs ne peut pas être rendu multiplateforme par la suite. Il faut donc bien y réfléchir avant.<\/P>Les applications hybrides sont une voie médiane entre ces deux possibilités. Avec des frameworks comme PhoneGap<\/A> ou Titanium Appcelerator<\/A> etc., le code JavaScript peut être compilé en Native-Apps pour différentes plateformes, dépassant ainsi les limites du navigateur. Les applications hybrides ressemblent et se sentent comme des Web-Apps, mais elles peuvent accéder à plus de ressources des appareils.<\/P>Le développement d'applications Geo avec la technologie Esri n'est bien sûr pas exempt de ce problème. Dans Partie 2<\/A><\/SPAN> de ce blog, des solutions et outils pour les développeurs ArcGIS concernant le développement multiplateforme sont expliqués.<\/P><\/BODY><\/HTML>
Pour atteindre une disponibilité optimale pour une application Native mobile, celle-ci devrait être développée au moins trois fois ! pour les plateformes mobiles dominantes actuelles iOS, Android et Windows Phone. Cela coûte cher. Pour économiser sur les coûts de développement, le développeur pourrait choisir moins de plateformes, mais il atteindrait alors également moins d'utilisateurs.<\/P>
Cet exemple montre clairement qu'en phase de planification d'une application, des concepts devraient être développés afin d'atteindre une disponibilité aussi élevée que possible des applications sur différentes plateformes avec un faible effort de développement – et donc des coûts moindres. Nous en arrivons ainsi au sujet du développement multiplateforme, l'un des problèmes les plus importants auxquels les développeurs doivent faire face aujourd'hui.<\/P>
Le développement multiplateforme signifie développer le code d'une application une seule fois et la déployer sur plusieurs plateformes généralement incompatibles entre elles. Le développement multiplateforme signifie également toujours trouver un compromis entre le public cible visé, l'effort de développement, l'expérience utilisateur (UI\/UX) et la fonctionnalité.<\/P>
<\/P>
Comme on peut le voir dans le graphique, il existe différentes approches avec leurs avantages et inconvénients respectifs pour la programmation multiplateforme. Une bonne option est certainement la mise à disposition en tant que Web-App. Le code est écrit une seule fois et hébergé sur un serveur web. La Web-App fonctionne ensuite dans le navigateur sur presque tous les appareils actuels. Avec JavaScript\/HTML5, il est désormais possible de créer des applications très puissantes et performantes. Outre l'obligation permanente d'être en ligne, la limite technique est le navigateur lui-même, qui ne permet pas l'accès à de nombreux capteurs des appareils, aux carnets d'adresses, à toute la mémoire locale, etc. Par exemple, il n'est pas possible de réaliser ainsi des applications pour le travail sur le terrain avec utilisation hors ligne de grandes quantités de données.<\/P>
En revanche, les Native-Apps sont spécialement adaptées à chaque plateforme respective et peuvent ainsi accéder à toute la puissance du matériel, aux composants UI, à la mémoire et aux fonctionnalités des appareils. Ce serait l'approche correcte pour une application mobile avec fonctionnalité hors ligne pour le travail sur le terrain. En raison de cette « spécialisation », le développement multiplateforme des Native-Apps n'est possible qu'avec des outils spéciaux tels que
Les applications hybrides sont une voie médiane entre ces deux possibilités. Avec des frameworks comme
Le développement d'applications Geo avec la technologie Esri n'est bien sûr pas exempt de ce problème. Dans
Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
