Apple pourrait faciliter le développement de « webapps natives »

Anthony Nelzin-Santos |

Depuis plusieurs mois, les ingénieurs d’Apple travaillent activement au développement d’un nouveau bridge Objective-C / JavaScript. Cette nouvelle API répond à deux demandes récurrentes des développeurs iOS et OS X : pouvoir appeler du code Objective-C depuis JavaScript et inversement pouvoir appeler du code JavaScript depuis Objective-C de manière « simple ».




Impact permet de concevoir des « jeux HTML5 et JavaScript », notamment sur iPhone et iPad.


Francisco Tomalsky, le développeur de Cappuccino, explique qu’il s’agit d’une évolution de WebScriptObject et de WebScripting qui se situe au niveau de JavaScriptCore plutôt que de WebKit. Autrement dit, ce n’est pas une nouveauté, mais cette API devrait désormais être plus facile à utiliser pour les développeurs. Du moins quand elle sera utilisable : elle est pour le moment « cachée » dans les entrailles de WebKit et considérée par Apple comme une API privée.



Nigel Brooke de Steamlock Software explique que cette API permet de faire interagir JavaScript et Objective-C en se chargeant du transtypage : appeler du code Objective-C depuis l’interpréteur JavaScript, lire le contenu d’une variable JavaScript avec de l’Objective-C… Autrement dit encore, elle facilite l’utilisation de « composants web complexes » dans une application native. Une pratique assez commune dans les développements multiplateforme comme les jeux utilisant le moteur JavaScript Impact ou les webapps se reposant sur Cordova.



Reste à savoir non pas quand, mais si Apple publiera cette API, c’est-à-dire s’il est dans son intérêt de favoriser les « webapps natives » alors que des partisans de cette approche comme Facebook ou LinkedIn ont fini par passer au natif. Les frameworks tiers facilitant la conception de ces applications hybrides ne manquent pas et peuvent peut-être suffire à donner le change.



[Via @siracusa]


