Découvrons DotNet sur différentes plateformes » Mono for Android

[Mono]Asynchrone Mon meilleur ennemi

Aktaour — Wed, 21 Dec 2011 23:27:57 +0000

Tout fier, je me lance dans ma première application à l’aide de Mono for Android.

Je crée un projet sous Visual Studio 2010 et me munis de mon téléphone sous Android.
Pour les imprimes écrans, j’utilise l’option screen capture du logiciel ddms (dalvik debug monitor) fournit avec le sdk de mono.

L’application à créer est simple:

Ouverture d’une activité à partir d’un bouton
Fermeture de l’activité ouverte
Affichage d’un message à l’écran sur fermeture de la seconde activité.

Dans une application standard, la logique reviendrait à exécuter un écran modal et après la fermeture de l’écran, on afficherait le message. Ce qui donnerai en C#:

void MaLoquique()
{
Form ecran2 = new Form();
ecran2.ShowModal();
MessageBox.Show("mon message");
}

En Mono for Android, cela donnerait:

void MaLoquique()
{
this.StartActivity(typeof(ecran2));
Toast.MakeText(this, "Mon message", ToastLength.Short).Show();
}

Et là surprise… l’activité se lance et on voit le message s’afficher en même temps. Que passa???
En lisant la documentation du Android SDK et en surfant, j’arrive à la conclusion qu’Android est entièrement asynchrone.

Pour ceux qui connaisse un peu Flex, c’est la même « bordel », il faut tout synchroniser dans un evenement global.

Cet événement global est expliqué sur beaucoup de site et cela fonctionne bien pour une petite application qui n’a beaucoup d’écran imbriqué.

Parlons maintenant du synchronise entre deux threads, si un thread doit attendre la fin d’un autre Thread pour continuer son traitement. Comment faire?
Un novice ferait une boucle d’attente comme un while. Les développeurs utiliseront un mutex ou un sémaphore.
exemple: thread1 lance le thread2 et thread1 attends la liberation du jeton du mutex.
Pour celà j’utilise l’objet « AutoResetEvent ».

Pour en revenir à notre application, je vais appliquer ceprincipe sans passer par l’événement global.
Pour cela il faudra créer l’écran2 dans un Thread. En effet si je bloque le mutex dans le thread principal, votre application est figé!
Dans l’écran2, j’ai mis un AutoResetEvent en static

Activité principale:

void MaLoquique()
{
Thread t = new Thread(() =>
{
this.StartActivity(typeof(ecran2));

ecran2.MonMutex.WaitOne();

this.RunOnUiThread(() =>
{
Toast.MakeText(this, "Mon message", ToastLength.Short).Show();
});
});
t.Start();
}

Ecran2:

[Activity(Label = "ecran2")]
public class ecran2 : Activity
{
public static AutoResetEvent MonMutex = new AutoResetEvent(false);

protected override void OnCreate(Bundle bundle)
{
base.OnCreate(bundle);

// Create your application here
}

protected override void OnDestroy()
{
base.OnDestroy();

MonMutex.Set();
}
}

le « RunOnUiThread » sert à intéragir avec le thread de l’activité en cours, néccessaire pour intéragir avec des élément graphiques.

Le miracle opère, le message s’affiche après la fermeture de l’écran2.

Dans le prochain billet, je décrirai un processus plus complet pour passer des variables et les mutex sur chaque activity lancés.

Voici le code source lié à ce billet

[Mono]Asynchrone Mon meilleur ennemi (suite)

Aktaour — Sun, 25 Dec 2011 11:32:59 +0000

Il y a quelques jours j’exposai vulgairement ma façon de développer en ansynchrone entre différentes activity.

Aujourd’hui je vous montre comment faire en mutualisant la génération des mutex et des paramètres passés entre activity.

Pour cela , je crée:

Une classe static nommée BibFrm (Bibliothèque pour les fomulaires) qui contiendra une liste de paramètres liée à chaque activity par un identifiant.
Une classe nommé ParamFrm qui contiendra les paramètres (cle/valeur) de mon activity
Un objet pour accéder de manière unique à mes paramètres (Univers Threadé) nommé mutexParamFrm
Une fonction de recupération de paramètres généric
Une fonction de suppression complète de paramètres
Une fonction d’ajout de paramètres
Une fonction de calcul du prochain identifiant des activity

