Hier, était organisée à Marseille, la « Nuit du Mobile 2.0″. Cette nuit du mobile, qui commençait en réalité le matin, à 9h 9h45 a été riche en information sur les solutions et services mobiles.

La nuit du mobile peut-être comparée à un mini World GSM, dans lequel on ne parle pas spécifiquement « matériel»  mais plutôt des tendances du marché en terme de besoins, services, logiciels…
Lors de cette journée/soirée, qui s’est terminée tard dans la nuit, la même question m’a été posée à plusieurs reprises: Android va-t-il devenir fragmenté?

Cette question a été levée pour deux raisons principales:
- un OS/Framework que tout le monde peut modifier à souhait
- des matériels différents (smartphones, netbook, GPS, lecteur multimédia…)

De ce fait, les professionnels se posent la question à savoir si Android va devenir comme J2ME. Non pas dans les performances, mais plus dans la complexité de gérer les mulitples versions disponibles en fonction des matériels.

L’exemple de J2ME est flagrant. Une même application a besoin d’être codée et compilée quasiment pour chaque téléphone puisque les possibilités matériels ne sont pas les mêmes et que les machines virtuelles sont plus ou moins différentes en fonction de son hôte. On retrouve du J2ME sur des features phones, smartphones, constructeurs X ou Y, qualités des puces utilisées différentes, processeurs différents, tailles d’écran différentes… Des sociétés sont aujourd’hui spécialisées sur le domaine, en créant des frameworks permettant de générer x applications à partir d’un seul code source en fonction des téléphones cibles (ex.: Mobile-Distillery).

Le dernier HTC Hero Sens annonçé, la semaine dernière, a bien montré une personnalisation Android, jusqu’alors jamais démontrée « publiquement» , de l’interface graphique et des librairies disponibles dans le téléphone. Le fait que ce téléphone ne soit pas estampillé « With Google» , comme ses grands frères HTC Dream, HTC Magic, montre bien qu’il y a une démarche de détachement de HTC vis à vis de Google…

Que se passerait-il si HTC décidait, par exemple, d’utiliser Android sur un de ses matériels en supprimant par exemple, les applications standards de Google (Contacts, Calendrier…)? Comme fonctionneraient certaines applications exploitant ces services?

Cette hypothèse parait tout de même peu probable: Android = Google…du moins pour le moment.

L’hypothèse la plus vraisemblable surviendrait plutôt du matériel! Même si Google requiert dans ses spécifications techniques un certain minimum pour la création du matériel, on peut observer des zones de risque. Concernant l’écran Android parle d’une résolution minimale de 2″8 mais rien n’est dit sur le touchscreen. Si demain, un constructeur commercialisait (cela va venir, puisque c’était le cas du Kogan Agora) un téléphone non touchscreen que se passerait-il pour les applications n’implémentant que le touchscreen: une réimplémentation nécessaire du code et donc plusieurs versions à gérer pour le développeur (coût!), un crash, une perte de marché?

La question reste ouverte…Cette fragmentation est-elle possible? Si oui, est-ce que cela va nuire à l’impact d’Android? Google Android doit-il imposée un contrôle des matériels disponibles ou alors renforçait ses spécifications? Seront-elles suivies et adoptées?

… c’est maintenant possible. David Turner, qui était présent à l’Android DevCamp (y’a-t-il un membre de l’équipe Android qui ne parle pas français ?!?) a publié aujourd’hui un billet indiquant la mise à disposition du kit de développement natif d’Android.

Ce kit permet d’ajouter du code natif (pour le moment ARMv5TE) à votre application afin d’en optimiser certaines routines. Ceci est particulièrement intéressant pour tirer parti des capacités graphiques des processeurs.

Il ne sera pas possible de développer des applications Android entièrement native mais seulement d’ajouter du code natif à une application Dalvik.

Nous savions que l’une des stratégies de Google pour pouvoir financer ses investissements sur la plateforme Android serait d’intégrer de la publicité.

Aujourd’hui, Google a entamé sa stratégie puisqu’il est désormais possible pour les développeurs d’intégrer de la publicité dirctement dans ses applications.

L’Android Market regorge d’applications affichant un bandeau publicitaire sur lequel l’utilisateur peut cliquer. Ce service est proposé par AdMob. Il faudra maintenant, également compter sur Google Adsense.

