Il semble que pas mal de choses bougent du côté de Google et plus particulièrement de l’Android Market.

L’un des derniers changements est que, dorénavant, une application sur l’Android Market pourra se décliner sous la forme de différents APK selon le téléphone de l’utilisateur.

Un APK, pour rappel, c’est une archive contenant l’ensemble des ressources applicatives et media nécessaires à l’exécution d’une application. Techniquement, en fait, c’est tout simplement votre application.

Auparavant, je cite Eric Chu, toutes les applications contenues sur l’Android Market se composaient d’un APK unique, un medium universel disponible pour tout les terminaux éligibles quelque soit la version de l’OS, la taille d’écran ou le processeur du terminal.

C’est là d’ailleurs tout l’esprit de Java, le langage de programmation utilisé pour développer une application Android. Personnellement, j’ai toujours pensé que Google serait fidèle à ce principe et limiterait autant que possible ce qu’on appelle la fragmentation.

La fragmentation, c’est lorsqu’une application ne fonctionne pas d’un terminal à l’autre non pas en raison d’impossibilité technique (différence de version, périphérique optionnel manquant, etc.) mais parce que certaines fonctionnalités essentielles du système sont différentes ou manquantes par rapport à d’autres terminaux. C’est ce qui petit à petit a tué J2ME, la plate-forme Java pour mobile qui se devait d’être universelle mais qui, à l’époque des Symbian, Windows Mobiles et autres OS aujourd’hui sur le déclin, était complétement différente d’un téléphone à l’autre (y compris lorsqu’ils étaient de la même marque).

Le nombre d'exécutables pour une seule et même application au temps de J2ME

Lorsqu’un système est destiné à être librement implémenté par qui le veut, on s’expose forcément à la fragmentation. Un constructeur peut parfaitement oublier des éléments essentiels de l’OS, soit à dessein, soit par mégarde. Pour éviter cela, l’Open Handset Alliance documente précisément ce qui est le miminum légal pour Android. Ne subsistent donc normalement que les écarts de conduite involontaires des constructeurs (ou opérateurs).

Ces erreurs d’implémentation d’Android rendent parfois la tâche difficile aux développeurs d’application. Soit.

Ainsi, Google, qui gère l’Android Market, permet aux développeurs de faire différents APK pour une seule et même application, en fonction du terminal ciblé. Ceci, cela dit, ne touche que quelques aspects de la dite-application : textures, ressources media, etc.

Ce n’est donc pas ce qui va permettre à un développeur de prendre réellement en compte les petites différences entre deux terminaux Android qui sont dûes à un problème d’implémentation.

Mais en terme d’image, là, j’ai un problème. Il y a déjà une floppée d’agences de « développement » qui pensent que développer pour Android est trop coûteux à cause des bugs des différents terminaux. Ces dernières ne jurent que par des frameworks de développement croisés iPhone-Android qui génèrent, le plus souvent une application Android au design iPhone. Ces entreprises là ne cessent de critiquer Android sur des points tout à fait faux.

Est-ce là la réponse de Google ? Admettre que certains terminaux sont trop à part pour qu’une application Android ne soit pas compatible avec certains terminaux Android ? D’un point de vue communication, ça risque de vraiment mal passer et de se rajouter à la longue liste des arguments erronés contre Android.

Au final, le message que Google envoie, c’est : oui, ma plate-forme est fragmenté, il faut faire plusieurs développements pour une seule application. Peu importe que cela soit vrai ou non.

Ce message arrive à un moment où énormément d’acteurs mobiles (souvent à la culture iPhone) s’imaginent que le développement Android est un chemin jonché d’embûches avec des bugs inexplicables seulement sur certains terminaux.

La réponse de Google devrait plutôt être de mieux contrôler les terminaux ayant accès à l’Android Market. Apple exige de valider chaque application une par une sur iTunes, pourquoi Google n’exige pas de réellement valider l’implémentation d’Android sur un terminal avant de lui donner accès à l’Android Market ? Je suis quasiment certain que le nombre de bugs serait moindre !

Opera Software est connu pour ses navigateurs. On les retrouve sur de nombreux plateformes Windows, Mac OS X, GNU/Linux… mais aussi sur les systèmes mobiles comme Android, ou iOS. Mais l’entreprise se lance dans un nouveau domaine : un marché d’applications (MarketPlace). Contrairement à un AppStore, il regroupe plusieurs plateformes à la fois. Ici, il s’agit d’Android, Blackberry, Java, Palm, Symbian et Windows Mobile. Seule une version web est proposée, ce qui permet un accès plus simple. La solution n’est pas propre à Opera, mais appartient à Appia (anciennement connu sous le nom de PocketGear).