La génération des identifiants des activity. Noté que l’objet mutexParamFrm sert à locker l’accès interThread a une seul iteration à la fois.

public static object mutexParamFrm = new object();
private static int idFrm = 0;
public static int ProchainIdFrm()
{
int result = 1;
lock (mutexParamFrm)
{
if (idFrm == Int32.MaxValue)
idFrm = 1;
else
idFrm++;
result = idFrm;
}
return result;
}

La classe contenant les paramètres

internal class ParamFrm
{
public string Cle = string.Empty;
public object Obj = null;

public ParamFrm()
{
}
public ParamFrm(string cle, object obj)
{
Cle = cle;
Obj = obj;
}
}

La fonction de récupération de paramètres

public static List recupListeParamFrm(int idFrm)
{
List listeParam = null;
if (listeParamDesFrm.ContainsKey(idFrm)) // récupération de la liste des paramètres par rapport à la clé
listeParam = listeParamDesFrm[idFrm];
else
{
listeParam = new List(); // génération de la liste si non présent
listeParam.Add(new ParamFrm("mutexfrm", new AutoResetEvent(false))); //ajout auto du mutex pour bloquer les activity parentes
listeParamDesFrm.Add(idFrm, listeParam);
}
return listeParam;
}

public static bool recupParamFrm(int idFrm, string nomParam, out T obj)
{
bool result = false;
obj = default(T);
nomParam = nomParam.ToLower();

lock (lockParamFrm)
{
List listeParam = recupListeParamFrm(idFrm);
foreach (ParamFrm paramFrm in listeParam)
{
if (paramFrm.Cle == nomParam) //la cle est toutjours un minuscule
{
result = true;
obj = (T)paramFrm.Obj;
break;
}
}
}
return result;
}

La fonction de vidage des paramètres

public static void viderParamFrm(int idFrm)
{
lock (lockParamFrm)
{
if (listeParamDesFrm.ContainsKey(idFrm))
listeParamDesFrm.Remove(idFrm);
}
}

La fonction d’ajout de paramètres

public static void ajouteParamFrm(int idFrm, string nomParam, object obj)
{
nomParam = nomParam.ToLower();
lock (lockParamFrm)
{
List listeParam = recupListeParamFrm(idFrm);

bool trouve = false;
foreach (ParamFrm paramFrm in listeParam)
{
if (paramFrm.Cle == nomParam) //la cle est toutjours un minuscule
{
trouve = true;
paramFrm.Obj = obj;
break;
}
}
if (!trouve)
listeParam.Add(new ParamFrm(nomParam, obj));
}
}

Pour plus de clareté, je lance l’activité « ecran2″ dans sa propre class par la méthode static Afficher:

public static void Afficher(Activity activity, string titre)
{
try
{
object obj;
int idFrm = BibFrm.ProchainIdFrm();
if (BibFrm.recupParamFrm(idFrm, BibFrm.nomParamMutexFrm, out obj))
{
BibFrm.ajouteParamFrm(idFrm, "titre", titre);

AutoResetEvent a = (AutoResetEvent)obj;
Intent intent = new Intent(activity, typeof(ecran2));

activity.RunOnUiThread(() =>
{
intent.PutExtra("idfrm", idFrm);
activity.StartActivity(intent);
});

a.WaitOne();
BibFrm.viderParamFrm(idFrm);
}
}
catch
{
}
}

Chaque paramètre sera ajouté dans la liste des paramètres customisé. Je ne préfère pas utiliser les Itent car il est impossible de leur passer des objets complexes sans les sérialiser.
L’itent est utilisé uniquement pour sauvegarder l’identifiant de la fenetre.

Dès lors, le thread est bloqué et attends la fermeture de l’activité.
Pour les plus codeurs d’entre vous, vous pouvez mettre tout ce code dans une activité parente et dérivé toutes vos activity de celle ci et le tour est joué.

Bonne fêtes de fin d’année.

Voici le code source lié à ce billet

[Mono]Orientation de l’écran

Aktaour — Mon, 26 Dec 2011 10:11:33 +0000

Sur Android, l’orientation de l’écran influe sur l’affichage des applications.
L’Android SDK offre la possibilité aux écrans de s’adapter à la résolution par ces systèmes de gravité (sorte de point d’ancrage).
Je crée mon application et je m’amuse à la passer du mode portrait au mode paysage.
Cette application se connecte en TCP à mon PC, et rapidement je me suis rendu compte que mon application se comporte étrangement.