Rappelons que AdSense permet au développeur qui l’utilise de se faire un peu d’argent à chaque fois qu’un utilisateur clic sur une annonce. Le service est également disponible pour iPhone.

Ce cour tutorial va vous expliquer comment utiliser la Carte SD dans vos développements.

Le première chose à savoir est qu’Android voit la carte SD comme un dossier dans l’arborescence Linux. Ce dossier se situe à la racine. Le chemin est donc /sdcard/.

Par défaut, l’émulateur est un téléphone sans carte SD donc la première étape de ce tutorial consiste en la création d’une carte SD.

Pour ce faire, ouvrez une console (sous Windows, démarrer -> exécuter « cmd.exe ») et tapez la commande suivante :

mksdcard -l label 8192M <chemin>/SDCard

Note : Si votre console vous répond que l’exécutable est introuvable, c’est que vos variables d’environnement ne prennent pas en compte le dossier tools du SDK. Soit vous rêglez le problème en suivant le tutorial d’installation, soit vous vous rendez dans le bon dossier pour taper votre ligne de commande (sous Linux il faudra alors la faire précéder de « ./ »).

8192M représente 8Go de données. Cela peut donc prendre du temps. Vous pouvez bien entendu utiliser un autre chiffre. SDCard sera le fichier image de votre carte SD.

L’outil mksdcard ne permet malheureusement pas de remplir l’image de la carte SD avec des fichiers. Nous allons donc utiliser l’émulateur pour cela.

Démarrez l’émulateur à partir de la console avec la ligne suivante :

emulator -sdcard <chemin>/SDCard

L’émulateur devrait démarrer et s’initialiser.

Note : Il peut arriver que l’émulateur refuse de démarrer de cette façon. Dans ce cas, lancez Eclipse, faîtes un nouveau projet Android et exécutez le en prenant bien soin de préciser dans la configuration la ligne de commande. Cette étape sera détaillée peu après dans le tutorial. L’émulateur devrait démarrer

Ouvrez maintenant une autre ligne de commande et utilisez la ligne suivante : lire la suite…

Ce tutoriel permet de découvrir l’utilisation de l’accéléromètre mais peut être étendu à tout les capteurs du téléphone de façon assez simple car tout les capteurs sont accessible de façon similaire dans Android.

Commençons par créer un nouveau projet de type Hello World :

public class bla extends Activity {

    /** Called when the activity is first created. */

    @Override

    public void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        setContentView(R.layout.main);

    }

}

Maintenant, pour avoir accès à l’accéléromètre, nous allons récupérer le « handler » du service système correspondant :

SensorManager m = (SensorManager) getSystemService(Context.SENSOR_SERVICE);

Ensuite, il va falloir, grâce au handler « m », enregistrer une classe chargée de recevoir les évènements liée à l’accéléromètre.

En effet, les capteurs sont accessibles sur un mode asynchrone.

D’abord créons notre classe capteur :

class capteur implements SensorListener{

    public void onSensorChanged(int sensor, float[] values) {

    }

};

Le nom de la méthode à écrire est assez explicite. C’est elle qui sera appelée par le système lorsque les valeurs du capteur visé vont changer.

Dans le cas de l’accéléromètre, on cherche les valeurs des forces s’exerçant sur l’axe des x, des y et des z :

class capteur implements SensorListener{

    float x, y, z;

    public void onSensorChanged(int sensor, float[] values) {

        x = values[0];

        y = values[1];

        z = values[2];

    }

};

Maintenant que nous avons cette classe, la première chose est de l’instancier dans notre « Activity » :

private capteur accelerometre;

Puis, nous allons l’enregistrer auprès du gestionnaire de capteur, et du même coup spécifier que nous voulons l’accéléromètre (et pas le magnétomètre, ou autre). Pour ce faire, dans notre méthode onCreate, rajoutons ceci :

m.registerListener(accelerometre, SensorManager.SENSOR_ACCELEROMETER);

Voilà, nous avons l’essentiel. A vous de donner un contenu à la fonction onSensorChanged pour créer des actions en fonctions des mouvements du téléphone.

Pour autant, afin de conclure ce tutoriel, voici le code qui permet d’afficher les valeurs des forces :

public class hello extends Activity {

private capteur accelerometre;

@Override

