Envoyé par
jmini
+1 est ce que ca veut dire qu'ils vont porter CocoaTouch (je ne suis plus certain du nom du Framework MVC d'Apple) pour que ca soit compatible avec MeeGo ?
Est ce que c'est pas le genre d'opération que Novell fait avec Mono (vis a vis du framework .Net).
Ce que je ne comprends pas non plus c'est qu'une application iPhone peut être compilée pour une archi intel: il est possible de compiler une appli pour le simulateur qui mache sous mac os x. Il me semble qu'on obtient un genre de Binaire X86 a faire touner sur son mac...
Il est clair que le problème essentiel se situe au niveau des frameworks Apple présent sur iOS.
Intel n'a pas le droit de les convertir et de le revendre ou même mettre à disposition gratuitement les versions converties, donc ils devront - comme Mono pour .Net ou GnuStep pour Cocoa - réécrire en "clean room" des frameworks compatibles iOS pour leur plate-forme. Et donc aussi investir dans la maintenance de ces frameworks…
(on leur souhaite bien du plaisir avec la couche Mach-O sur laquelle est basée toute l'IAC… mais on aussi peut parier qu'ils vont éviter ce problème-là et qu'ils annonceront que les applications iOS qui appellent directement les fonctionnalités Mach-O ne seront pas supportées… or il suffit dans une application d'interroger l'OS pour connaître la mémoire libre pour tomber dans ce cas de figure…)
Parmi les gros problèmes qui vont se poser, il y a ceux générés par les applications iPhone qui utilisent fortement les interactions avec les applications standards de celui-ci : Intel n'ayant pas le droit de convertir celles-ci : quid ?
Est-ce que c'est outil ne fonctionnera "bien" que pour les jeux à 99% en OpenGL-ES et "peu" pour les applications fortement liées à iOS ?
Parmi les plus petits problèmes, il y a évidemment tout ce que les développeurs auront par trop lié à l'environnement : les tailles et résolutions d'écran, la présence d'autres applications, de ressources "System" comme des icones, sons, etc.
Les applications elles ne pourront être converties avec cet outil que par leurs auteurs et ayant droits.
Quiconque s'amuserait à convertir l'application ou le code d'un tiers pour en faire commerce sans l'autorisation des ayants droits se fera lyncher (juridiquement parlant)… et cela vaut aussi pour Intel vis-àvis des frameworks Apple qui font d'iOS ce qu'il est…
Quant au simulateur présent sur Mac OS X, sa fonction essentielle est de fournir le bridge entre les APIs iOS et celles de Mac OS, le fait qu'il fonctionne en code x86 est secondaire, il pourrait aussi fonctionner en PowerPC, c'est juste le choix d'Apple de ne plus supporter celui-ci pour les outils de développement iOS. (et la cross compilation est une fonctionnalité de gcc…)
Les technologies d'émulation, conversion "on the flight" de code de processeur à processeur ne sont pas nouvelles… (Wine, Rosetta, VirtualPC, les JVM avec JIT, …) mais dans le cadre d'objet mobile, il y a quand même plus de probabilités que l'on aura affaire à un convertisseur statique, donc une conversion préalable qui se fera sur une plate-forme desktop…
Ce qui sera intéressant d'observer, c'est si Intel va au bout du raisonnement et offre ces outils de conversion sur Mac OS X (un outil à activer sous forme de Build phase dans Xcode avec un simulateur Intel adapté à leur plate-forme mobile) - ce qui aurait une logique puisque le public visé est celui des développeurs iOS, ou au contraire n'offre les outils de conversion que sur sa plate-forme de développement pour mobile (on peut présumer que ce seront des outils Windows-only)…
De toute façon, dans les 2 cas, il faut que le développeur ait accès à un simulateur pour tester le résultat de la conversion…
0 |
0 |
Que pensez-vous d'un tel utilitaire : très bonne idée ou complètement farfelue ? 
