mais ca reste souvent "choppes ton json sur le serveur, assembles le, donne ca a manger a l'interface et si le product manager s'est lache, persiste le sur disque.".
Ca fait déjà la moitié qui est indépendant du toolkit graphique. C'est déjà ca.
le plus gros etant le fait de melanger plusieurs langages
Justement c'est l'inverse : un projet multi-OS mobile "classique" conduit à faire de l'objective-C, du Java, du C#. Mono propose un unique langage pour toutes les plateformes.
se taper un compilation des plus relou a chaque modif du core
Pas plus relou qu'avec un projet classique multi-OS mobile.
Le deuxieme inconvenient, on perd (enfin, j'imagine) la possibilite d'utiliser des api natives pourtant bien utiles.
T'imagine justement très mal : ils ont justement fait le choix de ne pas avoir une API qui soit un dénominateur commun, mais de créer des bindings pour l'intégralité des API de la plateforme cible. L'objectif est clairement de ne rien perdre en terme de fonctionnel.
[^] # Re: L'eternelle question
Posté par TImaniac (site web personnel) . En réponse au journal Mono pour Android en version 1.0. Évalué à 3.
Ca fait déjà la moitié qui est indépendant du toolkit graphique. C'est déjà ca.
Justement c'est l'inverse : un projet multi-OS mobile "classique" conduit à faire de l'objective-C, du Java, du C#. Mono propose un unique langage pour toutes les plateformes.
Pas plus relou qu'avec un projet classique multi-OS mobile.
T'imagine justement très mal : ils ont justement fait le choix de ne pas avoir une API qui soit un dénominateur commun, mais de créer des bindings pour l'intégralité des API de la plateforme cible. L'objectif est clairement de ne rien perdre en terme de fonctionnel.