Comme Maxence le précisait dans son article traitant du sujet, les notifications push ne fonctionnent qu’à partir du SDK 8 (2.2). On pourrait se contenter de migrer vers cette version mais on perdrait alors 16% des utilisateurs (contre 40% en février 2011).
Que se passe-t-il exactement ? Sur un device au SDK antérieur, vous aurez l’erreur PHONE_REGISTRATION_ERROR au moment de vous enregistrer au service de Google.

Le problème ne vient pas du code écrit pour s’enregistrer (un simple Intent), ni même de la configuration du manifest (des permissions et un receiver), et pas non plus du code pour recevoir les messages (un BroadcastReceiver).

Tout ceci est disponible dans le SDK 4, et on peut donc le mettre en place sans risquer d’avoir une UnsupportedOperationException. Par contre, afin d’éviter l’erreur à l’enregistrement du device, on va ajouter le bout de code suivant :

if (SysUtils.getSystemVersion() >=  {
	// register to C2DM
}

On n’utilise pas la constante Build.VERSION_CODES.FROYO qui n’est disponible qu’à partir du SDK 8 et donc on utilise sa valeur (8). Cette petite astuce permet de mettre le push à disposition des téléphones récents tout en supportant les téléphones plus anciens.

Support des tablettes

Écrans XL

La logique voudrait que les tablettes soient des écrans xlarge (>= 960dp x 720dp). Dans les faits ce n’est pas tout à fait vrai, il existe des tablettes dans la catégorie large (>= 640dp x 480dp). Google fournit dorénavant la propriété smallestWidth pour déterminer à partir de quelle largeur minimum un layout doit être sélectionné mais ce n’est disponible qu’en version 3.2. Nous avons pris le parti d’utiliser xlarge.

Pour ce faire, vous aurez besoin d’un répertoire layout-xlarge dans les ressources (et éventuellement layout-xlarge-land pour le mode paysage plus fréquemment utilisé pour les tablettes) : aucun problème pour ajouter ce répertoire même dans un projet en 1.6.

Le second point important est la quantité de données à afficher sur un écran de cette taille. On a tendance à regrouper plusieurs écrans en un seul pour profiter de tout l’espace et par conséquent de créer une nouvelle activité. Le problème qui se pose alors est comment réutiliser le code des mes deux, voire trois activités smartphone pour en constituer une seule pour tablette ?

Comme un exemple et un dessin valent tous les blablas, prenons l’exemple d’Appaloosa, notre service de store privé :

Le client Android fournit plusieurs activités pour les smartphones (liste d’applications, détail d’une application et commentaires d’une application) et une seule pour les tablettes. La première chose à faire est donc de choisir la bonne activité en fonction du device. Pour cela on créé une activité de démarrage :

public class LaunchActivity extends Activity {
	@Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);

		Intent startActivity = null;
		if ((getResources().getConfiguration().screenLayout & Configuration.SCREENLAYOUT_SIZE_MASK) >= 4) {
			startActivity = new Intent(this,
					AppListAndDetailActivity.class);
		} else {
			startActivity = new Intent(this, AppListActivity.class);
		}
		startActivity(startActivity);
		finish();
	}
}

Comme pour le push, on utilise la valeur de la constante Configuration.SCREENLAYOUT_SIZE_XLARGE (4) plutôt que la constante elle-même, disponible à partir du SDK 9. Pour le reste, il s’agit simplement de lancer la bonne activité.

Défragmentation des écrans

Concernant le layout, on pourrait se contenter de concevoir un layout adapté mais ce serait dommage d’aborder les tablettes sans faire usage des Fragments. D’autant que Google fournit depuis mars 2011 une librairie de rétrocompatibilité (Compatibility Package) permettant d’utiliser les fragments dans toutes les applications avec un sdk >= 1.6.

Avant la bataille