    public void onCreate(Bundle savedInstanceState) {

String txt = new String();

TextView tv = new TextView(this);

accelerometre = new capteur();

super.onCreate(savedInstanceState);        

        SensorManager m = (SensorManager) getSystemService(Context.SENSOR_SERVICE);

        m.registerListener(accelerometre, SensorManager.SENSOR_ACCELEROMETER);

        txt = « X : «  + accelerometre.x;

        txt = txt + « \nY : «  + accelerometre.y;

        txt = txt + « \nZ : «  + accelerometre.z;

        tv.setText(txt);

        setContentView(tv);

    }

}

class capteur implements SensorListener{

    float x, y, z;

    public void onSensorChanged(int sensor, float[] values) {

        x = values[0];

        y = values[1];

        z = values[2];

    }

};

Pour « compiler », pensez à faire un ctrl+maj+o pour qu’Eclipse complète les dépendances avec les « import » qui vont bien.

Les valeurs retournées par l’accéléromètre sont exprimées en G. Sur l’émulateur, l’accéléromètre renvoie 0, 0, 0 soit aucune force (apesanteur ou chute libre).

En tant que partenaire de Frandroid et membre actif, eXpertise @ndroid se devait de faire un petit quelque chose pour l’ensemble des lecteurs de Frandroid mais aussi pour ceux qui maintiennent ce blog, les forums, le site jobs….

Bref, vous pourrez trouver sur l’Android Market pour votre téléphone (ou autre) équipé d’Android 1.5 Cupcake, le Widget Frandroid qui vous permettra d’être prévenu dès qu’une news parait sur le site. Un clic sur la news vous permettra d’accéder au contenu de l’article en ouvrant un navigateur.

En espérant que cela vous sera utile (si au niveau graphique vous avez des choses à redire, n’hésitez surtout pas à faire à apporter vos idées.

Le télécharger c’est par ici (Android Market)

Update 6/6/2009: version 1.2 chargement toutes les 2 minutes des dernières news et affichage en boucle dans le widget des 5 dernières…

On en parle sur le forum

Moblin, dont on vous avait déjà parlé est un système d’opération basé sur Linux pour netbooks. De nombreux constructeurs ont d’or et déjà choisi de le proposer par défaut avec leur machines (dont ASUSTeK). Le choix des consommateurs va donc être assez large entre Windows XP (en fin de vie), Winfows 7 (arrivée en octobre), Android (de nombreux netbooks en seront équipés), et Moblin d’Intel.

Moblin 2.0 en phase bêta

Après Canonical qui développe des solutions pour faire tourner les applications Android sur Ubuntu et d’autres distributions Linux, c’est Intel qui devrait permettre à l’Android Market de pouvoir être installé sur son système Moblin.

Les conséquences sont évidentes, Android va pouvoir profiter d’un déploiement plus important et Moblin d’une logithèque adapté à la mobilité… mais l’effet pourrait être inverse avec un court-circuit entre les deux systèmes sur netbooks, car Moblin pourrait devenir un vrai produit de substitution pour Android.

C’est Anand Chandrasekher, Vice Président de la branche mobilité d’Intel, qui a présenté des applications Android tourner sur Moblin 2.0.

Moblin est maintenant supervisé par Linux Foundation dans sa phase de développement, et Intel a encore augmenté son financement…

Plus d’informations sur le site de Moblin

Eric Chu, le responsable Android chez Google, vient d’annoncer le lancement de l’Android Developper Challenge version 2 (ADC 2).

L’Android Developer Challenge est un concours international ouvert à toutes les personnes, entreprises, associations…qui ont des idées de développement d’application pour la plateforme Android et les réalisent…avec plus ou moins de succès.

Google avait lancé son premier ADC en novembre 2007: plus de 1700 applications avaient été soumises (souvenirs!) et 50 applications avaient été récompensées avec des gains atteignant 250000$.

• Pour l’ADC2, les juges seront également les utilisateurs qui pourront noter les applications afin d’en sortir le TOP10!
• 2 rounds
• 10 catégories d’applications (vie sociale, jeu, education, réseaux sociaux…)
• 20 gagnants par catégories (pour le premier round)
• 1 application développée par Google permettant de tester aux utilisateurs de tester les applications soumises de manière aléatoire.
• Gains: de 25.000 à 100.000 pour les 3 premiers de chaque catégories pour le premier round, puis de 25.000 à 125.000 pour le second tour.
• Date de soumission: debut juillet
• Date de fin de soumission: mi-aout
• Compte rendu des juges mi-octobre
• Compte rendu final mi novembre
• Qui participera…? Bonne chance par avance!

Plus de détails par ici.