Multi-OS Engine : une technologie d’Intel qui permet de développer des applications iOS et Android natives

Multi-OS Engine : une technologie d’Intel qui permet de développer des applications iOS et Android natives
en utilisant le même code base Java

Multi-OS Engine est une technologie d’Intel qui permet aux développeurs d’utiliser leur expertise en Java pour développer des applications mobiles natives pour iOS et Android. La technologie est disponible pour les plateformes Mac OS X et Windows (via Cloud ou Serveur), mais pas pour le moment pour Linux.

L’idée derrière Multi-OS Engine est d’utiliser un code base Java commun pour créer des applications iOS et Android. Traditionnellement, les développeurs vont créer des applications Android à partir de Java et des applications iOS à partir d’Objective-C par exemple. Intel veut donc faire d’une pierre deux coups en réutilisant du code Java avec sa technologie Multi-OS Engine pour créer des applications iOS et Android natives. Intel explique également que le développement d’applications avec sa technologie ne compromet pas les performances natives et le look and feel des applications.

http://www.developpez.com/public/ima.../intel-moe.PNG

Plus exactement, la technologie Multi-OS Engine d’Intel se présente comme un plug-in autonome qui peut être intégré dans Android Studio pour construire, déboguer et déployer des applications iOS et Android. Android Studio UI designer sera également utilisé par les développeurs pour concevoir des interfaces utilisateur natives pour Android et iOS. Pour les applications iOS, Multi-OS Engine vous permet encore d’accéder aux API de la plateforme mobile d’Apple et autogénérer les bindings Java pour Objective-C ainsi que les bibliothèques C.

Comme vous pouvez le remarquer, l’idée derrière Multi-OS Engine est la même que celle derrière Xamarin, la technologie rachetée par Microsoft, qui permet d’écrire des applications en C# et partager le même code sur différentes plateformes : iOS, Android, Windows, Mac, etc. La différence fondamentale est qu’Intel a choisi Java au lieu de C#, sans oublier le fait que Multi-OS Engine se limite au développement d’applications Android et iOS. Il ne supporte donc pas le développement d’applications mobiles pour Windows.

Publié il y a moins d’un an, Multi-OS Engine est encore en préversion. La technologie d’Intel est compatible avec les dernières API Android et iOS, d’après le fabricant de puces. Elle est disponible sous la licence EULA (End-User License Agreement) d’Intel, mais la société prévoit de la rendre bientôt open source, pour développer la communauté et accélérer le développement de la technologie.

Sources : Intel Developer Zone, Annonce de Multi-OS Engine en open source

Et vous ?

:fleche: Que pensez-vous de Multi-OS Engine par rapport aux alternatives existantes comme Xamarin ?

Voir aussi :

:fleche: Intel présente des résultats financiers stables avec un CA qui augmente grâce à Altera, mais une restructuration qui fait chuter son bénéfice net
:fleche: Intel livre ses premiers Xeon Phi Knights Landing : la nouvelle mouture de ses coprocesseurs concurrence NVIDIA en apprentissage profond
:fleche: Intel prévoit de supprimer jusqu'à 12 000 emplois d'ici un an pour réorienter ses activités, en raison de la baisse des ventes de PC

Très bonne nouvelle =D y'en a marre de devoir apprendre X langages pour faire la même chose lol.
Par contre, concernant l'image, pourquoi le "bon" développeur a de la barbe et pas les autres ?

"Que pensez-vous de Multi-OS Engine par rapport aux alternatives existantes comme Xamarin ?"

Ben... depuis le rachat par Microsoft, on sait que RoboVM est condamné, donc la solution Intel a au minimum le mérite d'exister !

Parce que c'est "barbant" ? :weird: :mrgreen::mrgreen:

Citation:

---

Envoyé par paladice

Très bonne nouvelle =D y'en a marre de devoir apprendre X langages pour faire la même chose lol.
Par contre, concernant l'image, pourquoi le "bon" développeur a de la barbe et pas les autres ?

---

Chacun sa perception, à droite je vois un flemmard.

Je ne sais pas si on peut avoir confiance, il faut se rappeler robovm,
qu'est ce qu'Intel gagne au final avec cette techno?

De plus, au final, on développe avec les api natives enrobées dans du java, c'est juste un cauchemar, comme xamarin... c'est juste pas confortable : elle vient d'où l'erreur? de java ou de l'api native?

et si le saint Graal n'existait pas? et si il fallait mieux développer nativement?

Citation:

---

Envoyé par epsilon68

Je ne sais pas si on peut avoir confiance, il faut se rappeler robovm,
qu'est ce qu'Intel gagne au final avec cette techno?

---

Leurs devs bossent, à part ça je ne vois pas :mrgreen:

Citation:

---

Envoyé par epsilon68

qu'est ce qu'Intel gagne au final avec cette techno?

---