• res/layout/app_list_screen.xml : layout contenant la ListView des applications.
• AppListActivity.java : contenant le code pour charger la liste des applications (AsyncTask pour l’appel du web service, ListAdapter pour l’affichage des lignes…).
• res/layout/app_detail_screen.xml : layout contenant les différentes info de l’application.
• AppDetailActivity.java : contenant le code pour charger le détail d’une application (divers AsyncTask pour le détail, les screenshots, le téléchargement du binaire…)

Utilisation des fragments

Après découpage en fragments, on a… beaucoup plus de fichiers ! Oui, en effet, mais c’est nécessaire pour éviter la duplication de code. Reprenons chaque fichier un par un :

Déménagement des layout.xml dans les fragment.xml

L’essentiel du fichier app_list_screen.xml se retrouve dans app_list_fragment.xml : la liste, le loading (chargement de la liste), l’empty message (message en cas de liste vide). Ne reste dans le fichier initial que le code suivant (entête et fragment) :

<LinearLayout
	android:orientation="vertical"
	android:layout_width="fill_parent"
	android:layout_height="fill_parent">

	<include layout="@layout/header_layout"></include>

	<fragment class="com.octo.appaloosa.activity.AppListFragment"
			android:id="@+id/appListFragment"
			android:layout_width="fill_parent"
			android:layout_height="fill_parent"></fragment>

</LinearLayout>

Des activités au fragments, il n’y a qu’un pas

AppListActivity.java (après refactoring) ne contient plus grand chose et étends FragmentActivity au lieu d’une simple Activity. Tous les événements onClick restent dans l’activité :

public class AppnListActivity extends FragmentActivity {

	private AppListFragment listFragment;

	@Override
	public void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.app_list_screen);
		listFragment = (AppListFragment) getSupportFragmentManager().findFragmentById(R.id.appListFragment);
	}

	@Override
	protected void onResume() {
		super.onResume();
		listFragment.loadApplications();
	}

AppListFragment.java contient dorénavant le code pour interagir avec la vue, utiliser les AsyncTask pour les web services, etc… :

public class AppListFragment extends Fragment {
	private List<Application> mApplicationsList = new ArrayList<Application>();
	private ListView mApplicationsListView;

	private AppListListener listener = new AppListListener() {
		public void onComplete(List<Application> apps) {
			mApplicationsList = apps
			((BaseAdapter)mApplicationsListView).notifyDataSetChanged();
		}
	};

	public View onCreateView(LayoutInflater inflater, ViewGroup container,
			Bundle savedInstanceState) {
		View view = inflater.inflate(R.layout.app_list_fragment, container, false);
		mApplicationsListView = (ListView)view.findViewById(R.id.applicationListView);
		mApplicationsListView.setAdapter(new AppListAdapter(mApplicationsList, getActivity()));
		return view;
	}

	public void loadApplications() {
		new AppListAsyncTask(getActivity(), listener).execute();
	}
}

Le mécanisme est assez proche d’une activité, les termes changent un peu (onCreateView au lieu de onCreate par exemple). Par ailleurs, il existe un fragment tout fait pour les listes (ListFragment), que nous n’avons pas utilisé car le layout contenait un peu plus qu’une simple liste (loading notamment).

La version tablette

Je vous épargne l’écran de détail qui est basé sur le même principe pour aborder l’écran tablette qui cumule la liste et le détail. app_list_detail_screen.xml est donc relativement simple puisqu’il utilise les mêmes fragments que les smartphones :

<LinearLayout
  	android:orientation="horizontal"
  	android:layout_width="fill_parent"
  	android:layout_height="0dp"
  	android:layout_weight="1">

  	<fragment class="com.octo.appaloosa.activity.AppListFragment"
		android:id="@+id/appListFragment"
		android:layout_weight="1" android:layout_width="0dp"
		android:layout_height="fill_parent"></fragment>

	<fragment class="com.octo.appaloosa.activity.AppDetailFragment"
		android:id="@+id/appDetailFragment"
		android:layout_weight="2.5" android:layout_width="0dp"
		android:layout_height="fill_parent"></fragment>
</LinearLayout>

Faire le bon choix

