Honnêtement, je confirme à 100% ce qui est dit dans l'article : certains capteurs (particulièrement le magnétomètre) sont complètement à côté de la plaque :/

Par contre, trouver le nord à partir du gyromètre, WTF ?!

Voilà un concurrent crédible à Mario Kart sur plateformes mobiles. Pour une fois, il ne s'agit pas d'une énième copie mal faite d'un produit existant, mais il y a véritablement du travail derrière et l'ambiance MK s'y retrouve. Il faudra que je teste...

Nouveau tutoriel Android pour afficher du contenu formaté (code HTML) dans une WebView.

Ça peut paraître simple au premier abord, mais il y a quelques pièges dont il faut faire attention.

Merci Seb ;)

Au passage, je voulais aussi signaler que le lien de téléchargement direct est disponible sur le site.

Je recopie ici mon commentaire :

« Beaucoup ont l'air de dire qu'il faille obligatoirement que les applications soient codées en 64 bits pour qu'elles puissent bénéficier de cette nouvelle architecture. Je ne suis pas vraiment d'accord.

Certes, avec des applications natives, il est impératif qu'elles soient compilées en 64 bits pour exploiter cette architecture. Mais n'oublions pas que sur Android, la grande majorité des applications sont écrites en Java !

Cela implique qu'elles sont compilées sous forme de bytecode qui sera ensuite interprété par la Dalvik VM ; c'est cette dernière qui a pour tâche de générer le code natif et non le programmeur (sauf dans le cas où il fait du code natif, mais ce n'est pas tous les jours).

Par conséquent, je pense que c'est un faux problème : la plupart des applications bénéficieront du 64 bits sans changements, par le simple fait que le code natif est produit par une VM qui, elle, devra supporter cette architecture.

C'est le principe du bytecode : faire abstraction de l'architecture cible et laisser le soin à la VM de faire le boulot de compilation et d'optimisation. »

Quelques astuces pour accélérer l'émulateur Android officiel (d'une lenteur absolument pachydermique - ceux qui n'ont pas testé ne peuvent pas s'en rendre compte).

Visiblement, la meilleure solution consiste à... passer par un autre émulateur, plus complet et rapide !

Mais rien de saurait remplacer un véritable appareil physique ;)

EDIT: Autres astuces dans cette page très complète : http://stackoverflow.com/questions/1554099/why-is-the-android-emulator-so-slow

Ah oui tiens, l'option est apparue dans mon smartphone aussi. On verra si elle fait son office... et ne bloquera pas les applications jugées "indésirables" par Google, mais qui ne le sont pas !

Petit coup de pub pour ce Pokédex pour Android fait par un ami (et collègue de classe) ! Il vient de la mettre en ligne, mais je trouve qu'elle vaut la peine d'en parler ;)

C'est une première version, des nouveautés suivront (c'est prévu), mais elle est déjà suffisamment complète et rapide. L'interface est sobre mais efficace, rien à redire.

Elle ne demande qu'une seule autorisation, pour l'affichage d'un petit bandeau publicitaire discret.

Si vous êtes fan, n'hésitez pas ;)

Je vois une différence toutefois : les programmes Android ne sont pas compilés en langage natif (bien qu'on puisse), mais compilés en bytecode. Ce dernier est interprété ensuite par la Dalvik VM.

A priori, il suffirait de recompiler la VM en 64 bits pour profiter pleinement de cette architecture avec quasiment tous les programmes existants, non ?

Évidemment, il faut aussi que le système soit correctement compilé, ainsi que les différentes bibliothèques. Pour le code natif en 32 bits, il y aurait toujours une rétro-compatibilité.

J'imagine que la problématique est identique sur iOS...

Je garde sous le coude : trouver toutes les mémoires internes et externes sous Android.