Quelle approche suivre pour développer des applications ciblant plusieurs plateformes?

Pour les applications ciblant plusieurs plateformes, je vois principalement deux approches de développement -

• Optez pour une plate-forme de développement de type JAVA. Avoir une solution de code et laisser le runtime intermédiaire gérer différentes plates-formes. Si quelque chose ne va pas dans une plate-forme, ajustez un peu le code. Mais gardez les mêmes pour tous.

• Créez du code modulaire séparant la logique de base et l'interface utilisateur. Développer des interfaces utilisateur distinctes pour les plates-formes respectives qui appellent les mêmes bibliothèques principales. Générez l'application séparément pour chacune des plates-formes cibles.

Alors, lequel suivre? Je sais, la réponse commencera par " Ça dépend ". Mais je veux entendre vos opinions sur ces approches et les facteurs à considérer pour choisir l'une d'entre elles.

À part Oracle / Apache / Google actuel, il est difficile de battre la JVM à cet effet. C'est vraiment de très haute qualité sur la plupart des plateformes, universel, et vous avez un bon nombre de langues parmi lesquelles choisir (Java, Clojure, Scala etc.). Il vous permet de cibler une architecture de machine unique (la machine virtuelle) et de ne pas trop vous soucier du matériel spécifique de l'utilisateur final.

Cela dit, il peut ne pas convenir à certains types d'applications: la mise en réseau de bas niveau vient à l'esprit, tout comme le traitement graphique / vidéo lourd.

Optez pour HTML5. Toute plate-forme avec un navigateur HTML5 peut exécuter votre application. Bien que HTML5 ne soit pas encore prêt pour grand temps, l'approche de l'application Web l'est.

Dans l'éditeur de sons Audacity, nous utilisons wxWidgets comme bibliothèque multiplateforme. Étant donné que nous devons établir un lien avec les bibliothèques C et que nous avons besoin d'un accès rapide et de bas niveau, une approche JVM ne fonctionnerait pas pour nous. Le code GUI est le même à 95% sur toutes les plateformes. Nous utilisons #ifdefs pour les petites variations. Cependant, nous trouvons essentiel qu'un développeur travaille sur chacune des trois plates-formes (Mac, Windows Linux), car même en utilisant la bibliothèque multiplateforme, il est trop facile pour un changement sur une machine de casser des choses sur une autre.

Si vous pouvez obtenir les performances dont vous avez besoin, optez pour JVM. Si vous ne le pouvez pas, utilisez QT ou wxWidgets, et je suggérerais QT plutôt que wxWidgets car cela demande moins de travail pour qu'il soit joli.

En tant que développeur en temps réel, j'ai utilisé avec succès une option similaire à 2 - des modules spécifiques à la plate-forme séparés avec une API commune utilisée par la logique principale. Cependant, rien de ce que j'ai fait n'a d'interface utilisateur - réseau, audio, streaming de données - dans ce cas, c'est l'interface matérielle de bas niveau qui est spécifique à la plate-forme.

Je l'ai fait de cette façon pour plusieurs raisons:

1) Pour obtenir les performances optimales sur chaque plateforme

2) Pour profiter des fonctionnalités proposées uniquement sur 1 plateforme

3) (J) Les VM n'existaient pas pour certaines plateformes (systèmes embarqués, consoles de jeux ...)

Cela dépend de ce qui est important pour vous :)

Lorsque nous avons été confrontés à ce choix pour une application Mac / Windows multiplateforme il y a environ 10 ans, nous avons jeté un coup d'œil aux différentes options multiplateformes - Java, Qt, wxWidgets, etc. Le problème que nous avions était que l'apparence de l'interface utilisateur était vraiment importante pour nous, et toutes les applications "multiplateforme" semblaient, enfin, compromises. Nous avons fini par mordre la balle et construire notre propre noyau multiplateforme, avec une interface utilisateur personnalisée pour chaque plate-forme en haut (écrite dans PowerPlant pour Mac et MFC sous Windows). Au fil du temps, nous avons assez bien réussi, et la partie «multiplateforme» est devenue plus épaisse sans compromettre l'interface utilisateur.