Un point intéressant à regarder est l’action d’un click sur un élément de la liste. En effet, si on se trouve dans le cas du smartphone, on lance l’activité de détail (AppDetailActivity). Si on se trouve dans le cas de la tablette, on charge le détail dans le fragment associé :

public void onItemClick(AdapterView<?> parent, View view, int position, long id) {
	AppDetailFragment detailFragment = (AppDetailFragment) getFragmentManager().findFragmentById(R.id.appDetailFragment);
	if (detailFragment == null) {
		Intent intent = new Intent(getActivity(), AppDetailActivity.class);
		intent.putExtra("application", mApplicationsList.get(position));
		startActivity(intent);
	} else {
		if (detailFragment.getCurrentApplication() == null || detailFragment.getCurrentApp().getId().equals(mApplicationsList.get(position).getId()) == false) {
			detailFragment.loadApplicationDetail(mApplicationsList.get(position));
		}
	}
}

Au final, on a beaucoup plus de classes et de fichiers, mais les fragments (java + xml) sont réutilisables, ce qui nous permet d’envisager toute sorte d’interface et surtout envisager les tablettes, voire les TV…

Conclusion

En l’état actuel des choses, il possible de couvrir un spectre de SDKs relativement large (1.6 -> 4.0) et un spectre d’écrans complet (small -> xlarge) avec une seule application. Toutefois, Google fournit la possibilité de proposer plusieurs apk pour une même application, par exemple si la version tablette contient des images HD assez lourdes que l’on souhaite épargner aux smartphones…

On dit souvent qu’Android est fragmenté (je ne le nierai pas complètement) mais cet article démontre que malgré la multitude de devices (qui fait aussi la richesse de la plateforme), on peut adresser 99% des utilisateurs sans trop de difficultés.

La sortie récente de Android 4.0 (Ice Cream Sandwich) promet de réunir les développements tablettes et smartphones mais en attendant d’avoir un parc conséquent d’appareils basés sur cette dernière mouture, il faudra continuer a jouer d’astuces pour cibler le plus grand nombre d’utilisateurs.

Je suis donc heureux d’annoncer le lancement de Metroide ! Si vous l’avez téléchargé et que vous trouvez des bugs, écrivez moi à metroide dot android at gmail dot com.

Si vous ne l’avez pas encore installé, c’est ici pour la version complète :

Et ici pour la version lite :

Sur métroide (mon application de calcul d’itinéraire de metro pour Android), j’ai un grand nombre d’images pour toutes les lignes du métro (+rer et tram) que je dois afficher dynamiquement sur l’itinéraire.

Comme un exemple vaut mille paroles, exemple :
J’ai l’itinéraire suivant : nation (« m1″: ligne 1 du métro), porte d’italie (« m7″).
Je vais donc avoir besoin des images R.drawable.m1 et R.drawable.m7. Mais je n’ai qu’une chaine de caractère pour spécifier le nom de l’image. J’aurais aimé faire un truc du genre R.drawable["m1"] ou R.drawable.get(« m7″)… mais malheureusement, ce n’est pas possible. Je dois avouer que pour le concours SFRJTD, je n’ai pas poussé plus loin mes recherches et j’ai fait un switch en découpant ma chaine (m1 -> m et 1, donc m me dit metro, 1 ligne 1, je prend donc R.drawable.m1)… berk !

Cette solution ne me convenant pas et n’ayant pas trouvé de réponse à ma question, je me suis dit : « tant qu’a faire crade, pourquoi ne pas faire de l’introspection ? » Et c’est comme ca que j’ai réduit un switch de 40 lignes en 5 lignes comme ceci :

try {
	Field f = R.drawable.class.getField(line); // line = "m1" ou "rb" ou "t3"...
	return f.getInt(null); // class static et champs static dans R, on peut laisser à null
} catch (Exception e) {
	return R.drawable.empty;
}

Je ne suis pas encore complètement convaincu et je me dis que j’ai du me prendre la tête à faire compliqué alors que c’est prévu dans le SDK. Si tel est le cas, je suis preneur de vos solutions…