Intel essaye de se rendre incontournable dans un domaine où il est à la traine par rapport à ARM, peut-être ? Fournir l'environnement de développement, c'est la certitude que celui-ci sera parfaitement compatible avec ses propres technos.

Je me pose une question :

C'est un framework java à part qui génère du code java natif (android) et le l'objective-C (IOS) ? (1)

Ou alors on écrit directement en android-natif et on génère le code en objective-C ? (2)

Si C'est (1), il n'ont rien inventé. Titanium fait déjà sauf que le framework est en Javascript. Pour l''utiliser régulièrement, je me rend compte que finalement, il y a beaucoup de limitations ...

Si c'est(2) alors là ça devient intéressant :D

Je sais que je vais me faire trouer la paillasse par certain, mais lorsque je vois les trésors d'ingéniosité pour transformer telle ou telle techno pour faire du mutliplateforme, multidevice, multifruit, etc. Est-ce que la solution la plus simple ne serait pas la meilleure ? Je parle bien entendu de faire simplement du "fullweb" (peu importe la techno), il n'y a quand même pas plus universel qu'un navigateur web aujourd'hui...

Je sais qu'on ne peut pas tout faire en "fullweb" aujourd'hui, mais franchement, hein ? dites ? Quand même ! Les choses évolues rapidement et le natif, c'est pour une plateforme, tu veux faire un truc qui marche partout bah tu fais pas du natif => il n'y aurait-il pas des pratiques (visions, paradigmes, etc.) à revoir ?

Allez-y, sortez vos fourches... :rouleau:

Citation:

---

Envoyé par vinmar

Je sais que je vais me faire trouer la paillasse par certain, mais lorsque je vois les trésors d'ingéniosité pour transformer telle ou telle techno pour faire du mutliplateforme, multidevice, multifruit, etc. Est-ce que la solution la plus simple ne serait pas la meilleure ? Je parle bien entendu de faire simplement du "fullweb" (peu importe la techno), il n'y a quand même pas plus universel qu'un navigateur web aujourd'hui...

Je sais qu'on ne peut pas tout faire en "fullweb" aujourd'hui, mais franchement, hein ? dites ? Quand même ! Les choses évolues rapidement et le natif, c'est pour une plateforme, tu veux faire un truc qui marche partout bah tu fais pas du natif => il n'y aurait-il pas des pratiques (visions, paradigmes, etc.) à revoir ?

Allez-y, sortez vos fourches... :rouleau:

---

Non, ça finira sans doute par arriver. Mais effectivement, pour l'instant, on ne peut pas tout faire et les performances sont trop mauvaises.

Au niveau des fonctionnalités, ça avance. Au niveau des performances, il faudra attendre WebAssembly.

Sur un autre plan WebAssembly me fait un peu peur : le foisonnement de nouvelles bibliothèques, de nouveaux outils, de nouveaux langages transpilés en Javascript est déjà au-delà du raisonnable aujourd'hui, et ça risque d'encore empirer...

Citation:

---

Envoyé par vinmar

Je sais qu'on ne peut pas tout faire en "fullweb" aujourd'hui, mais franchement, hein ? dites ? Quand même ! Les choses évolues rapidement et le natif, c'est pour une plateforme, tu veux faire un truc qui marche partout bah tu fais pas du natif => il n'y aurait-il pas des pratiques (visions, paradigmes, etc.) à revoir ?

Allez-y, sortez vos fourches... :rouleau:

---

C'est proposé si gentiment :mrgreen:

1) Les devs web arrêtent de se prendre pour autre chose que des devs web en voulant faire des applications.

2) Les devs d'applis arrêtent de prendre tout et n'importe quoi pour développer, parce que lol ça fait un langage pour toutes les plateformes c'est forcément super .

3) On arrête le parasite qu'est Javascript : on l'oublie pour toute autre chose qu'une page web.

Pendant qu'on y est, on pourrait aussi arrêter de dire aux autres ce qu'ils doivent faire...

Citation:

---

Envoyé par GilbertLatranche

C'est proposé si gentiment :mrgreen:

1) Les devs web arrêtent de se prendre pour autre chose que des devs web en voulant faire des applications.

2) Les devs d'applis arrêtent de prendre tout et n'importe quoi pour développer, parce que lol ça fait un langage pour toutes les plateformes c'est forcément super .

3) On arrête le parasite qu'est Javascript : on l'oublie pour toute autre chose qu'une page web.

---

Bon j'essaie de reposer ma question - en dehors de toute considérations de langages/technos je précise - :

Il n'y a-t-il pas une erreur à faire des machins qui font tourner des trucs sur tout et n'importe quoi alors que truc à la base n'était pas fait pour ça ? => tu le sens mon niveau d'abstraction ?

Ma deuxième question est plus polémique et moins liée au bousin d'Intel : y'a-t-il encore une utilité à faire du natif lorsque l'on parle de multi plateforme et tout et tout ? Il y a certes des domaines où le fullweb est encore limité (les jeux 3D par exemple) ou des applications de niche (bref des exceptions/impossibilités il y en a toujours), mais est-ce que toutes les applications sur smartphone par exemple méritent d'être natives ? En tout cas sur le mien, pas des tonnes... Il ne serait pas plus intéressant et moins cher de les faire en fullweb ?

