Débat : Le développement Android, une pléthore de langages et d’outils ?

Je suis d'accord pour une interface graphique qui est plus sympa à utilisé genre labview  . Elle serait plus intuitive et plus lisible pour n'importe quel noob ^^ comme moi .

Je suis d'accord pour un éditeur permettant de déclarer les éléments de l'interface graphique, à condition que le code généré soit clair et classé: déclaration, propriétés, évènements par exemple. Évidement que quelqu'un qui sait coder saurai s'en passer, mais au même titre que quelqu'un qui sait marcher et qui pourtant se sert aussi de sa voiture. Tout simplement car ça va plus vite et que ce qui compte c'est ou on va. Hormis les jeux, la partie importante du code n'est pas celle qui gère l'interface, tout ce qu'on demande à cette partie c'est d'être proprement structurée. Et si un outil nous permet de générer ce code répétitif rapidement, c'est une excellente chose. Donc oui je pense que ce type d'outil doit être mis en place, ça ferait gagner du temps aux programmeurs confirmés et encouragerai les débutants.

+ 1 pour Dream Weaver et son code infecte, mais -1 pour visual studio qui génère un code tout à fait clair en ce qui concerne les éléments de l'interface graphique.

je susi tout a fait d'accord avec toi. le but c'est de ne se concentrer que sur le code et l'archi et pas sur des trucs plus ou moins futiles pour faire roots. moi en tout cas j'ai pas le temps pour.

Monodroid est toujours en développement, et il y a de très fortes chances, d'après ce que j'ai pu lire à droite à gauche, que tout comme MonoTouch, son utilisation soit payante. Moi qui ai une sainte horreur de Java, je me demande vraiment si je serai capable de dépenser pour m'acheter une licence Monodroid :( Après, si je me trompe, je suis preneur de toute information que j'ai pas trouvée :)

Pour les anglophones, voici un poste récent qui fait un petit bilan assez noir de la programmation sous Android: http://www.itsbeach.com/blog/2010/08/developing-for-android.html

Lol... juste Lol.... Eclipse est une sombre merde face à VS2008 (et je ne parle même pas de la 2010) C'est fouilli, bourré d'incohérence... c'est mon cauchemar quotidien, vivement que je change de job...

Les interfaces builder ne sont pas fait pour les débutants, ils sont fait pour gagner du temps dans les taches "cuisines", les tâches répétitives et (selon moi) sans intêret. Un bon interface builder est bijectif et saura donc aussi bien cracher l'xml à partir de la vue que regénérer la vue à partir de l'xml paufiné à la main. On peut écrire 90% de l'xml automatiquement, et affiner les 10% restant à la main. Il n'y a donc pas de rapport avec un quelconque talent de programmation et je ne pense pas que plus c'est "roots" plus ça fait élite, et plus le développeur est doué. Avec l'arrivée des windows phone 7, la productivité d'un développeur qui découvre tout l'ensemble microsoft va tout de même faire pâlir un habitué d'android, c'est certain.

moi j'aimerais bien qu'il y est Python 3.

+1 avec nicolas, mais je n'ai pas encore entendu quoi que ce soit à ce propos malheureusement. Sinon, il y a toujours la possibilité de se créer une petite DSL en langage de script (Ruby ou Groovy sont bien adaptés à cela) pour générer son fichier d'interface en XML.

Pas tout à fait d'accord : J'utilise les deux, ils ne sont pas fait pour la même chose, c'est tout, mais VS n'a pas à rougir...

Monodroid a fait un plugin pour Visual Studio : http://monodroid.net :)

Une librairie de generation de byte-code Dalvik serait bienvenue. Cela aiderait beaucoup a porter d'autres langages de devs. (JRuby, Clojure, Groovy, ....)

tiens un exemple plus parlatn: GIT, le noyau est en ligne de commande et apres tu as pleins de front end ( smartgit, tortoise, git extension...) qui vont chacun avoir leur vision de la chose. apres justement tu peux choisir celle ou celles qui te conviennent suivant tes besoins ou habitudes.

