Le dilemme du moment...
Le grand interrogation du moment dans le petit monde du développement mobile est le choix des technologies. Il était une époque pas si lointaine, où, il faut bien l'avouer, le développent mobile était guère palpitant et cela n'intéressait pas énormément de gens. La faute à l'absence de 3G et de matériel peu performant certainement, la faute aux apis utilisés peut être aussi : Il y avait bien J2ME, l'api Windows CE, et quelques autres frameworks qui n'étaient pas satisfaisant, ni pour les développeurs, ni pour les utilisateurs : trop de différences entre les implémentations (J2ME), ou standard trop fermé (Windows CE).
Avec le succès de l'iphone, le marché juteux a fait s'intéresser beaucoup de sociétés au développement sur téléphone et beaucoup ont investis dans l'écriture d'applications iphone, pour "être présent sur ce nouveau segment". Jusque là, tout va bien.
Oui mais voilà, android est de plus en plus présent et... ça serait dommage de ne pas être sur ce segment... Sauf que cette fois, tout le monde est un peu plus frileux, faut il réinvestir ? Ne peut-on pas faire des choix plus pérènne qui puisse nous permettre d'être présent sur toutes les plateformes.
HTML 5 au secours du développeur mobile
Il y a bien une solution séduisante : faire un site internet version mobile, adapté à l'utilisation au doigt, aux petites résolutions, et aux connexions internet peu performantes. On a tout de même certaines interrogations :
Avec l'HTML5, je vais pouvoir avoir faire des animations sympas, utiliser la géolocalisation, mais comment vais je faire si j'ai besoin d'utiliser l'appareil photo, les contacts du téléphone, être prévu lors de l'arrivé d'un SMS ? Pour beaucoup, il n'y a pas ces besoins, c'est donc une solution intéressante.
Il y a quelques problèmes cependant :
- Performances pour certains cas d'utilisation (jeux ?)
- Pas présent sur le "market" du téléphone, donc on se prive d'une certaine simplicité d'accès.
- L'application n'est pas réellement "installée", l'utilisateur n'a pas la sensation de s'approprier l'application et ne sait pas trop si ça va fonctionner en mode "non connecté" quand il sera dans la campagne profonde ou à l'étranger sans forfait data par exemple.
- Il n'y a pas de raccourci dans la liste des applications. Il y a les favoris sur tous les navigateurs et la possibilité de créer un raccourci sur le Home sous android mais c'est à l'utilisateur de leur faire et c'est un peu compliqué...
- Ne fonctionne pas en "en tache de fond" donc pas de notifications par exemple.
Qui dit mieux ?
Tout ça, c'est assez gênant il faut bien l'avouer. Il y a plein de frameworks qui émergent de partout pour essayer d'unifier tout ça. Mais standardiser, c'est difficile, il faut trouver le consensus, faire l'unanimité, il faut avoir un certain pouvoir, être écouté.
Je suis suis tombé sur une spécification du W3C au hasard de mes recherches sur internet qui s'appelle Web Widgets. Beaucoup y voit une façon de créer en HTML des petits cadres à incorporer dans un portail, sur un bureau, etc... Cela consiste en un fichier Zip contenant des fichiers html, css, ... avec un fichier xml de description. C'est en quelque sorte un mini site web "offline". Il semblerai que le W3C ait une vision beaucoup plus large de la chose... Et j'y vois un certain potentiel également. Et pourquoi cela ne pourrait pas être des applications pour mobiles ? Dans les W3C Widgets, on déclare des "features", se sont en quelques sortes des "api javascript non standardisés" que l'on s'attend à avoir à disposition lors de l'installation du widget. Voilà une porte ouverte à toutes les fonctions natives, sensors et autres équipements des téléphones.
C'est bien gentil, mais mon SMS, je l'intercepte comment alors ?
Il y a un framework dont l'origine n'est pas le w3c qui semble être parti sur cette piste : Bondi de l'OMTP (Open Mobile Terminal Plateform). A l'origine cela ne respectait pas la norme W3C Widget, ils s'y sont raccroché par la suite. Les gens derrière l'OMTP sont plutôt des fabricants de téléphones et des opérateurs : AT&T, Orange, Vodaphone, Ericsson,... Il y a donc une API javascript (oui, encore une) qui tente de standardisé l'accès aux ressources du téléphone. La techno a l'avantage de permettre d'utiliser du code non spécifique pour 90% de l'application : du html, du CSS et du javascript, le risque est déjà beaucoup plus réduit. Il faut bien l'avouer c'est assez élégant : on imagine par exemple pouvoir utiliser GWT pour générer ses pages html/javascript. Je n'ai pas bien compris s'il s'agissait d'une spécification ou d'une implémentation et éventuellement sur quelles plateformes l'implémentation serait disponible. L'autre avantage est aussi de pouvoir déployer une partie de ses pages "en ligne" sans pouvoir utiliser toutes les fonctions du téléphone et de proposer une version Widget plus évoluée en partageant du code commun.
Dans tous les cas, je trouve la piste intéressante et je suis certains qu'on va en entendre beaucoup parler en 2010 ! Je serai intéressé par créer une petite interface android pour lancer des W3C Widgets basiques en utilisant les bridges java/javascript fournis dans l'appli android et webkit pour voir ce que ça peut donner... peut être le sujet d'un prochain article...
Et vous, qu'en pensez vous, futur flop ou futur standard ?
Pour aller plus loin :
Introduction aux W3C Widgets
BONDI is all beachy with W3C
http://bondi.omtp.org
mercredi 30 décembre 2009
mardi 29 décembre 2009
Ce que Google ne fera certainement jamais...
Google innove et gagne des parts de marché sur tous les terrains. L'enthousiasme (ou au moins l'attention) des internautes à chaque nouvelle annonce est indéniable. Il y a cependant de temps à autre des personnes qui crient au loup et qui décrivent une entreprise à la stratégie quasi machiavélique qui veut tout savoir de nous en aspirant notre vie privée et notre cerveau à des fins dominatrices ou financières. C'est assez différent de l'image quasi altruiste que renvoie à première vue les produits google : gratuit pour les utilisateurs, api ouvertes et open-source pour les développeurs, une volonté de faire progresser internet.
Je me suis dit qu'il était temps pour moi de prendre un peu de recule sur la stratégie de Google et de réfléchir à ce qui ne pourraient pas plaire, à moi ou à d'autres dans les produits google, en raison de la stratégie du "géant de mountain view". La démarche est simple : trouver ce que Google ne fera certainement pas dans un avenir relativement proche car incompatible avec sa stratégie, son "business model".
1. Offrir la possibilité de se connecter à son compte google via openId.
OpenId tend à se démocratiser et permet un Single Sign On décentralisé. Devant le succès remporté par cette solution, les "grands" (Google, MSN, Yahoo) l'adoptent à leur façon. Ils implémentent la partie "provider", c'est à dire la possibilité d'utiliser son compte pour s'identifier sur d'autres sites. Cependant il y a la 2e partie d'openId : pouvoir par exemple s'identifier sur gmail avec le provider openId de son choix... Je pense que cela n'arrivera pas, pas pour les raisons invoquées par google mais parce que gagner la bataille de "qui détiendra l'identifiant numérique de référence des personnes physiques" donne des avantages indéniables.
2. Céder les droits des données communautaires
Indexer les données, c'est le cœur de métier de google. Pourquoi centraliser nos données intéresse google ? Parce que cela lui permet de faire des croisements, des consolidations, des statistiques anonymes, ... bref, de produire une valeur ajoutée lié au volume des informations détenues plus que de la contribution unitaire elle même.
Une des demandes les plus populaires sur le Google Moderator du Google Data Liberation est de clarifier et d'assouplir les droits concernant l'utilisation de google maps comme outil pour créer soit même du contenu. C'est quelque chose de risqué pour google qui n'est pas prêt de céder les droits sur des informations qu'il a parfois consolidé à partir de données d'utilisateurs. Autre exemple, le 3D Warehouse de Google Earth est un service permettant de partager ses modélisations 3D (dont les batiments) fait avec google sketchup. Si j'ai bien lu les conditions d'utilisations du service, Google s'approprie une partie des droits d'utilisation sur les créations. Je pense qu'il est peu probable que Google change cette façon de faire.
3. Permettre d'utiliser les services google avec un stockage en ligne externe à google ou avec cryptage des données.
Il est question d'un service "Google Drive" pour le stockage de vos données. Pour les mêmes raisons que le point précédant, l'utilisation d'un support de stockage en ligne non-google ou le cryptage des données avec une clé non connue de google ne seraient pas compatible avec sa stratégie.
4. Permettre d'installer ses services sur un cloud privé.
Plus d'une entreprise serait intéressée par la possibilité d'installer un gmail sur ses propres serveurs, sur son propre réseau. Qu'est ce qui empêche de passer de Google Apps à une installation des mêmes services sur une infrastructure "cloud" non google ? Les droits d'utilisation des données ou autre chose ? Je ne connais pas les détails juridiques concernant les données pour les entreprises qui passent à Google Apps. Je suis intéressé par vos avis !
5. Proposer des solutions basées sur le peer to peer et la gestion décentralisée.
Opera Unite est un exemple de produit allant à contre courant de la stratégie Google, en proposant à chacun d'héberger son contenu depuis son navigateur web. Est-ce que google proposerai de tels produits ? Je ne pense pas. C'est peut être sur ce type de segment que certaines entreprises peuvent tirer leur épingle du jeu...
Voilà le fruit de ma réflexion. C'est bien entendu totalement subjectif, et j'ai dressé finalement un tableau assez sombre qui ne reflète pas ma vision générale, plutôt positive, des services Google. N'hésitez pas à laisser vos avis et commentaires, je suis curieux de connaitre votre vision des choses !
Quelques liens connexes :
Je me suis dit qu'il était temps pour moi de prendre un peu de recule sur la stratégie de Google et de réfléchir à ce qui ne pourraient pas plaire, à moi ou à d'autres dans les produits google, en raison de la stratégie du "géant de mountain view". La démarche est simple : trouver ce que Google ne fera certainement pas dans un avenir relativement proche car incompatible avec sa stratégie, son "business model".
1. Offrir la possibilité de se connecter à son compte google via openId.
OpenId tend à se démocratiser et permet un Single Sign On décentralisé. Devant le succès remporté par cette solution, les "grands" (Google, MSN, Yahoo) l'adoptent à leur façon. Ils implémentent la partie "provider", c'est à dire la possibilité d'utiliser son compte pour s'identifier sur d'autres sites. Cependant il y a la 2e partie d'openId : pouvoir par exemple s'identifier sur gmail avec le provider openId de son choix... Je pense que cela n'arrivera pas, pas pour les raisons invoquées par google mais parce que gagner la bataille de "qui détiendra l'identifiant numérique de référence des personnes physiques" donne des avantages indéniables.
2. Céder les droits des données communautaires
Indexer les données, c'est le cœur de métier de google. Pourquoi centraliser nos données intéresse google ? Parce que cela lui permet de faire des croisements, des consolidations, des statistiques anonymes, ... bref, de produire une valeur ajoutée lié au volume des informations détenues plus que de la contribution unitaire elle même.
Une des demandes les plus populaires sur le Google Moderator du Google Data Liberation est de clarifier et d'assouplir les droits concernant l'utilisation de google maps comme outil pour créer soit même du contenu. C'est quelque chose de risqué pour google qui n'est pas prêt de céder les droits sur des informations qu'il a parfois consolidé à partir de données d'utilisateurs. Autre exemple, le 3D Warehouse de Google Earth est un service permettant de partager ses modélisations 3D (dont les batiments) fait avec google sketchup. Si j'ai bien lu les conditions d'utilisations du service, Google s'approprie une partie des droits d'utilisation sur les créations. Je pense qu'il est peu probable que Google change cette façon de faire.
3. Permettre d'utiliser les services google avec un stockage en ligne externe à google ou avec cryptage des données.
Il est question d'un service "Google Drive" pour le stockage de vos données. Pour les mêmes raisons que le point précédant, l'utilisation d'un support de stockage en ligne non-google ou le cryptage des données avec une clé non connue de google ne seraient pas compatible avec sa stratégie.
4. Permettre d'installer ses services sur un cloud privé.
Plus d'une entreprise serait intéressée par la possibilité d'installer un gmail sur ses propres serveurs, sur son propre réseau. Qu'est ce qui empêche de passer de Google Apps à une installation des mêmes services sur une infrastructure "cloud" non google ? Les droits d'utilisation des données ou autre chose ? Je ne connais pas les détails juridiques concernant les données pour les entreprises qui passent à Google Apps. Je suis intéressé par vos avis !
5. Proposer des solutions basées sur le peer to peer et la gestion décentralisée.
Opera Unite est un exemple de produit allant à contre courant de la stratégie Google, en proposant à chacun d'héberger son contenu depuis son navigateur web. Est-ce que google proposerai de tels produits ? Je ne pense pas. C'est peut être sur ce type de segment que certaines entreprises peuvent tirer leur épingle du jeu...
Voilà le fruit de ma réflexion. C'est bien entendu totalement subjectif, et j'ai dressé finalement un tableau assez sombre qui ne reflète pas ma vision générale, plutôt positive, des services Google. N'hésitez pas à laisser vos avis et commentaires, je suis curieux de connaitre votre vision des choses !
Quelques liens connexes :
mercredi 9 décembre 2009
Ma nouvelle appli : Google Moderator pour android
Voilà ça y est, j'ai mis en ligne mon appli Android permettant d'accéder à "Google Moderator".
Elle demande encore à être perfectionnée mais l'essentiel est là. Je suis intéressé par vos retours positifs ou négatifs concernant vos essais de l'appli car à force de tester avec mon compte google et mon unique téléphone android, je suis certainement passé à coté de bugs. N'hésitez donc pas à l'essayer et me donner vos remarques, il est gratuit et trouvable sur le market sous le nom "Moderator".
Je suis persuadé que l'appli peut être un apport intéressant pour la plateforme android qui manque encore d'un aspect "social" un peu plus poussé autour du market et de la plateforme en général.
Je suis convaincu qu'une des grandes forces de l'OS android est l'orientation qu'il essaye de donner aux applications en les aidant à communiquer entre elles. Moderator ne fait pas exception et est capable très facilement d'être intégré à une autre application. Tout le monde peut, en quelques lignes de code, rajouter à son application un écran permettant aux gens de proposer des suggestions pour sa propre application.
Si vous êtes développeur voici comment faire :
1) Aller sur le site moderator.appspot.com depuis votre ordi, créer une "series" et allez dans un topic. L'url affichée doit être de la forme suivante : http://moderator.appspot.com/#15/e=10d4fb&t=10d4fc
2) Récupérer la valeur du paramètre "t"
3) Ajouter un élément de menu à votre application qui appelle cette fonction : (y remplacer la valeur du paramètre "t")
Et voilà c'est fait !
Elle demande encore à être perfectionnée mais l'essentiel est là. Je suis intéressé par vos retours positifs ou négatifs concernant vos essais de l'appli car à force de tester avec mon compte google et mon unique téléphone android, je suis certainement passé à coté de bugs. N'hésitez donc pas à l'essayer et me donner vos remarques, il est gratuit et trouvable sur le market sous le nom "Moderator".
Je suis persuadé que l'appli peut être un apport intéressant pour la plateforme android qui manque encore d'un aspect "social" un peu plus poussé autour du market et de la plateforme en général.
Je suis convaincu qu'une des grandes forces de l'OS android est l'orientation qu'il essaye de donner aux applications en les aidant à communiquer entre elles. Moderator ne fait pas exception et est capable très facilement d'être intégré à une autre application. Tout le monde peut, en quelques lignes de code, rajouter à son application un écran permettant aux gens de proposer des suggestions pour sa propre application.
Si vous êtes développeur voici comment faire :
1) Aller sur le site moderator.appspot.com depuis votre ordi, créer une "series" et allez dans un topic. L'url affichée doit être de la forme suivante : http://moderator.appspot.com/#15/e=10d4fb&t=10d4fc
2) Récupérer la valeur du paramètre "t"
3) Ajouter un élément de menu à votre application qui appelle cette fonction : (y remplacer la valeur du paramètre "t")
public void launchModerator() {
try {
Intent moderatorIntent = new Intent(Intent.ACTION_VIEW, Uri.parse("moderator-topic://?t=10d4fc"));
startActivity(moderatorIntent);
} catch(ActivityNotFoundException anfEx) {
AlertDialog.Builder downloadDialog = new AlertDialog.Builder(this);
downloadDialog.setTitle("Moderator App not found");
downloadDialog.setMessage("The free app 'Moderator' is required to submit suggestions.\n" +
"Do you want to go the market to download it ?");
downloadDialog.setPositiveButton("Yes", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialogInterface, int i) {
launchMarketForModerator();
}
});
downloadDialog.setNegativeButton("No", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialogInterface, int i) {}
});
downloadDialog.show();
}
}
public void launchMarketForModerator() {
Uri uri = Uri.parse("market://search?q=pname:net.srcz.android.moderator");
Intent marketIntent = new Intent(Intent.ACTION_VIEW, uri);
startActivity(marketIntent);
}
Et voilà c'est fait !
lundi 7 décembre 2009
L'utilisation de librairies java sur Android - Partie 2 (Classloader)
Certaines librairies utilisent des techniques avancées de chargement dynamique.
Il faut savoir que la compilation de programme android s'effectue en plusieurs étapes :
* .java => .class (classique)
* .class + .jar éventuels => .dex (1 seul et unique .dex pour tous les jars)
* .dex => .apk
Les raisons invoquées par google sont multiples : optimisation pour l'exécution sur des téléphones, gain de place, etc.
Si vous avez besoin du chargement dynamique, tout n'est pas perdu ! C'est possible sur android, sous quelques conditions.
Tout d'abord, vous ne pouvez pas charger un jar "classique". Vous devez le transformer en DEX avec les commandes "dx --dex" puis "aapt add".
Ensuite, vous devez utiliser une api spécifique :
android.dalvik.DexFile df = new android.dalvik.DexFile(new File("test.jar"));
String myClasseString = "com/test/MyClass";
Classloader cl = getClassloader();
Class myClasse = df.loadClass(myClasseString,cl);
Si vous avez des erreurs à la compilation, vous pouvez passer par les apis de réflexion.
C'est cette technique qui a été utilisée pour le portage d'Apache Felix (osgi).
Pour plus d'info cliquez ici
Il faut savoir que la compilation de programme android s'effectue en plusieurs étapes :
* .java => .class (classique)
* .class + .jar éventuels => .dex (1 seul et unique .dex pour tous les jars)
* .dex => .apk
Les raisons invoquées par google sont multiples : optimisation pour l'exécution sur des téléphones, gain de place, etc.
Si vous avez besoin du chargement dynamique, tout n'est pas perdu ! C'est possible sur android, sous quelques conditions.
Tout d'abord, vous ne pouvez pas charger un jar "classique". Vous devez le transformer en DEX avec les commandes "dx --dex" puis "aapt add".
Ensuite, vous devez utiliser une api spécifique :
android.dalvik.DexFile df = new android.dalvik.DexFile(new File("test.jar"));
String myClasseString = "com/test/MyClass";
Classloader cl = getClassloader();
Class myClasse = df.loadClass(myClasseString,cl);
Si vous avez des erreurs à la compilation, vous pouvez passer par les apis de réflexion.
C'est cette technique qui a été utilisée pour le portage d'Apache Felix (osgi).
Pour plus d'info cliquez ici
lundi 28 septembre 2009
L'utilisation de librairies java sur Android - Partie 1 (awt)
Comme vous le savez certainement, l'environnement Android est assez différent de celui qu'on a l'habitude de voir avec J2SE :
- Il ne supporte qu'une partie des API disponibles dans J2SE
- La machine virtuelle est Dalvik.
Je vais tenter de référencer les problèmes auquels on peut s'attendre lorsqu'on tente d'utiliser une librairie java sur android dans une série d'articles. J'ouvre le bal avec AWT :
Eh bien c'est un peu un problème de conception du J2SE : Lorsqu'on souhaite par exemple faire du traitement sur des fichiers d'images (lecture, écriture, redimensionnement, ...), la plupart du temps on utilise ce que nous propose J2SE c'est à dire java.awt.Image...
Si vous tentez de référencer awt dans votre propre code on vous averti gentillement à la compilation.
Si vous avez récupéré directement le .jar de votre librairie, vous pouvez facilement savoir quelles parties de J2SE sont utilisées avec le fabuleux utilitaire jarjar disponible ici
Que faire si des références sont trouvées ?
Certaines classes appellent des fonctions natives de l'interface, dans ce cas, vous êtes fichus. Pour beaucoup d'autres, il n'y a pas d'objection technique à les utiliser, je vous suggère d'extraire ce qui vous intéresse des implémentations opensource OpenJDK ou d'Apache Harmony. Une fois ceci fait, toujours en utilisant jarjar, renommez les références des packages java.awt et java.swing de votre "sous ensemble de jre maison" et dans la librairie.
Etant donné le travail important que cela nécessite, n'hésitez pas partager dans vos commentaires, vos efforts d'adaptations de librairies !
A suivre : Le Classloader et le chargement dynamique...
- Il ne supporte qu'une partie des API disponibles dans J2SE
- La machine virtuelle est Dalvik.
Je vais tenter de référencer les problèmes auquels on peut s'attendre lorsqu'on tente d'utiliser une librairie java sur android dans une série d'articles. J'ouvre le bal avec AWT :
- Références à AWT et Swing interdites
Eh bien c'est un peu un problème de conception du J2SE : Lorsqu'on souhaite par exemple faire du traitement sur des fichiers d'images (lecture, écriture, redimensionnement, ...), la plupart du temps on utilise ce que nous propose J2SE c'est à dire java.awt.Image...
Si vous tentez de référencer awt dans votre propre code on vous averti gentillement à la compilation.
Si vous avez récupéré directement le .jar de votre librairie, vous pouvez facilement savoir quelles parties de J2SE sont utilisées avec le fabuleux utilitaire jarjar disponible ici
java -jar jarjar-1.0.jar find class javamail-1.4.2\mail.jar "%JAVA_HOME%\lib\rt.jar"Avec un pipe et un grep vous trouverez facilement ce qui vous intéresse...
Que faire si des références sont trouvées ?
Certaines classes appellent des fonctions natives de l'interface, dans ce cas, vous êtes fichus. Pour beaucoup d'autres, il n'y a pas d'objection technique à les utiliser, je vous suggère d'extraire ce qui vous intéresse des implémentations opensource OpenJDK ou d'Apache Harmony. Une fois ceci fait, toujours en utilisant jarjar, renommez les références des packages java.awt et java.swing de votre "sous ensemble de jre maison" et dans la librairie.
Etant donné le travail important que cela nécessite, n'hésitez pas partager dans vos commentaires, vos efforts d'adaptations de librairies !
A suivre : Le Classloader et le chargement dynamique...
Inscription à :
Articles (Atom)