Je reste toujours assez dubitatif de voir des apps natives d'infos exister (lemonde, liberation, etc. lefigaro pour les plus extrémistes ;) ) et qui n'affiche que des fils d'informations. Non seulement ces applications sont soumises à l'approbation des stores (rien que ça si j'étais patron de presse ça me ferais chier), mais en plus, c'est du développement en plus? donc des coûts en plus pour ces boîtes...

Bref, quand je vois la merde que c'est ces soucis de multiplateforme, je pose la question : mais ne va-t-on pas droit dans le mur ? Ne sommes-nous pas en train de nous enfermer dans des carcans imposés par des grosses boîtes qui ont réussi à nous faire croire que pour mater son journal préféré en ligne il faut passer par une application native ? Grosses boîtes qui sont suivies d'autres grosses boîtes qui inventent des boîtes magiques pour que tout cela marche sur ces plateformes de grosses boîtes... A la fin, nous sommes juste des petits développeurs qui ont la vie qui ne se simplifie pas avec le temps (en plus de perdre nos cheveux). Alors que le fullweb, ces questions ne posent pas à moins de filtrer le net directement...

Regardez, Stallman à une tignasse lui encore... :)

Je peux évidemment me tromper, mais je ne la sens pas trop cette techno d'Intel. Le software, ça n'a jamais été leur point fort. Surtout que sur le hardware, ils ne sont plus aussi bien que ça.

Sinon, comme évoqué, je pense qu'à moyen terme, on se dirige tout droit vers le fullweb. Pas vraiment besoin d'être sorti de Polytechnique pour le deviner. Donc miser sur du client natif en Java... Mouai...

Et si demain il n'y a plus qu'android?
Voila un problème de reglé:aie:

je ne pense pas que le web soit "l'avenir", je pense que le web est déjà dominant mais j'aimerais que le futur soit aux applications *rapides* et pouvant fonctionner déconnectées. Surtout sur les mobiles, une page web (serveur) n'est pas génial car nous n'avons pas toujours le réseau ou un réseau rapide.
Application hybride alors? peut-etre mais jusqu'à présent, l'UI n'était pas géniale pour l'utilisateur.
Peut-être bien que react-native est une partie de la solution, mais le javascript est pénalisant par sa VM, sa conso mémoire et sa "lenteur".
Au final, moi je veux une appli rapide et qui ne pompe pas ma batterie!

Citation:

---

Envoyé par Michael Guilloux

Plus exactement, la technologie Multi-OS Engine d’Intel se présente comme un plug-in autonome qui peut être intégré dans Android Studio pour construire, déboguer et déployer des applications iOS et Android. Android Studio UI designer sera également utilisé par les développeurs pour concevoir des interfaces utilisateur natives pour Android et iOS. Pour les applications iOS, Multi-OS Engine vous permet encore d’accéder aux API de la plateforme mobile d’Apple et autogénérer les bindings Java pour Objective-C ainsi que les bibliothèques C.

Comme vous pouvez le remarquer, l’idée derrière Multi-OS Engine est la même que celle derrière Xamarin, la technologie rachetée par Microsoft, qui permet d’écrire des applications en C# et partager le même code sur différentes plateformes : iOS, Android, Windows, Mac, etc. La différence fondamentale est qu’Intel a choisi Java au lieu de C#, sans oublier le fait que Multi-OS Engine se limite au développement d’applications Android et iOS. Il ne supporte donc pas le développement d’applications mobiles pour Windows.

---

Oui alors si Intel a eu le bon sens de proposer un outil en Java vu l'engouement de la communauté .Net sur le mobile (et l'intérêt de parler développement mobile pour Windows alors que Microsoft abandonne ce domaine), est-ce que leur outil va vraiment intéresser quelqu'un ? On est toujours sur un marché très majoritairement iOs-first où le design est fait pour iOs et où la cible est iOs. Et je ne vois pas du tout les devs iOs se mettre à Android Studio pour anticiper du multi-plate-forme… Et ceux qui s'y essayeront, je les vois bien adhérer une fois les outils d'interfaces graphiques testés sous Android Studio…

Sérieusement, si la rumeur que Google intègre Swift comme "first class language for Android" se confirme (gros doute quand même), je voudrai bien croire à une possibilité de travail efficace sur du multi-plate-formes. Mais d'ici là, tant qu'on verra des outils proposés à l'envers bah… Ça occupera un peu les forums info… C'est tout…

Trop tard cette technologie, Embarcadero l'a dejà fait, cela se fait dejà en delphi XE7, A partir de ton code ecrit en Pascal-Objet tu choisi simplement la plate forme cible (iOs, Androis ou Windows Phone)