Le contenu provient de plus de 32 000 développeurs et supporte plus de 200 pays et même 2 000 téléphones différents. La plateforme se différencie des Market classiques, sur plusieurs points :

• Ce n’est pas un store, mais un Marketplace de plusieurs boutiques. A l’heure actuelle, aucun AppStore ne se ressemble. Appia souhaite donc en créer un seul qui mélange plusieurs plateformes, afin d’avoir une expérience unique.
• Il y a à la fois des applications gratuites et payantes. Le modèle est particulièrement intéressant pour les développements, car il propose le paiement in-app, la publicité et la facturation de leurs applications. L’intérêt est d’avoir une seule plateforme pour toutes les architectures.
• Plutôt que de vendre sous le nom d’Appia, ce sont des partenaires (comme Opera) qui distribuent le contenu.

Selon la langue, le terminal et même la monnaie, le MarketPlace s’adaptera en proposant des applications dédiées. Depuis le mois de février, les chiffrent parlent d’eux mêmes. Il y a eu 15 millions d’utilisations pour 700 000 téléchargements par jour. Pour Opera, l’intérêt est à la fois de faire grandir la plateforme, mais surtout de récupérer des commissions.

Pour avoir rapidement navigué dans le store Android, le contenu semble intéressant. Cependant, les applications sont directement livrées sous forme d’apk. Cela signifie que si une mise à jour intervient, vous n’en serez pas tenu au courant.

Si vous voulez tester ce Marketplace, rendez vous sur ce lien (fonctionne également depuis un ordinateur).

Source : TechCrunch

Aujourd’hui Android réussit son parcours, grâce à l’Android Market et ses nombreuses applications. La boutique n’atteint pas encore le nombre d’applications de l’Apple App Store, mais la plateforme distance largement les autres concurrents. Une telle variété d’applications est très intéressante pour les plateformes, car elle permettrait de grossir leurs catalogues. Android est open-source et grâce à cette philosophie, les concurrents vont pouvoir virtualiser les applications.

En essayant de rester simple, les programmes Java utilisent une machine virtuelle, c’est-à-dire un environnement d’exécution pour ces programmes. Sur Android, elle s’appelle Dalvik. Vous pouvez remarquer que de version en version, le système de Google est de plus en plus rapide, car de grosses optimisations sont faites sur cette partie.

L’entreprise Myriad a annoncé Alien Dalvik, qui est une machine virtuelle capable de lancer des applications Android, mais sur des téléphones normalement non compatibles. Cette société ne vous est peut-être pas inconnue, car il y a un an, elle lançait Dalvik Turbo, une machine capable d’exécuter les programmes trois fois plus rapidement, tout en améliorant l’autonomie. Depuis, Google a rattrapé son retard et offre aujourd’hui un très bon compromis.

Dans l’introduction, j’ai parlé de virtualisation. Ce mot vous semble peut-être inconnu, mais voilà un exemple simple de mise en oeuvre. Vous avez un ordinateur sous GNU/Linux et malheureusement un logiciel ne fonctionne que sur Microsoft Windows. Deux solutions s’offrent à vous : redémarrer votre machine ou virtualiser le système Windows. Le principe est de lancer sur une machine hôte (ici votre Linux) un ou plusieurs systèmes d’exploitations, sans qu’ils ne s’aperçoivent qu’ils sont en réalité sur une autre machine. L’avantage est que vous profitez de vos différents systèmes simultanément, sans qu’ils s’interfèrent. L’inconvénient est qu’avec un tel système, vous devez posséder un processeur suffisamment puissant, pour qu’il puisse gérer les OS.

Dans le monde mobile, cette technologie permet d’améliorer la sécurité et fiabilité des systèmes d’exploitation. Les applications sont cloitrées dans des unités qui n’intéragissent pas directement avec le système. Les données de l’appareil sont ainsi protégées. ReadWriteWeb Mobile donne un exemple très simple. Vous avez certainement entendu qu’Obama utilisait un BlackBerry. Cela est possible uniquement parce que les applications sont verrouillées de telle sorte que les menaces extérieures soient bloquées. Pour les utilisateurs lambdas, l’intérêt est de pouvoir lancer des applications d’un système à l’autre, de manière totalement transparente.