Android, kezako ?

Pour ceux d’entre vous qui ne lirait jamais les news (comment êtes vous tombé sur mon blog ?!), Android est le système d’exploitation pour plateformes mobiles développé par Google. Dans les faits, Google a racheté une société qui avait conçu la première version d’Andoid mais peu importe. Android est donc un OS pour appareils mobiles (téléphones, dont le HTC Dream chez Orange et le HTC Magic chez SFR; netbooks; archos…).

A l’OS, s’ajoute un SDK (actuellent en v1.1, bientôt 1.5) permettant à tout un chacun de développer ses applications pour l’OS… à ceci prêt qu’il faut connaître le langage Java mais si vous fréquentez mon blog, je suppose que c’est le cas.

Un environnement de développement aux petits oignons

• Tout d’abord, gros avantage, c’est du Java ! Mine de rien, les développeurs Java, c’est pas ce qu’il manque aujourd’hui sur le marché et on peut donc espérer une grosse activité de développement. Est ce le bon choix d’avoir pris un langage qui n’est pas réputé pour sa rapidité d’exécution ? Peut-être pas… toujours est-il que si Google veut rattraper le nombre d’applications déjà développées sur l’Iphone, ça me semble être une bonne stratégie.

• Ensuite, il existe un plugin Eclipse (ajoutez cette adresse à vos updates Eclipse : http://dl-ssl.google.com/android/eclipse/). Là encore, la communauté Eclipse est à ce jour la plus importante comparé à Netbeans et IntelliJ. Encore un bon point pour toucher le plus grand nombre de développeurs. Avec le SDK, est fourni un émulateur pour tester vos applications sans pour autant avoir à acheter un téléphone. Le lancement de l’émulateur est pris en charge dans Eclipse, c’est donc un réel plaisir que de développer pour la plateforme. Je regrette juste la lenteur de démarrage de l’émulateur…

• Le SDK en lui-même est d’une simplicité assez déconcertante, tout du moins pour qui connaît déjà Java. La doc est relativement claire, le SDK est fourni avec quelques exemples mais surtout, on peut en quelque lignes manipuler google maps, récupérer les coordonnées GPS, utiliser la liste de ses contacts (cf partie suivante)… En tout cas, on trouve pas mal d’infos partout sur le web : forum anddev, google groups, …

Code snippets

Récupérer la position GPS actuelle

Dans le manifest, il faut ajouter les permissions suivantes :

Dans votre activité, vous aurez un code ressemblant à ça :

Criteria criteria = new Criteria();
criteria.setAccuracy(Criteria.ACCURACY_FINE);
criteria.setAltitudeRequired(false);
criteria.setBearingRequired(false);
criteria.setCostAllowed(true);
criteria.setPowerRequirement(Criteria.POWER_LOW);

LocationManager locationManager = (LocationManager) getSystemService(Context.LOCATION_SERVICE);
String provider = locationManager.getBestProvider(criteria, true);
Location currentLocation = locationManager.getLastKnownLocation(provider);
locationManager.requestLocationUpdates(provider, 100, 100, locationListener); // si on se déplace de 100 m (vérification toutes les 100 millisecondes)

// ...

private final LocationListener locationListener = new LocationListener() {
	public void onLocationChanged(final Location location) {
		currentLocation = location;
	}

	public void onProviderDisabled(final String provider) {
		currentLocation = null;
	}

	public void onProviderEnabled(final String provider) {
	}

	public void onStatusChanged(final String provider, final int status,
			final Bundle extras) {
	}
};

Attention, si le GPS n’est pas activé, vous aurez des erreurs, notamment le provider sera null et getLastKnownLocation plantera lamentablement.

Pour tester, vous pouvez émuler une position. On est censé pouvoir le faire depuis eclipse mais perso, ça n’a pas fonctionné. J’ai donc utilisé la méthode geek :

telnet localhost 5554
geo fix 2.305114 48.869321

Afficher une map et dessiner dessus

Pour afficher la map (Google maps), c’est relativement simple, il y a une Activity et une View toutes prêtes. Dans votre fichier myMap.xml, vous aurez :

Remplacez le KEY HERE par une clé fournie par google à partir du keystore de votre sdk (plus de détails ici).

Dans le manifest, sous la balise application, vous aurez :

Enfin dans le code java :

public class MapLines extends MapActivity {
   @Override
	public void onCreate(final Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.myMap);
		MapView mapView = (MapView) findViewById(R.id.map_view);
		Overlay overlay = new MyOverlay();
		mapView.getOverlays().add(overlay);
	}

	private class MyOverlay extends Overlay {
		@Override
		public void draw(final Canvas canvas, final MapView mapView) {
			GeoPoint myPoint = new GeoPoint((int) (48.858563 * 1E6),
					(int) (2.347204 * 1E6));
			Point point = new Point();
			mapView.getProjection().toPixels(myPoint, point); // transforme les coordonnées GPS en position x/y sur l'écran
			RectF oval = new RectF(point.x - 2, point.y - 2, point.x + 2, point.y + 2);
			canvas.drawOval(oval, paint); // dessine un rond à la position souhaitée
		}
	}
}

