Google propose un outil pour faciliter le portage Java vers Objective-C, Réactions à la publication du 19/09/2012

[Rédaction]

Alors que le principal langage utilisé pour le développement d'applications sous Android est le Java, Google propose depuis quelques jours un outil dont le but est de convertir du code Java en code Objective-C, qui pourra être compilé dans une application iOS.


Baptisé J2ObjC, l'outil, en ligne de commande, est destiné à permettre aux développeurs d'écrire tout le code "interne" (non lié à l'interface utilisateurs) de leurs applications mobiles une seule fois, en Java, pour l'intégrer ensuite à des applications Android ou iOS, voire des applications web.


Il devrait également permettre aux développeurs iOS de piocher dans les nombreuse bibliothèques libres disponibles en Java pour en intégrer des parties dans leurs applications iOS.


Si l'arrivée de cet outil peut paraître surprenante, en donnant l'impression que Google souhaite faciliter le développement pour iOS, le but est en fait probablement tout autre : inciter les développeurs d'applications mobiles multi-plateformes à développer d'abord une version Java pour Android, puis à l'adapter à iOS, plutôt que de développer en priorité pour iOS, avec éventuellement un portage Android par la suite.
Par Matthieu Sarter

[Dieru]

Complètement raccord avec la remarque. Aujourd'hui je demande à développer prioritairement pour iOS puis Android. La raison : simple, le panel utilisateur. Les utilisateurs Android se divise en 2 catégories : Ceux qui veulent un smartphone, le moins cher possible. Eux achetent peu voir pas d'applications. Les Geeks qui veulent un terminal "ouvert" qui achetent ou piratent. Les Clients iOS achetent plus facilement des applications, dès lors que leur cout ne dépasse pas 3€. Plus de source de revenu pour le dev CQFD;

[Albert Einstein]

Adobe n'avait elle pas essayer de faire la même chose avec flash puis un convertisseur, s'attirant ainsi la foudre de steve Jobs qui bloquait les apps ?

[GregWar]

Mouais... le projet ne gère aucun aspect graphique, et c'est un choix ferme. C'est donc toute l'interface qu'il faut revoir.

D'autant plus que l'écrasante majorité des apps sur mobile ne font rien d'autre qu'afficher une (série d')info(s), et 2/3 questions utilisateurs.
La couche de présentation (si tant est qu'elle soit séparée) doit souvent représenter 60 à 80% du code.


Pour moi c'est plus un rôle éducatif, et ca va plus servir Apple que Google.
Tiens, j'ai un algorithme en java, un peu compliqué avec de la synchro, des IO, et tout... comment je peux l'écrire en ObjC alors que je ne connais pas l'équivalent des toolkits, des collections...?
Bah, ca me donne une idée.

[petia]

double bonus pour Google:

- dissuader les programmeurs de maîtriser l'Obj-C
- faire ramer les applis iOS portées ainsi (parce qu'aucune conversion de code n'est optimale), que l'on pourra défavorablement comparer avec leurs équivalents sous Android.

[axey]

Mouais...

Dans le genre on peut aussi utiliser Ruby: Rubymotion pour iOS et Ruboto pour Android.
Mais là encore, ça ne fonctionne pas pour les interfaces.
Or dans les applis mobiles, la gestion de l'interface représente souvent la majeure partie du code.

Autre alternative: Haxe http://haxe.org/
Et là on peut utiliser NME http://www.haxenme.org/ pour avoir un code commun à toutes les plateformes, y compris pour l'interface et la gestion du réseau. Mais c'est plus adapté au jeu qu'à l'affichage d'interfaces créées avec les composants natifs.

[laurent.fructus]

double bonus pour Google:

- dissuader les programmeurs de maîtriser l'Obj-C
- faire ramer les applis iOS portées ainsi (parce qu'aucune conversion de code n'est optimale), que l'on pourra défavorablement comparer avec leurs équivalents sous Android.

Je ne sais pas si tu développes mais une boucle est une boucle, un test est un test, une affectation de variable une affectation de variable, etc... quelque soit le langage. Donc pour la partie basique des langages, je pense qu'il ne faut pas trop s'inquiéter concernant cette portabilité et la rapidité d'exécution du code (à moins d'avoir une daube comme système sous-jacent).

Reste les appels aux différentes classes d'objets que chaque API propose dans les différents environnements: objective-C et java restent assez proches pour une partie des API standard (strings, arrays, queues, etc...) donc le portage devrait assez simple pour la partie métier de l'application.

De toute façon, ils n'ont certainement pas réécrit toutes les librairies donc ils se baseront sur ce qui existe: si c'est performant au départ, cela le restera à la sortie.

Et sachant que cela ne concerne pas tout ce qui touche l'interface, franchement, il n'y a pas de raison que cela fasse ramer les applications.

Je ne suis pas inquiet à ce sujet...

Laurent

[almux]

Complètement raccord avec la remarque. Aujourd'hui je demande à développer prioritairement pour iOS puis Android. La raison : simple, le panel utilisateur. Les utilisateurs Android se divise en 2 catégories : Ceux qui veulent un smartphone, le moins cher possible. Eux achetent peu voir pas d'applications. Les Geeks qui veulent un terminal "ouvert" qui achetent ou piratent. Les Clients iOS achetent plus facilement des applications, dès lors que leur cout ne dépasse pas 3€. Plus de source de revenu pour le dev CQFD;

... Et Apple de nous sortir un "compilateur inverse", pour "aider" les devs à coder sans crainte d'abord sous iOs. En effet: il sera, alors, toujours possible de vite "émuler" la sauce pour les appareils sous Android...

[duncan]

double bonus pour Google:

- dissuader les programmeurs de maîtriser l'Obj-C
- faire ramer les applis iOS portées ainsi (parce qu'aucune conversion de code n'est optimale), que l'on pourra défavorablement comparer avec leurs équivalents sous Android.

Je ne sais pas si tu développes mais une boucle est une boucle, un test est un test, une affectation de variable une affectation de variable, etc... quelque soit le langage. Donc pour la partie basique des langages, je pense qu'il ne faut pas trop s'inquiéter concernant cette portabilité et la rapidité d'exécution du code (à moins d'avoir une daube comme système sous-jacent).

Reste les appels aux différentes classes d'objets que chaque API propose dans les différents environnements: objective-C et java restent assez proches pour une partie des API standard (strings, arrays, queues, etc...) donc le portage devrait assez simple pour la partie métier de l'application.

De toute façon, ils n'ont certainement pas réécrit toutes les librairies donc ils se baseront sur ce qui existe: si c'est performant au départ, cela le restera à la sortie.

Et sachant que cela ne concerne pas tout ce qui touche l'interface, franchement, il n'y a pas de raison que cela fasse ramer les applications.

Je ne suis pas inquiet à ce sujet...

Laurent

Je ne sais pas non plus si tu développes mais je comprend très bien sa remarque.
Un logiciel ne se résume rarement à une suite de boucle et de test mais contient surtout des appels à des API qui diffèrent d'un langage à l'autre, d'où sa remarque sur les collections par exemple...
Java et C# ont bcp de points communs dans leur conception et pourtant passer de l'un à l'autre n'est pas instantané.

[Faabb]

Complètement raccord avec la remarque. Aujourd'hui je demande à développer prioritairement pour iOS puis Android. La raison : simple, le panel utilisateur. Les utilisateurs Android se divise en 2 catégories : Ceux qui veulent un smartphone, le moins cher possible. Eux achetent peu voir pas d'applications. Les Geeks qui veulent un terminal "ouvert" qui achetent ou piratent. Les Clients iOS achetent plus facilement des applications, dès lors que leur cout ne dépasse pas 3€. Plus de source de revenu pour le dev CQFD;

Je me reconnais tout à fait dans ce que tu dis!
Le prix de 3€ est mon seuil psychologique, mais j'achète très volontiers mes applications sous iOs (et sur le MAS).
Un marché plus grand et plus simple, et des prix plus petits. On s'y retrouve bien!