Myriad Alien Dalvik permet actuellement de lancer des applications sur les téléphones Maemo. Alors que ce système est quasiment abandonné, les perspectives pour Meego sont importantes. Cet OS est encore à ses balbutiements et un tel apport pourrait l’aider dans un premier temps. Pour résumer, les appareils auraient à la fois accès aux applications Nokia, via l’Ovi Store, mais aussi à celles de l’Android Market. Il faut toutefois nuancer, car tous les programmes Android ne sont pas totalement compatibles, notamment en ce qui concerne ses performances. Si vous lancez un jeu comme Dungeon Defenders, il est fort probable que même en ayant un périphérique avec un matériel tenant la route, il n’arrive pas à l’exécuter de manière fluide. La société montre une vidéo sur un N900, un téléphone sur le système Maemo :

Maemo était un système que Nokia avait réalisé seul. Puis Intel avait de son côté lancé Moblin OS. Ces deux entités ont fusionné pour donner Meego. Les premiers téléphones sur cet OS mobile pourraient arriver prochainement. Cette machine virtuelle semble pour l’instant réservée à des systèmes Nokia, mais Myriad dévoilera officiellement ses objectifs au MWC.

Source : ReadWriteWeb Mobile

Par l’intermédiaire d’un communiqué de pressse, nous avons appris qu’Oracle portait plainte contre Google pour la violation de brevets concernant Java, qui auraient été utilisés pour développer Android.

Oracle qui a racheté Sun Microsystems l’année dernière, possède en effet la technologie Java et ses brevets associés. La plainte affirme qu’Android viole au moins 7 de ces brevets. Les reproches portent sur l’utilisation de Java à la fois dans le système d’exploitation Android, le SDK Android, et la machine virtuelle Dalvik.

Quel rapport entre Java et Android ? L’ensemble des applications est développé dans le langage de programmation Java. Bien que le code soit optimisé pour fonctionner sur une machine virtuelle propre à Google, nommée Dalvik, l’ensemble du système (système d’exploitation Android + machine virtuelle Dalvik) reprend des parties du système Java. L’attaque d’Oracle concerne donc la reprise de ce code, ne respectant pas les brevets et licences propres à Java.

Google n’a pas encore réagi aux accusations, n’ayant pas encore eu le temps d’examiner le dossier.

On notera quand même, qu’Eric Schmidt, l’actuel CEO de Google, a dirigé le développement des technologies Java chez Sun Microsystems pendant plusieurs années. Oracle affirme donc que  Google aurait violé les brevets « en connaissance de cause et de façon répétée ».

Le document officiel décrivant les violations est disponible ici.

Quelles pourraient être les solutions (bien que cela va déboucher sur un long procès…) :

- un gros chèque de la part de Google pour Oracle ?

- une répartition de la vente des logiciels entre le développeur, Oracle et Google ?

- une modification du système Android pour ne plus exploiter Java ? (et là, les développeurs ont du souci à se faire, ainsi que l’ensemble de la solution Android)

- une disparition d’Android ? (là on n’y croit pas ! )

Donnez votre avis sur le sujet !

Selon Wikipedia : Le Linpack est un benchmark informatique qui sert au classement des plus puissants superordinateurs du monde dans le TOP500. Créé par Jack Dongarra, il mesure le temps mis par un ordinateur pour résoudre un système de n équations à n inconnues dense, la solution étant obtenue par une utilisation partielle du pivot de Gauss, par 2/3·n³ + n² opérations à virgule flottantes. La performance est ensuite calculée en divisant le nombre d’opérations par le temps mis, donc en FLOPS.

Vous pouvez installer et tester Linpack sur votre androphone en l’installant à partir de l’Android Market. Après test sur mon HTC Desire sous Android 2.1, j’obtiens 6,7 MFLOPS comme résultat, alors que sur le HTC Hero le résultat est de 2.

Pour le Nexus One sous Android 2.2, le résultat est tout bonnement… époustouflant. Sur la capture publiée on remarque que le Nexus One a atteint 37,6 MFLOPS voir même plus de 40 MFLOPS. Soit 4,5 fois plus que le HTC Desire sous Android 2.1. Le ToP10 de Linkpack fait apparaître ses résultats jamais atteints sous Android. Le gain de performance est du au nouveau compilateur JIT (Just in Time), déjà disponible dans l’AOSP, ses performances et sa stabilité laissaient jusqu’à présent à désirer.