En effet, à chaque changement d’orientation, ma connexion TCP se renouvelle. Après plusieurs heures d’analyses et de recherches j’ai compris et résolu le problème.

Par défaut, à chaque changement d’orientation, l’Activity courante est détruite puis recréé par le système Android.
Imaginez ma frustration en constatant cela, où sont mes objets en mémoires -> disparu….

Je connais deux solutions à ce problème:

Surcharger la méthode onRetainNonConfigurationInstance pour en sauvegarder un seul objet. Je dé-conseil ce n’est vraiment pas pratique
Surchager la méthode OnConfigurationChanged

Le fait de surcharger la méthode OnConfigurationChanged et de définir la propriété ConfigurationChanges au Manifeste permet de ne plus redémarrer l’activité courante en cas de changement d’orientation.

TIPs: en java, les propriétés ConfigurationChanges se trouve dans le fichier AndroidManifest.xml du projet. Sous Mono for Android c’est dans l’entête de votre définition de la classe qu’il se trouve.

Exemple:

[Activity(Label = "FrmTest ", ConfigurationChanges=Android.Content.PM.ConfigChanges.Orientation)]
public class FrmTest : Activity
{
///

/// Permet de ne plus redemarrer l'activité sur un changement de configuration
///

///
public override void OnConfigurationChanged(Configuration newConfig)
{
base.OnConfigurationChanged(newConfig);
}
}

Cette petite astuce vous permettra sans doute de gagner du temps :).

Mono for Android

Aktaour — Wed, 21 Dec 2011 21:15:03 +0000

Bonjour,

Je suis passé d’un Iphone à un Samsung Note sous Android 2.3.6, je pars donc à la découverte de Mono for Android.

Pour information, Mono for Android permet de développer des applications en C#. Il est basé sur le runtime Mono et est propriété de la société Xamarin .

L’interface graphique est basé sur les fichiers axml de l’android sdk. Il est donc assez aisé de trouver de la documentation sur la partie graphique sur le site officiel.

Ce qui va m’intéresser pour le moment c’est de comprendre et de détourner la logique du tout asynchrone de l’Android SDK qui pour tout dire m’horripile grandement.
L’application se décompose en Activity, Widget et d’autres choses que je ne connais pas encore.
-Les Activity sont les écrans de votre application.
-Les Widgets sont les composants utilisateurs affichés dans les Activity.

Pour ce qui est du développement, vous écrivez du code .Net en C# dans Visual Studio 2010 ou/et MonoDevelop sous Windows/Linux/MacOSX.

Un émulateur existe pour tester vos applications mais il est extrêmement long à la détente tout du moins sous Windows.
La seule solution pour pouvoir développer correctement est d’acheter une licence de développement (399 euros pour un développeur).
Je sais que c’est cher payé pour développer en C# alors que le développement en Java est totalement gratuit.

La puissance de Xamarin c’est que le code hors écran est compatible sous Iphone/IPad. Il suffit de refaire les écrans de vos applications et de fusionner le code métier sous les différentes plateforme.

En poussant le vice, vous pouvez même avec une certaine organisation étendre cette réutilisation de code sous Windows PC/Mobile/Phone.

Par exemple pour mon entreprise, il y a plusieurs années j’ai porté une application de vente écrite en C# CF (Windows mobile/CE) sous Windows XP. En réorganisant tout simplement l’application, avec une directive de compilation.

Il y a quelques jours, je me suis mis en tête de récidiver en m’attaquant à la plateforme Android. Pour ce faire, j’ai bien évidemment choisi Mono for Android et après 3 soirées, j’ai porté environ 80% du code métier en modifiant moins de 5% de sont code.
Le plus gros changement fut au niveau des requetes vers la base de données. J’ai du retravailler les requêtes et les connexions à la base pour utiliser une base SqLite au lieu de SQLCe database.

Une fois le code données et métier portés, je me suis attaqué à l’interface graphique et la au mon Dieu « tout est asynchrone »

Quel casse tête!

Au fil des entrées du blog, je vous expliquerai comment contourner assez facilement le mode asynchrone pour le rendre synchrone.
Beaucoup d’entre vous me dirons que c’est une hérésie, moi je parlerai plutôt de logique d’application.
Comme je le dis souvent, la simplicité est le maître mot de la durabilité.