Bien entendu, vous pouvez dessiner autre chose que des ronds, des carrés… vous pouvez mettre des images par exemple.

Récupérer les contacts

Là encore, c’est très simple. Dans le fichier manifest, vous déclarez la permission :

Ensuite, dans votre code, pour récupérer par exemple les noms des contacts :

String[] columns = new String[] { People.NAME };
Cursor cursor = getContentResolver().query(People.CONTENT_URI, columns, null, null, People.NAME);

String[] contacts = new String[cursor.getCount()];
if (cursor.moveToFirst()) {
	int i = 0;
	do {
		contacts[i++] = cursor.getString(cursor.getColumnIndex(People.NAME));
	} while (cursor.moveToNext());
}

Vous pouvez ensuite les mettre dans un spiner ou une liste :

ArrayAdapter contactAdapter = new ArrayAdapter(MainSearch.this, android.R.layout.simple_dropdown_item_1line, contacts);
AutoCompleteTextView textView = (AutoCompleteTextView) findViewById(R.id.edit);
textView.setAdapter(contactAdapter);

Et voilà !!

Mon humble participation

Concours SFR Jeunes Talents

SFR a annoncé il y a un mois le lancement d’un concours de développement d’applications pour Android afin de faire connaître la plateforme et surtout pour annoncer l’arrivée de l’HTC G2 (qui se fait attendre…). C’est à cette occasion que je me suis lancé dans le développement d’une application qui à défaut d’être originale, sera d’une grande utilité pour tous ceux qui habitent Paris (dans un premier temps et n’importe quelle ville où il y a un métro à terme). Vous l’aurez compris, il s’agit d’une application gérant les itinéraires en métro !

Metroide

Metroide, c’est son nom, permet simplement de calculer votre itinéraire en métro depuis n’importe où (station, contact, adresse, favori et position gps courante). L’avantage est qu’il n’a pas besoin de connexion internet pour calculer un itinéraire de station à station (aucune connexion au site de la ratp).

En effet, toutes les stations et tous les liens sont dans l’application (au format XML pour l’instant), et j’ai implémenté l’algorithme Dijkstra pour calculer le plus court chemin, donc le meilleur itinéraire entre deux points.

Par contre, si vous utilisez les autres options, elles font toutes appel au GeoCoder pour transformer l’adresse en coordonnées GPS et donc là, une connexion internet est requise.

Trève de blabla, voici la présentation que j’ai soumise au concours SFR :

Ainsi que la vidéo de l’appli :

J’ai encore un peu de boulot pour rendre le tout plus joli (notamment les favoris), et beaucoup de boulot pour saisir les stations de RER / tramway et trains de banlieue. La version actuelle sera mise à disposition gratuitement sur l’android market et je verrai pour passer à une version payante (1 ou 2 €) quand elle sera plus aboutie.