avatar @MathieuChabod | 
Oh non pas ça ... Quand on voit les améliorations qu'ont données le changement en natif pour Facebook, on peut pas facilité la création en HTML5 ...
avatar damiendu83600 | 
Vivement la WWDC qu'on reparle un peu d'Apple , parceque la c'est que de Google qu'on parle ...
avatar Jean-Jacques Cortes | 
@chabodmathieu Le problème avec les applications natives est qu'elles doivent être écrites en Objective-C, ce qui ne facilite pas le portage sur d'autres plateformes. Il faudrait autoriser un autre langage comme le C++ par exemple.
avatar Ajioss | 
Quand je vois le sort qu’a réservé Apple à sa page consacrée aux webapp : http://www.apple.com/webapps/whatarewebapps.html je doute de l’issue d’une telle initiative...
avatar Armas | 
Ca, pour moi, ca sent clairement la tentative de rebouchage de brèche de la barque IOS pour contrecarrer la montée d'Android.
avatar pol2095 | 
html5 serait vraiment une daube alors ? pour qu'il faille passer par du code natif
avatar Jiminy Panoz | 
"Quand on voit les améliorations qu'ont données le changement en natif pour Facebook, on peut pas facilité la création en HTML5 ..." Oui enfin faut aussi dire que niveau html5, facebook avait aussi fait de la grosse merde. D'ailleurs, linkedin est passé au natif pour une raison principale, et ça a été dit par leur responsable : l'absence d'outils pour html5. Facebook a quand même réussi à se faire humilier par sansha, une petite boîte qui avec deux devs en quelques semaines a proposé une webapp facebook mille fois plus performante que l'app officielle, pour justement prouver à facebook que leur problème venait davantage de leurs devs et leur façon de coder n'importe comment que de html5... Mais bon, c'est même plus la question aujourd'hui, vu que les raisonnables s' accordent à dire qu'on va vers une complémentarité web app + app native.
avatar Ikari | 
@Jean-Jacques Cortes Rien ne vous empêche de publier une application iPhone en C ou en C++. Il y a même des outils pour les faire en Ruby …
avatar oomu | 
le code natif est toujours supérieur à du code interprété en terme de vitesse (évidemment) et d'intégration dans la plateforme (par définition). Mais du code interprété/managé apporte certaines flexibilités. Mais voulons nous vraiment cette flexibilité ? Déjà qu'il faut se méfier des bugs de safari au cas où une escaladation de droits soit possible Avec du code natif, il faudra aussi se méfier des bugs du processeur. Je pense toujours que simplifier l'exécution de code binaire depuis internet est une erreur. C'est une jolie erreur pour l'ingénieur, c'est beau et pratique. C'est une catastrophe pour l'utilisateur à terme. (faille de sécurité, perversion/dévoiement de la plateforme). Du code binaire chargé depuis le net est essentiellement une boite noire -- "Le problème avec les applications natives est qu'elles doivent être écrites en Objective-C, ce qui ne facilite pas le portage sur d'autres plateformes. Il faudrait autoriser un autre langage comme le C++ par exemple. " en quoi c'est un problème pour Apple ? c'est même carrément un avantage. Non, il ne faut pas "autoriser" C++ D'abord, il est "autorisé". Si vous avez un compilateur/environnement de développement basé C++ qui génère du code pour le runtime Objective C alors ça passe. Notons au passage que cela n'est pas si facile : Objective C est compatible C. Par nature : objective C est une extension de C. Objective C n'est PAS compatible C++. C++ est un dérivé de C, mais il n'est plus du C. Objective C a été une force pour Apple, pas un boulot. En 15 ans le nombre d'applications Objective C a _explosé_. Ce n'est pas sans raison. Objective C et Cocoa sont plus que liés, ils sont fondamentaux l'un à l'autre. Le runtime Objective C met en oeuvre des concepts de base sur lesquels Cocoa est bâti. en gros: ils vont ensemble et Xcode met en oeuvre cette synergie. Du coup, quand on dit "objective C", on parle surtout de la force de cocoa. et Cocoa va bien au delà de C++/lib standard c++/QT/MFC/etc.
avatar oomu | 
Ce que demande Apple, et pour de solides raisons dont nous profitons tous, c'est que des apps sur ios soient conçues pour la plateforme applicative COCOA (donc le runtime objective C en dessous). Apple ne veut pas se retrouver comme pour Os X responsable de maintenir la compatibilité des applications de tierces parties avec des plateformes applicatives de tierces parties (en vrac: java, qt, silverlight, flash, python, ruby, etc) chaque fois qu'elle veut améliorer ios et proposer de nouveaux usages. Apple veut pouvoir faire progresser IOS et Xcode sans considération pour les plateformes de concurrents. ET que les développeurs soient du coup incités à suivre les "merveilleuses nouveaux outils" de Cocoa du nouvel ios. Steve Jobs avait été très clair sur comment la dépendance à une plateforme applicative d'une autre entreprise est un danger pour Apple. Son propos se tient encore en 2013. - Cela est aussi vrai pour Os X, où tout serait nettement + simple s'il suffisait d'ajouter à Cocoa le support des Versions de Documents pour que PAF ! Photoshop ou Office le gère aussi, d'un coup, magique. Apple lentement, se débrouille pour rendre Cocoa _nécessaire_ sur Os X.
avatar joneskind | 
@Armas : D'où ça sort ? De quelle "brèche" tu parles ? IOS est toujours le terrain de jeu préféré des développeurs et le marché qui leur rapporte le plus. La majorité des devs développent d'abord pour iOS avant de passer par Androïd. Y a peut-être plus de tel Androïd en circulation mais les payeurs sont sur iOS. Par ailleurs, une webapp est bien plus limitée qu'une App native en terme d'accès système, donc je ne vois pas les devs abandonner le native pour du Web... Ton fantasme n'est pas près de se réaliser.
avatar joneskind | 
Quand je pense qu'il y a encore des Gus pour se persuader que si Apple n'a pas accepté Flash sur iOS c'était pour protéger l'Appstore des jeux gratuits... C'te vaste blague quand même...
avatar KrummenHacker | 
@oomu "Objective C n'est PAS compatible C++" C'est totalement faux! Personnellement, toutes mes Apps iOS sont écrites en Objective C++. Pour cela, il suffit de renommer les fichier source .m en .mm et le compilateur accepte le code C++. De plus, le compilateur clang qui est celui utilisé par défaut dans XCode 4.6 est compatible avec les dernières nouveautés de C++ 11 qui vient d'être finalisé. Jusqu'à récemment, il était difficile d'inclure des objets C++ dans un objet Objective C, car les constructeurs et destructeurs n'étaient pas appelés lors de l'initialisation de l'objet Objective C. Ce n'est plus le cas actuellement. Avec l'utilisation de ARC qui simplifie la gestion de la mémoire du côté Objective C, le mélange des deux langage est un délice. Je dirais que l'intégration des deux langages est presque parfait. Je m'attends à ce que les dernières limitations disparaissent dans XCode 5. Il est vrai que la documentation à ce sujet est lacunaire. J'utilise Objective C pour réaliser les interfaces utilisateur et l'accès aux ressources systèmes puisque les APIs ne sont disponible que dans ce langage, mais pour le reste, j'écris tout en C++. On pourrait guerroyer en mode croisade durant des siècles sur les mérites respectifs des différents langages, mais il faut rester pragmatique et utiliser ceux qui sont le mieux adaptés à la plateforme pour laquelle on programme, soit C# pour windows, Java pour Android et Objective C++ pour iOS / OS X.
avatar Ricky McLane | 
@oomu : +1 et +1 ;) Et ça à commencé au début des années 90 avec NEXTSTEP !. "The piece of software the most respected in the World". (d'une avance considérable à l'époque !) Etudiant à cette époque, quel panard j'ai pris à utiliser Objective-C, Interface-Builder (toute mon admiration à JM Hullot mon Frenchy préféré) / Project Builder (Xcode d'aujourd'hui) et l'Application Kit. Alors que dans le même temps le c++ m'ennuyait profondément... Petit moment de nostalgie ;-)
avatar l3aronsansgland | 
Ca attirerait simplement plus de développeurs, donc plus d'apps.
avatar KrummenHacker | 
@ricky mclane Je compatis avec les difficultés que tu as rencontré en programmant en C++ durant la dernière décennie du précédent millénaire, car je les ai vécues aussi. Il est vrai qu'à l'époque, objective C était plus facile à utiliser, car les concepts majeurs de C++ tels que l'héritage multiple étaient très très mal implémentés par les compilateurs. Mais la situation a beaucoup évolué depuis et C++ a atteint sa pleine maturité et n'a plus rien à envier à Objective C, bien au contraire. Il y a bien un concept majeur de Objective C qui est absent de C++, c'est celui de delegate/protocol. J'ai longtemps trouvé que ce serait cool de pouvoir utiliser ce concept en C++. J'ai fini par construire l'équivalent à l'aide d'une classe C++ très simple et de quelques #define. Le résultat est tout a fait comparable à ce qu'offre Objective C, mais en mieux, grâce à l'héritage multiple et aux fonctions virtuelles. Il faudra bien qu'un jour, je me décide à documenter cette classe et que je la publie sur le web, mais je suis si paresseux.
avatar Ricky McLane | 
@KrummenHacker : J'avoue bien humblement que je ne me suis plus jamais intéressé au C++, et veux donc bien croire qu'il a bien évolué sur divers aspects tant syntaxiques que conceptuels même si je reste très dubitatif sur le paradigme de l'héritage multiple qui semble séduisant sur le principe (au même titre que la surcharge des opérateurs) mais un vrai "sac de nœud" dans certaines circonstances.
avatar robrob | 
Effectivement je developpe beaucoup en Objective C++ aussi. Par contre perso je n'utilise pas ARC et j'utilise aussi des bibliotheques C et c'est la qu'on voit le b*rdel que ca peut etre de gerer la memoire C/Objective C/C++ dans un meme programme.
avatar robrob | 
@ricky mclane Les cas d'usage necessaire de l'heritage multiple sont tres rares. C'est vraiment le truc a eviter dans la majorite des cas. De toute maniere objective-C et C++ ne repondent pas aux memes contraintes et comme toujours en informatique il s'agit d'utiliser le bon outil pour resoudre le bon probleme.
avatar KrummenHacker | 
@robrob Alors, si la gestion de mémoire d'Objective C te paraît un b*rdel, ce que je confirme, il faut absolument que tu essaies ARC! J'ai personnellement mis plus d'une année avant de tenter l'expérience, tant j'étais effrayé par la perspective de devoir revoir tout mon code. Lorsque j'ai fais le pas, ça ma pris quelques heures pour corriger tous les retain et release que le compilateur refusait désormais. Il m'a fallu revoir certaines bidouilles que j'avais dû faire pour contourner des contraintes désormais obsolètes de compatibilité avec C++ (probablement du genre de celles que tu mentionnes). Le résultat est un code bien plus simple et propre. Les fuites de mémoires ne sont plus que de mauvais souvenirs. Je ne reviendrais pour rien au monde en arrière, tu comprendras pourquoi une fois que tu auras franchi le pas. Le temps perdu à convertir les projets existants est amorti très rapidement, tant ARC facilite le travail.
avatar KrummenHacker | 
@ricki mclane La surcharge des opérateurs? Pour des raisons de compatibilité multi plateforme et de performances (NSString est très mauvais pour des chaînes de caractères très longues >100KB, j'utilise une classe de gestion de chaînes de caractères maison (je n'utilise pas du tout la librairie standard de C++) qui répond à mes besoins particuliers. La surcharge de l'opérateur = me permet de convertir entre NSString et ma propre classe de manière totalement implicite. Ce n'est qu'un exemple parmi tant d'autres. La surcharge d'opérateur est justement une des fonctionnalités de C++ qui me facilite son intégration avec Objective C.
avatar robrob | 
@KrummenHacker C'est surtout le melange des modeles memoire qui est b*rdelique. Chacun pris a part c'est simple. Un exemple utiliser des objets d'OpenCV melanges avec de l'objective C et des bibliotheques non objective C necessitant les C*ObjectRetain et Release. Pas insurmontable juste penible que ce soit pas un peu mieux unifie.
avatar KrummenHacker | 
@robrob Ben justement, avec ARC, tu ne te préoccupes plus de retain, ni de release, ni de autorelease, etc. À quelques exceptions près (CGRef etc.), je dois l'admettre. Mais dans ces quelques rares cas, le compilateur te le signale lors de la conversion vers ARC. Ah! Évidemment, un objet alloué en C++ avec new doit quand même toujours être libéré par un delete. Ça, ça ne change pas. C++ 11 introduit aussi des smart pointers, mais je n'ai pas expérimenté. Faudra que j'essaie un jour.
avatar robrob | 
J'utilise les smart pointers au boulot mais pas dans mes projets persos. Juste en raison de la taille qui ne le justifie pas sinon c'est comme ARC, c'est pratique. Le probleme est bien les CGRef et autres combine aux new/delete, combine a ARC ou non-ARC. D'ailleurs je comprends toujours pas pourquoi on a toujours autant de bibliotheque en C et non objective-C.
avatar Silvering | 
RubyMotion fait mieux que tout le monde... C'est la meilleure solution du moment pour passer outre l'objective-c

Pages

CONNEXION UTILISATEUR