non non yu ne m'a pas comris je ne veux pas faire de .net sous android, je veux jsute pouvoir coder en java ou en ndk sous visual studio, car c'est un outil dont j'ai l'habitude. c'est le meme principe qu'un peintre avec son pinceau, peut importe la couleur de la peinture ce qui fait la difference pour le peintre ca sera son pinceau

Java c'est quand même un des meilleur compromis qui existe. ok on peut avoir du ruby , python et autre truc super funny bien plus dynamique et surtout moins verbeux mais Java + Eclipse y a pas plus productif à mon sens pour le dev et le debugage testing . Je suis pas pour un interface builder poussé. C'est super top pour mocker rapidement les écrans mais pour la gestion des states et compagnie à la flash ca devient vite super compliqué pour pas grand chose ... mon vote : Java eclipse Amelioré le designer xml Revoir les layout managers qui sont vraiement pas intuitifs !!! C'est la galère et irrationnel pour centrer un label sur le millieu d'un écran. Prenez le model swing please ou flex qui est TOP TOP voili voilou

Pour les composants réutilisables, tu as à présent les Android Library Projects. Ils te permettent de faire exactement ca !!

Tu as la solution Mono qui est la seule pour developper sous Unix, cependant ce n'est pas du WPF mais du GTK# ce qui est entierement différent (Pas de XAML...). Renseigne toi sur Mono si tu veux developper en .Net sous Android ;)

Pour moi le nombre de langages est suffisant, par contre ce sont les IDE qu'il faut étendre, à quand un plugin pour visual studio ??? enfin surtout la version express comme ça on garde le cote gratos. y a pleins de gens comme moi qui bossent dessus car on fait du dev windows c++ et c# et qui du coup ont leur habitudes de boulot. Eclipse il m'a fait rager pleins de fois: je compile une erreur, ok je corrige je rebuild et la il me remet la meme erreur car il a un cache a la con qui fait que mon fichier n'est pas recompile... et pleins de trucs cons comme ça... comme pour passer a un autre projet etc etc... j'ai envie de coder sur mon téléphone mais si je doit repasser 30 minutes à chaque fois à retrouver mes marques c'est pas la peine, ma famille me laisse pas assez de temps pour. Je pense que c'est surtout l'environnement de développement qui fait que les gens vont apprécier ou pas, les langages actuels sont suffisament uiniversels et connus pour ça. et faut pas oublier que microsoft lui l'a bien compris, son message envers la communauté de dev est: "vous faites deja du developpement .net ou silverlight ??? ben la c'est la meme chose." sans deconner c'est royal pour le dev s'il n'a pas a se recogner tout pour simplement refaire un projet. donc moi je vote pour un plugin pour visual studio (express si possible) qui je le rappelle peut fonctionner avec n'importe quel langage.

Entièrement d'accord avec ce qui a été dit plus haut (notamment avec r3gis). Cependant, il est vrai qu'un outil de création d'interface serait une bonne chose (je ne parle pas du truc sorti par Google qui permet de faire tout et n'importe quoi sans connaitre un poil de java). Certes, ça ne remplacera jamais l'édition du fichier xml mais si ça peut permettre un gain de temps qu'on peut utiliser dans l'ajout de fonctionnalités, why not. En tout cas, Eclipse convient très bien et remplie sa fonction. Attendons de voir les prochaines versions de Chrome (avec accès au matériel) pour voir apparaitre un nouveau type d'applications (les applis web hors ligne).

je plussoie quand on sait coder un minimum, pas besoin d'un assistant graphique pour designer une interface. ça peut néanmoins être utile pour gagner un peu de temps sur les parties classiques de la création d'interface: choix du layout manager, placement des buttons/TextFields/.... puisque tout cela c'est du code générique qu'on ne peut de toutes façons pas optimiser mais ce n'est pas non plus dramatique que cela soit absent pour le moment.