Nous examinons à nouveau cette décision pour un nouveau projet. En regardant les options maintenant, j'irais probablement avec Qt - c'est gratuit et semble vraiment avoir bien mûri. Java était peut-être une option, mais nous ne pouvons pas vraiment prendre le coup sur les performances (nous faisons du traitement d'image 3D).

Si l'interface utilisateur est vraiment importante pour vous, je pense que vous devrez investir beaucoup de temps pour que les choses soient correctes sur chaque plate-forme, que vous utilisiez quelque chose comme Qt ou que vous rouliez le vôtre. Pour une application interne ou spécialisée où les utilisateurs pourraient accepter davantage une interface utilisateur moins soignée, cela pourrait convenir!

Tout le monde fait beaucoup d'histoires sur les langages comme Java étant «multiplateforme» mais ce dont ils parlent vraiment, c'est que vous pouvez compiler une fois et l'exécuter partout. Même dans un langage comme Java (ou C # / mono), vous aurez toujours besoin de couches d'abstraction pour traiter les détails spécifiques au système d'exploitation dans certaines zones.

C ++, et en fait la plupart des langages, sont multi-plateformes, il suffit de compiler pour cibler chaque plateforme.

Leur clé est le processus plutôt que les outils / langages:

1. Assurez-vous que vous disposez d'un processus de génération intégré qui génère et exécute les tests unitaires pour toutes les plates-formes cibles .
2. Assurez-vous que chaque développeur teste sur toutes les plates-formes cibles avant d'archiver le code - Cela signifie évidemment que chaque développeur a accès au nombre approprié de machines / vms.
3. Bien résumé. Abstrait tout ce qui appelle des API natives. Écrivez des bibliothèques qui encapsulent ces appels.
4. Si vous faites quoi que ce soit au-delà d'une interface utilisateur de formulaires assez simple qui s'adresse au plus petit dénominateur commun, acceptez simplement que le code GUI n'est pas multiplateforme. Extrayez votre interface graphique / couche de présentation et codez-la séparément pour chaque plate-forme. Oui, il existe des boîtes à outils graphiques multi-plateformes, qui conviennent parfaitement aux applications simples, mais si vous faites quelque chose de plus avancé, vous voudrez coder les capacités de la plateforme native.

Ces étapes sont les mêmes quel que soit le langage / jeu d'outils / framework que vous utilisez.

Tirez parti du Web!

Sérieusement, si vous voulez en avoir pour votre argent, écrivez une application Web.

Pourquoi?

• Les clients Web ne nécessitent généralement pas beaucoup de puissance PC.
• Les clients Web sont PARTOUT. Pas seulement PC / MAC / Linux, mais aussi sur les téléphones, les appareils mobiles et plus encore.
• Rien de plus à télécharger pour les utilisateurs! (En règle générale, sauf si vous voulez quelque chose de fantaisiste et utilisez Flash ou Silverlight)
• Tous les composants courants sont du côté serveur et peuvent être Java, .NET, PHP ou un mélange d'un tas de composants existants. Le client ne devrait pas s'en soucier!

Même les deux approches que vous avez mentionnées sont très similaires. Le navigateur Web rend HTML pour plusieurs architectures sous-jacentes. De même, la JVM interprète le code Java d'une manière qui a du sens pour le matériel sous-jacent. Cependant, le Web a simplement une clientèle plus large!

J'ai eu pas mal de chance avec Mono. Je peux écrire le même code pour les machines Windows que pour les machines Linux, et pour la plupart, il fonctionne sur les deux. Et je peux utiliser les compétences que je connais déjà en C # et Winforms.

Faites d'abord une preuve de concept.

S'il s'agit d'une application raisonnablement complexe, l'élaboration d'une preuve de concept vous donnera une idée des fonctionnalités linguistiques dont vous avez besoin et des domaines dont vous aurez besoin pour tirer parti du framework ou des bibliothèques tierces.

Les fonctionnalités linguistiques et les bibliothèques dont vous avez besoin vont déterminer la langue que vous finirez par choisir (et donc, comment vous allez aborder la prise en charge multiplateforme)

J'ai construit un système, en commençant par une application de bureau, il y a 15 ans, lorsque Java était encore à ses balbutiements et n'était pas prêt à être utilisé pour créer ce type d'applications. Je savais que je devais avoir un noyau en C ++ et je l'ai conçu dès le départ pour être multiplateforme, y compris en utilisant des types de taille (par exemple int32 au lieu de int ou long), afin qu'il puisse fonctionner sur Mac, Windows et UNIX (pré-Linux journées).

À l'époque, j'ai essayé de chercher un bon environnement d'interface multiplateforme, il y en avait quelques-uns, y compris XVT. J'ai suivi la formation pour XVT et quand j'ai commencé à créer une vraie application, j'ai réalisé que je n'allais pas pouvoir créer un look and feel propre et natif sur la plateforme (à commencer par le Mac). J'ai donc abandonné cette idée et créé une interface utilisateur native pour Mac (PowerPlant) au-dessus du noyau portable.

Quelques années plus tard, nous sommes passés à Windows (interface utilisateur dans MFC). Il était plus rapide de créer une interface utilisateur la deuxième fois, nous avons maintenu une interface utilisateur Mac et Windows en parallèle pendant une courte période, puis nous sommes allés à Windows. Le noyau est ensuite passé à diverses versions d'UNIX et de Linux, pour nous permettre d'exécuter des calculs sur serveur. Le noyau a bien porté, avec quelques ajustements lorsque nous l'avons rendu 64 bits prêt.

Maintenant, je recommence à utiliser un Mac et j'aimerais que nous puissions revenir au Mac, mais la taille et la complexité de l'application en font un choix difficile. Il est toujours logique qu'une grande partie de cette application soit une application de bureau - c'est comme un environnement CAO. Mais plutôt que de reconstruire l'interface utilisateur dans un langage C / C ++ spécifique à la plate-forme (et de continuer à maintenir une interface utilisateur basée sur MFC), je suis plus enclin à réécrire la pile entière en Java afin qu'elle puisse s'exécuter sur plusieurs plates-formes.

Il peut toujours y avoir des raisons d'exécuter un noyau non Java, par exemple C ++ comme nous l'avons fait. Mais je voudrais exécuter des tests de performances précoces pour voir si cela était vraiment nécessaire. Et je regarderais attentivement mon interface utilisateur pour voir si je pouvais la construire en tant qu'application Web, connectée au noyau via des services Web, afin que je puisse avoir une gamme de clients - applications de bureau, applications mobiles, applications Web, etc. Si j'avais besoin d'un morceau en C ou C ++, pourrait-il être écrit sous une couche de Java? Ou en tant que service Web?

Une autre considération - combien de temps durera votre application? À quel point deviendra-t-il complexe? Si vous avez des idées à ce sujet, tenez compte de la longévité possible de toutes les bibliothèques d'interface utilisateur que vous utilisez et de votre capacité au fil du temps à aider les gens à les maintenir. Cela peut être difficile à considérer maintenant mais mérite réflexion.

- Alex

Si vous pouvez en faire une application Web, faites-en une application Web. En utilisant des boîtes à outils comme ExtJS , il est relativement facile de créer de belles interfaces utilisateur compatibles avec un navigateur de type GUI.

Sinon, Java ou QT + C ++ ou C + Wx sont des options possibles pour avoir une seule source pour tous.

Votre deuxième approche est appropriée si vous souhaitez que l'application semble native sur chaque plate-forme cible. Les applications Mac natives sont différentes des applications Windows natives, il ne suffit pas d'utiliser un autre skin et des raccourcis clavier pour couvrir cela.