Quelles contraintes dois-je connaître pour optimiser la portabilité du code mono?

En termes d’API, vous obtenez une bibliothèque de classes de base (BCL) très similaire lorsque vous utilisez MonoTouch ou Mono pour Android (M4A), car ils partagent le même profil mobile (qui était basé à l’origine sur le profil Silverlight et amélioré pour utiliser davantage l’API FX 4.0).

C’est beaucoup de code commun. Les différences dans la BCL sont minimes, mais certaines existent, principalement parce que fonctionner sur des appareils iOS nécessite des compromis, ce qui crée certaines limitations .

En dehors de la BCL, MonoTouch et M4A fournissent des liaisons pour leur plate-forme. MonoTouch fournit par exemple monotouch.dll qui lie la plupart des API iOS (basées sur C ou ObjectiveC). Cette partie ne fonctionnera pas sur Mono pour Android (il en va de même pour les liaisons Android fournies par M4A).

C’est là que vous devez concevoir un concept pour minimiser les différences. Dans de nombreux cas, l’aspect le plus différent concerne les interfaces utilisateur. Il existe quelques approches. Beaucoup d’entre elles sont basées sur MVC (par exemple, MonoCross ) afin de simplifier la tâche des développeurs tout en permettant une apparence native pour chaque plate-forme.

En plus de l’interface utilisateur, prenez l’habitude de vous assurer que les dépendances externes ont des variantes qui fonctionnent sur toutes les plates-formes de votre choix, ou soyez prêt à les factoriser.

Pour moi, les pièges étaient:

• Compression – Non disponible dans silverlight, utilisateur sharpziplib si nécessaire (je sais que vous ne ciblez pas silverlight, mais juste au cas où.)
• Sérialisation – Protobuf-net est votre ami.
• Stockage – C’est le plus délicat. Utilisez-vous des entrées-sorties régulières, ou un stockage isolé, ou une chose sur une plate-forme et autre chose sur une autre? De plus, mono.sqlite fonctionne à peu près partout sauf sur silverlight. Allez-y et prévoyez un plan d’urgence pour Silverlight si nécessaire.
• Inventé chez MS – Oubliez ce genre de choses. WCF, structure d’entité, SQL-CE, LINQ to SQL, etc. Mono gère parfaitement les tâches de base .NET, mais est très inégale en ce qui concerne les technologies périphériques, pour lesquelles l’OMI n’a pas beaucoup de valeur.

Cela étant dit, j’ai trouvé que la portabilité était incroyablement simple. En fait, c’était si bon que j’ai pu transférer le code destiné au poste de travail sur mobile en seulement un jour ou deux, bien que je devais ensuite passer beaucoup de temps à l’optimisation. Ce n’est pas parce que le code est portable qu’il fonctionnera de manière identique sur toutes les plateformes! Je pense qu’il est préférable de coder en champ vert sur la plate-forme la plus sensible aux performances, qui, IMO, est monodroïde car elle présente les complications de JIT sur un périphérique mobile, la récupération de place entre ordinateurs virtuels, etc.

Avez-vous essayé le Mono Migration Analyzer (MoMa) ? Ce n’est pas la solution ultime, mais cela pourrait vous assurer une portabilité décente à travers les temps d’exécution Mono.

J’ai utilisé du codage .Net multiplate-forme avec MonoTouch (iOS), Mono pour Android et Silverlight pour Windows Phone 7. J’ai constaté qu’une bonne approche consistait à baser mon code sur le moteur d’exécution Silverlight, car la plupart de ces fonctionnalités sont sockets en charge sur Mono ainsi que.

Si vous souhaitez uniquement cibler iOS et Android, la principale différence entre eux est l’interface utilisateur. Tant que vous restz à l’écart de tout ce qui est lié à l’interface utilisateur, votre code devrait bien fonctionner sur les deux plates-formes.

Il existe une différence majeure entre les plates-formes: sur iOS, votre code est précompilé, le support de la reflection est donc limité. La plupart des choses fonctionnent bien, mais vous devez faire attention à utiliser un code lourd en reflection sur iOS.