si je ne me trompe pas, la syntaxe est celle du java, mais la machine virtuelle a été écrite de a à z par google, donc oracle n'a pas son mot à dire dans tout ça. Mais les suites du procès intenté par oracle permettront de savoir à quoi s'en tenir.

Je ne pourrai pas entrer dans le débat sur Eclipse et les IDE par contre j'ai utilisé appinventor et je trouve cet outil vraiment pratique pour quelqu'un de non technique ayant déjà fait un peu de programmation. On s’affranchie des connaissances en programmation grâce à l’interface graphique. Je sais que ça ne vaudra jamais une application codée avec du vrai code mais ça a le mérite d’amener d’autres profils sur la plateforme et peut être que cela créera des vocations. Si on maitrise un peu l'algorithmie avec app inventor on peut réaliser une application pour son téléphone et avoir le plaisir d'utiliser sa création. Pour la suite j'espère qu’il ne sera pas abandonné car j'y vois plusieurs intérêts : Pour les personnes non techniques comme moi on peut créer une application si tant est que l'on connait un peu la programmation et l'algorithmie. Pour une société app inventor peut permettre de faire une ébauche d'application pour un client ou une version démo (light) rapidement. Dans l'éducation cela peut être une première approche de la programmation et permettre par exemple dans une classe de technologie au lycée de proposer une activité en rapport avec les technos d'aujourd'hui. J'espère que le projet continuera à être développé car il y a quelques manques quand même : Il n'est pas possible de faire plusieurs écrans, actuellement l'appli doit tenir dans un écran unique. Une bidouille est proposée dans la faq mais ce n’est pas terrible comme solution. La construction de l'interface utilisateur est limitée, notamment pour le positionnement des objets (boutons, textes,...). On ne peut pas changer l’icône de l’application. Le partage de l’application n’est pas possible sans compte app inventor. Je ne parle pas forcément de publication sur le market mais au moins de faciliter l’échange avec ses amis. La connectivité avec internet pourrait être plus développée. La documentation s'est enrichie par rapport au début ce qui n'est pas un mal :-)

Je plussoie, le truc de base comme designer est vraiment toute pourrite, google est clairement à la masse comparé à tout ce qui se fait ailleurs comme designer (QTcreator, visual studio, monodevelopp, le designer de webos, d'apple etc...) Il faudrait vraiment qu'ils bossent ce point là parce que ça reste un calvaire quand on veut juste faire quelque chose de simple sans se prendre la tête et se plonger uniquement dans le code contrairement à qtcreator et visualstudio par exemple.

Je crois que vous avez oublié Mono qui est compatible Android aussi ;)