Bref, Android 2.2 promettrait un gain de performance remarquable qui a sûrement été l’objectif premier de Google avec l’arrivée de la technologie Flash très gourmande. Vivement le Google I/O…

Source : Standroid

Il y a des langages sur lesquels nous travaillons afin de porter leur bytecode pour la Dalvik VM, donc il ne sera pas question seulement du langage Java.

On pouvait le supposer, ou bien sinon le prévoir, au moins le prédire, Android va s’ouvrir à d’autres langage de programmation que le Java.

Cette citation est tirée d’une des réponses de Jason Chen lors des Google I/O. C’est d’ailleurs une phrase qui est confortée à plusieurs moment puisque Jason Chen insiste sur le fait qu’Android n’est pas une technologie Java et que la Dalvik VM n’est pas une machine virtuelle Java.

S’il on ne sait pas encore quels autres langages seront supportés par Android (C/C++, Python, ou même C# sont probablement les plus à mêmes de faire partis des langages choisis), il apparait maintenant très clair que le choix du langage Java n’existe pratiquement que pour attirer à Android tout les développeurs mobiles qui sont déjà très à l’aise avec cette technologie.

Les autres langages supportés auront eux probablement pour rôle d’amener les développeurs du monde PC vers le développement Android.

Rien de ce qui contribue à la diversité ou la fragmentation d’une plate-forme n’est dans l’intérêt [des développeurs]

Depuis maintenant quelques mois règne un étrange silence sur la planète Java mobile (J2ME). Ce silence vient d’être rompu par Rich Green, vice président exécutif de Sun. Et le message est clair, si l’entreprise à l’origine de Java n’est pas en colère, elle est en revanche inquiète pour sa technologie et les conséquences que les choix de Google sur Android entrainent.

En effet, inutile de le rappeler Android, ce n’est pas du Java, mais ça se programme en Java.

Par conséquent, Sun est particulièrement ennuyé de voir une sorte de nouvelle machine virtuelle arriver sur le marché car son objectif avec la technologie Java est de respecter le précepte « Write once, run everywhere ». C’est-à-dire que le même code doit pouvoir s’exécuter sur toutes les plate-formes Java.

Pour autant, Google assure quant à lui qu’Android n’est pas un problème pour ce principe, mais bel et bien la solution. Cette réponse vient du constat que la plupart des programmes J2ME ne sont plus, et depuis longtemps, « Write once, run everywhere ».

Cela étant, Android est-il lui-même à l’abri d’une fragmentation ?

Il est vrais, que les ralentissements constatés sur l’émulateur n’aide pas à évaluer la performances de nos applications.

Le guide aborde les points suivants :

• Avoid Creating Objects
• Use Native Methods
• Prefer Virtual Over Interface
• Prefer Static Over Virtual
• Avoid Internal Getters/Setters
• Cache Field Lookups
• Declare Constants Final
• Use Enhanced For Loop Syntax With Caution
• Avoid Enums
• Use Package Scope with Inner Classes
• Avoid Float
• Some Sample Performance Numbers

Update
Nous aimerions remercier Aissen pour ses précisions :
Pour comparaisons, voici un certain nombre de recommandations pour le développement sur J2ME/JME. Vous y trouverez des informations similaires et complémentaires.

Chapter 10, Performance Tuning
Chapter 3, « Programming Strategies for Small Devices, »
http://developers.sun.com/mobility/midp/articles/garbagecollection2/
http://developers.sun.com/mobility/midp/articles/garbage/
http://developers.sun.com/mobility/midp/articles/threading2/index.html

Rassurez-vous, cela ne pourrait être qu’une mauvaise passade. En effet, Sun vient d’annoncer le développement d’une version de JavaME pour l’iPhone. Cette version sera distribuée gratuitement sur l’Appstore et permettra d’exécuter des applications Java a priori téléchargées de n’importe où.

Eric Klein, vice-président du marketing Java chez Sun a déclaré que qu’ils allaient faire en sorte que le maximum de fonctionnalités natives de l’iPhone soient implémentées et accessibles. La machine virtuelle devrait être disponible dés le mois de juin.

Pour rappel, un projet de machine virtuelle de type JavaME existe aussi pour Android, comme nous en parlions ici.