@bernard segonnes : exactement, j'avais utilisé le générateur de UI de JBuilder et c'était pas terrible en effet mais mieux que le défunt Visual Café (qu'il repose en paix !). C'est pour ça que j'étais perplexe au début de IB, mais encore, l'approche est différente là : il y a une nette séparation entre le code (ce qu'on tape) et ce que génère IB (des objets "dry" = secs = sur le disque, non encore montés en mémoire).

@Regis : autant en effet j'ai toujours été perplexe envers les outils générant du code pour le layout (ça pose la problématique de savoir ce qui se passe si ce code généré est modifié ensuite à la main, est-ce que c'est reflété dans le layout d'origine ?) car en effet, on peut toujours douter des perfs du code généré. L'approche de Interface Builder est différente : on va setter les propriétés des objets qui va in fine conduire à leur sérialization, donc ce qu'on produit avec IB, ce sont des objets persistés dans un fichier (NIB) et non pas du code qui va être compilé ensuite. Je trouve cette approche bien + pertinente que d'autres que j'ai pu voir par le passé. Sur le sujet : l'outil limite les possibilités : oui bien sur mais le but d'IB n'est pas je pense de faire TOUTE la UI (surtout si on a des trucs tricky). La encore l'approche est bonne : on peut ne décrire que le squelette (les écrans, ceux qui vont potentiellement s'enchainer) et laisser des pans entiers de la UI dans le code et bien avoir la main dessus. Appcreator restera sans lendemain à mon avis, ça reste hyper limité et l'approche web pour ce domaine reste bizarre alors qu'on est sous eclipse pour tout le reste (on peut le comparer à Ares de Palm qui est 100% web et bien plus abouti lui http://ares.palm.com/Ares/about.html ) Même si dans l'absolu on peut se passer d'un editeur de layout, il y a plein d'applis "de base" sur lesquelles un tel outil peut accélérer le dev et c'est bien cela qui est visé là je pense.

L’interface Builder : c'est pour des démo ou présentations vite fait. Cà fera obligatoirement du code (xml & init dans onCreate()) mal foutus et mal optimisé. J'ai l'expérience de JBuilder (et autre produit Borland, Dreamweaver, Word pour HTML, etc...), le code automatiquement généré n'est pas du tout optimisé... impossible pour une machine d'optimiser :-)

La question que l'on peut aussi se poser, c'est est-ce que Google a intérêt a tout miser sur un langage qui dépend d'Oracle. C'est pour cela que l'on devrait voir fleurir d'autres solutions de développement sur Android.

Je suis d'accord avec R3gis par contre :) l'interface Builder ne doit être utilisé que pour gagner du temps, et pas en perdre :)

MDR !! Eclipse orienté Web seulement ?? MDR ! ça se voit que Monsieur Revol ne connait absolument pas Eclipse ! Cet IDE est simplement le plus puissant, le plus flexible et le plus utilisé dans le monde de l'informatique (et je parle même pas de dév Web). Visual Studio, à coté, fait pale figure avec ses versions payantes !

Pour l'interface graphique, je ne suis pas du tout d'accord avec ce qui semble être communement admis. Non, pour moi une interface à la interface builder n'est pas une bonne solution.... a moins que vous ne sachiez pas coder... Ca me fait un peu penser aux gens qui faisait des sites web sur Dreamweaver ou Front Page et qui pensaient savoir faire des sites web... Sauf que au final le développeur n'as aucune conscience de ce qu'il fait et les trois quart du temps ça produit du code horrible et qui aurait bien mieux fallu écrire à la main. A mon sens, on ne peux pas faire des vraies interfaces si on ne connais pas un minimum comment ça marche derrière. Genre faire un widget custo, il est *impossible* de faire ça avec du glisser déposer. Ca va bien pour faire vite fait un squelette mais dès qu'on veut faire quelquechose de joli et optimisé (et ce sur n'importe quelle plateforme, QtDesigner, GTK-Glade, Flash etc etc), ça attend des limites (qui sont les limites de l'outil graphique qui par définition est limité en nombre de widgets à ce qui est fourni dans le sdk). Alors, oui, Android n'a pas un grand nombre de widgets, mais il y a plein de code sous licence apache dans le git android.... Loin de moi l'idée de troller (quoique ;p), mais une fois qu'on sait un minimum coder pour n'importe quelle interface graphique on arrête très vite d'utiliser le générateur d'interface graphique automatique qui est là a mon sens que pour les "débutants". Demandez aux gens qui codent des applications en qt (et pourtant qtdesigner est loin d'être l'outil le plus pourri du monde - ou même en flash dans une moindre mesure car là les outils sont fait pour faire du graphique). Faire un outil qui serait équivalent à ce qu'on peux faire avec du code brut c'est une vraie utopie. Déjà parceque dans les widgets custo d'android on met du code java. Donc je pense que si l'effort doit être fait, c'est pour fournir des projets de widgetings eyecandy compatible depuis la 1.5 jusqu'a la 2.2 ou plus. Mais ça doit être des projets séparé d'android. Ca existe déjà pour le widget QuickAction (dispo dans l'appli contact du git d'android et qui à été forké et réduite par plein de gens), les widget de slidingtab (comme pour délocker le téléphone/prendre un appel), de liste qui se réordonne (appli musique), de mini onglets et j'en passe. Tout ces widgets ne sont pas dans Android de base. C'est regrettable mais la solution mainenant ce n'est pas de developper des IDE usines à gaz mais d'éduquer les développeurs et les outils déjà existant sont très suffisant pour accomplir de belles interfaces sans trop se fouler. Pour moi les propositions qui auraient du sens à faire c'est pas un interface builder, mais ça serait par exemple qu'android supporte le SVG directement dans son widgeting. Ca ça fera vraiment avancé les interfaces graphique comme ça va le faire pour le HTML... ce n'est pas l'éditeur officiel aussi performant soit-ils qui améliorent les choses, mais l'ouverture qui permettent d'utiliser une multitude d'outil adapté à vos besoin... Si vous croyez le contraire, je crois qu'il y a une plateforme parfaire pour ça :p. Donc plutot que de porter l'effort sur l'éditeur graphique qui est une impasse, jpense que l'éditeur xml devrais être améliorer. L'autocompletion qui a encore quelques lacunes, le collapse de code... enfin tout ce qu'on trouve sur les bon vrais éditeur de code html et peut-être un lint pour éviter les oublis (genre les contraintes de layouts pour les widgets de base). Il ne faut pas focaliser sur l'interface graphique, il manque aussi des choses pour l'internationalisation par exemple (là ça aurai un sens d'avoir un interface qui facilite tout ça). Il y a bien des projets qui permettent d'exporter en .pot mais ce n'est pas intégré.

Pléthore ? Il y a tout un tas de projets pour porter des langages sur android, mais à part le Java, rien d'abouti...

Effectivement, développer des écrans sous Android avec les outils actuels est une véritable épopée ! Cela me rappelle les premiers outils qui étaient disponibles sous Visual Studio en XAML. Je pense qu'app Inventor va exister quelque temps avant de disparaître au profit d'autres outils plus puissants. On a déjà assisté à cela sous BlackBerry avec MDS Studio qui permettait de faire des applications natives en quelques minutes sans l'utilisation d'un langage de programmation (à part quelques lignes de JavaScript !) et qui a été abandonné au profit de l'incontournable Eclipse. Il faut effectivement que les outils graphiques Android se mettent au niveau des outils présents sur les plateformes Microsoft et Apple. Les interfaces via XNA et Silverlight et leurs SDK respectifs sont assez impressionnants tant au point de vue de leurs utilisations et du rendu final. Mais comme évoqué plus haut, des EDI vont fleurir ici et là avec des spécifications dédiées aux interfaces, wait and see...

A mon avis : le SDK & Eclipse sont largemenbt suffisant (même si c'est un peut galère le xml pour les écrans, mais on y arrive tout de même). Plutôt que de créer des langages (même pas standard), Google ferait mieux d'optimiser sa machine virtuelle, mettre un JIT dedant, voir comment laisser une limite (16Mo) mais... avec la possibilité de dépasser (si aucune autre grosse applie en cours, et lors de l'execution actuelle. si on relance l'app. l'OS pourrait indiquer manque de RAM par ex., ou killer l'app). Je paufine mon appli actuellement, et en effet quand je la quitte : elle reste en mémoire. Quand je clique sur l'icone pour relancer : la RAM alloué lors de la précédente exécution reste alloué... Si on arrive 'vers' les 16Mo, ce serait bien que l'OS kille tout, et relance proprement..

On n'a pas la même définition de "pléthore"... qu'il n'y ait rien pour développer sous iOS, ca peut se comprendre, c'est verrouillé par Apple. Mais avec Android, il aurait du y avoir un IDE digne de ce nom. Eclipse est clairement orienté Web... Il n'y a aucun designer digne de ce nom, faire des IHM sous Android relève de la galère... Le jour où il y aura un équivalent de Visual Studio, il y aura plus de programmeurs pour Android. Avec la sortie de Windows Phone 7, je parie qu'il y aura rapidement plus de programmes pour Windows Phone 7 que pour Android, à cause de la qualité de l'IDE et de son accessibilité principalement. La tentative française de PCSoft (avec Windev Mobile 15) est louable, mais la version Android est ultra limitée, il faudra au moins 3 ans je pense avant de pouvoir pondre quelque chose de sérieux. L'avantage étant tout de même une accessibilité extraordinaire en terme d'IHM et de code. (Et avec pour désavantage un poids assez élevé des APK)

go m'a l'air très intéressant même si j'aurai préféré qu'il n'inclue pas de garbage collector et laisse le programmeur gérer la mémoire comme il le souhaite ; mais bon à partir du moment où ça n'impacte pas notablement les performances, ce n'est pas un problème. Cependant pour l'instant aucune annonce n'a été faite parlant de son utilisation dans android (ce n'est pas inconcevable de le voir débouler sur cet environnement, mais la syntaxe java a l'avantage d'être familière pour à peu près tous les devs) Google app inventor, j'y crois assez peu... mais bon c'est tout de même une initiative intéressante. Reste le java qui convient pour à peu près toutes les applis à part les jeux gourmands en ressources. Des améliorations seraient les bienvenues sur certains éléments comme les widgets, mais dans l'ensemble ce langage remplit bien son office. Il faut juste que google continue d'améliorer les outils de développement en java et les api associées.

En ce qui concerne Go, ça n'est pas prévu pour android. Ca pourrait très bien tourner dessus, mais c'est un langage plus prévu pour des tâches systèmes, sans interface, donc plutôt du coté serveur. Le fait de pouvoir développer en C/C++ est un point intéressant pour les choses un peu critiques niveau performances (jeux par exemple).

J'ai essayé appcreator et j'ai vraiment bien aimé. Mais ça n'aura réellement d'intérêt que lorsqu'on sera en mesure de développer/distribuer nos propres composants. Sur le plan éducatif, j'ai montré un peu à mon fils, mais il n'a pas d'invitation et son ordinateur n'est pas assez puissant ... dommage. Sinon, coté Eclipse, LE gros point noir, pour moi, c'est l'objet 'R' qui bloque l'utilisation de resources inclues dans des jars. On ne peut donc pas créer de composants réutilisables facilement. Quand je développait en Delphi, il y avait un vrai marché du composant et des tas de sites qui en proposaient, gratuits ou payants. Un mine d'or pour qui développait une application ... Coté autres langages, je pense que chaque nouveau langage sera un plus en permettant à des développeurs autres que Java de s'investir dans la plateforme.

Je suis assez d'accord avec Alvin concernant la pauvreté des outils pour développer des interfaces graphiques, pour moi c'est le gros point noir car taper toute l'interface en xml (je ne rechignerais pas à la modifier un peu cependant) n'est vraiment pas un travail interressant de mon point de vue. J'y vois plutôt une étape rébarbative. Ensuite, j'en étais resté à JNI pour faire des morceaux optimisés en natif, est-ce toujours le cas ? Car Jni, c'est quand même la plaie également (gestion d'objet en C instanciés en java et gérés par le garbage collector java, on ne maitrise plus leur libération, etc.) Enfin, je suis assez d'accord que le modèle de développement de widget pourrait, à défaut d'être simplifié, intégré dans un IDE qui nous cracherait les 3/4 listener, méthodes incontournables, etc. Vans.

Je prefere directement modifier le code xml que d'utiliser les outils fournis, et il faudrait revoir la conception d'interface, il manque la position en fonction des bords et un interface builder. La creation de widget est un enfer, au lieu de creer des nouvelles choses meme pas finies ils devraient se concentrer sur ceux qui existe deja (et aussi eviter les erreur du genre dans Time le weekday retourne a 0 le dimanche alors que le weeknum le lundi)