Microsoft abandonne son pont Android mais achète Xamarin
Microsoft abandonne la construction du « pont » qui devait permettre aux développeurs Android de porter sans effort leurs applications sous Windows 10 (une passerelle baptisée « Astoria »). L’éditeur concentre maintenant tous ses efforts sur le pont « Islandwood », c’est à dire celui destiné aux développeurs iOS intéressés par un portage de leurs créations sur Windows 10.
Pour expliquer l’abandon d’Astoria, Microsoft indique avoir reçu beaucoup de retours de développeurs ne comprenant pas le maintien de deux ponts alors que bien souvent, les applications mobiles se destinent à la fois à iOS et Android. Il suffit d’utiliser un des deux ponts, et c’est celui pour iOS qui a tenu bon.
Deux autres passerelles sont disponibles : Centennial pour les logiciels Win32 et .NET (en cours de finalisation), et le Web Bridge pour les apps HTML et Javascript (qui a été livré en juillet dernier au travers du SDK pour Windows 10). Shazam et Yahoo s’en servent déjà pour leurs propres applications.
Mais les développeurs Android (et les autres) pourraient bien avoir une autre solution pour adapter leurs créations à Windows 10. Après des années de rumeurs, Microsoft a finalement jeté son dévolu sur Xamarin, une solution de développement pour concevoir des applications multiplateformes en C# : Windows, iOS, Android.
Les deux entreprises se sont rapprochées au fil du temps et il paraissait de plus en plus évident que Microsoft allait signer un chèque : les outils de Xamarin sont en effet populaires, malgré leur prix (l’éditeur propose sa plateforme de développement sur abonnement). Plusieurs grands noms ont succombé au délice de cette boîte à outils, dont Coca-Cola, Alaska Airlines ou encore Honeywell. En tout, Xamarin compte 1,3 million de développeurs.
Ils sont nombreux maintenant à espérer que Microsoft rapproche Xamarin de ses propres solutions de développement, pour ne plus proposer qu’un seul environnement… au prix le plus serré possible, voire gratuit. Redmond a grand besoin de garnir son Windows Store avec des applications innovantes : actuellement, le catalogue est bien maigre (et c’est pire encore sous Windows 10 Mobile). Les conférences Build pour les développeurs démarrent le 30 mars : l’occasion sera trop belle pour Microsoft de dévoiler son jeu.
En même temps s'il faut passer par xamarin, personnellement ça ne me vend pas du rêve. Jamais essayé c'est vrai, et sans doute que crosoft va beaucoup améliorer la chose, mais il n'empêche que la communauté est réduite par rapport aux autres langages, et que de ce que j'aurai lu, il n'existe pas toutes les méthodess natives de chaque os et il fait composer avec.
Après pour une boîte qui n'a que les $ en têtes, ca divise le temps de prod c'est indeniable, et ca as sans doute de gros avantages c'est sûr.
@Rictusi :
Un boite qui n a que les $ en tête ? Ah tu en connais qui n ont pas cela en tête ? Appl€ par exemple?
Eh oui, ça existe.
Le but d'une entreprise est de gagner de l'argent, mais ça ne veut pas dire que c'est forcément la seule motivation et qu'ils n'ont que ça en tête.
Aucune entreprise n'existe pour gagner des $. (dans le sens : unique but de l'entreprise)
Une entreprise existe pour répondre à une demande de valeur ajoutée.
Pour que l'entreprise puisse investir et créer cette valeur ajoutée, elle DOIT gagner des $.
C'est un moyen et pas une finalité.
Pour exister sur le marché des investisseurs (bourses) elle doit donner des dividendes attractifs et avoir un cours qui inspire confiance.
Meme une société de conseils en placement vend ses conseils et se paye sur les placements...
Sans conseil, pas de placements et pas de $...
Bref.
"Une entreprise existe pour répondre à une demande de valeur ajoutée.", tu es sérieux là ? Tu fais quoi comme job ? Tu as été élevé chez les loups, les moines ?
La grosse majorité des grandes (et pas grandes) entreprises ont d'autres objectifs que les $. Je veux dire, en plus des $.
Le monde n'est pas aussi simpliste, heureusement.
Scoop : les politiques ont aussi d'autres objectifs que faire progresser nos sociétés et modes de vie.
@en ballade :
"Un boite qui n a que les $ en tête ? Ah tu en connais qui n ont pas cela en tête ?"
Pourquoi écris tu Apple avec € depuis des mois alors ?
Haaaaa je croyais que c'était pour faire passer le même message ... Mais je dois me tromper ..
Rien de nouveau sous le soleil dans tes commentaires donc ... :-))
"Jamais essayé c'est vrai"
Ah. Lire ce qui suit cette phrase est donc inutile.
Déjà, "ça ne me vend pas du rêve" laisse dubitatif sur tes méthodes d'évaluation et de sélection des outils de travail.
Qu'as-tu voulu exprimer exactement ?
@ Rictusi : « de ce que j'aurai lu, il n'existe pas toutes les méthodess natives de chaque os et il fait composer avec. »
Ben comme toujours avec un framework de développement « multi-plateformes » (qui n’est en fait qu’une plateforme de plus). Ces machins sont toujours à éviter quand on souhaite faire des applications soignées et parfaitement adaptées aux plateformes sur lesquelles on les fournit.
Mais il ne faut pas non plus oublier que tous les types d’applications ne nécessitent pas forcément ce cahier des charges, et du coup ces machins peuvent être très utiles dans certains cas sans nuire à la qualité du produit final.
Ce qui est regrettable, c’est quand ils sont utilisés aussi dans les autres cas, par des développeurs visant juste l’effort minimal pour la distribution la plus large possible. Mais ce n’est pas nouveau.
« Après pour une boîte qui n'a que les $ en têtes, ca divise le temps de prod c'est indeniable, et ca as sans doute de gros avantages c'est sûr. »
Ouaip.
Roo ben zut alors, ils auraient pu racheter Windev...
@ kubernan
Windev... c'te bonne blague.
MDR ;-)
Bravo à Miguel, Nat et leurs equipes. Mono est un beau projet.
C'est clair bravo à eux, malgré la muraille idéologique DinoSoftienne et le nombre incroyable de bâtons dans les roues de la part de DinoSoft, qu'ils ont reçus tout au long de cette décennie.
Je serais eux, je profiterais de l'argent pour rebuilder une startup qui développerait de nouvelles plateformes (avec Swift comme base par ex. ^_^)...
@fte :
Alors le principe du cross-plateform : croire que l'on va produire un produit identique à coup moindre.
Au final c'est apprendre un langage intermédiaire qui n'a aucune pérennité et introduit une couche supplémentaire et les problèmes qui vont avec.
Très adapté à certaines situations de niche mais pas pour la grande majorité des applications.
Je ne comprends pas ton commentaire, ni pourquoi tu me l'adresses spécifiquement.
Ta conception du cross-plateforme date d'il y a 20 ans.
Quant à Xamarin, à C# et F#, je n'imagine pas comment tu peux imaginer qu'ils n'ont aucune pérennité. Ce sont au contraire des langages très solides et de qualité, et le toolset est très bon également.
Après, la couche supplémentaire, les problèmes, que ce soit limité ici et là et non natif, c'est une autre affaire.
Ça, c'était la super nouvelle de la journée !
Bon, tout est à faire mais avoir un code pour plusieurs plateformes, on sait déjà que c'est un rêve de dev.
Le fait que ce langage soit C#, sachant que mono et .net sont assez proche, c'est tellement mieux que les frameworks html/css/Javascript.
Youpi matin, donc.
@ Hasgarn : « mais avoir un code pour plusieurs plateformes, on sait déjà que c'est un rêve de dev. »
De certains développeurs, sans aucun doute. Mais pas de tous, fort heureusement.
On est d'accord, je me range à ton point de vue, je préfère le natif.
Mais à choisir entre un FrameW html/css/Javascript et Xamarin, je prends Xamarin.
Pour quelles raisons ?
Un moteur node.js, react, TypeScript, une webview, et tu obtiens des performances remarquables à la fois sur iOS et Android avec un langage plus sympathique que JS et une très vaste collection de librairies de toutes sortes.
C'est une solution crédible pour de nombreuses applications, au moins pour partie.
Donc oui, pourquoi Xamarin ?
La même question se pose dans l'autre sens par ailleurs. Pourquoi React Native plutôt que Xamarin ? Par exemple.
"Parce que." n'est pas une réponse acceptable.
Parce que ?
Parce que je maîtrise mieux c# que JS (que je n'aime vraiment pas dans cet usage après m'être casser le fion sur une app hybride Backbone JS…).
C'est un parce que valable à mes yeux.
Le comfort est une réponse valable. :)
Et j'aime mon confort ;)
c'est là qu'on voit que ce sont des choix non pour faire le meilleur produit aux CLIENTS mais pour faciliter la vie de l'ingénieur.
Tu ne t'es pas dit que je fais le choix d'une technologie que je connais pour faire le meilleur produit pour le client ?
Que peu importe l'environnement de dev, ce n'est pas l'environnement qui est mauvais mais le codeur ?
@ Hasgarn : « Que peu importe l'environnement de dev, ce n'est pas l'environnement qui est mauvais mais le codeur ? »
Attention, tout de même : certes, un bon framework ne compensera pas un mauvais développeur, mais ça marche aussi dans l’autre sens. Même un excellent développeur ne pourra pas faire de magie face à un mauvais framework (sauf à tout redévelopper lui-même, mais dans ce cas, il aura plus probablement choisi de changer de framework).
Admettons, je suis allé un peu vite ^^'
Reste qu'en matière de dev mobile, aucune techno n'est vraiment ancienne et comme ça évolue plutôt vite, lesdits FW sont généralement plutôt à la pointe et bon.
Pour une web app, c'est sur que tu peux tomber sur des trucs très… vieux.
Maintenant, oomu provoque un peu et s'il n'a pas tord, il n'a pas non plus raison. Sous prétexte que la techno sied à un dev, le choix de cette techno n'est pas la meilleur. Comme tu le soulignes toi même :
"Même un excellent développeur ne pourra pas faire de magie face à un mauvais framework (sauf à tout redévelopper lui-même, mais dans ce cas, il aura plus probablement choisi de changer de framework)"
le choix d'une techno fait parti des devoir d'un dev et il doit choisir celle qui apporte les meilleurs plus-values.
Et en l'occurence, Xamarin VS WebApp, j'ai vite choisi.
J'ajoute d'ailleurs que la webApp encapsulée a un gros défaut : la webview dans laquelle on l'injecte. Et j'ai eu de très mauvaise surprise sur les devices Android à ce sujet.
@Hasgarn
si, je me le suis dit. Mais je suis taquin.
Je n'ai aucune raison de douter de Vous, donc je ne doute pas. Mais la réthorique, la formulation, au cours de la discussion, il était très facile d'y lire que vous faites un choix qui vous arrange, pour votre confort, et non en faveur de l'utilisateur.
C'est un point que je trouvais intéressant de piquer.
-
Mais c'est mon préjugé classique envers tous les frameworks multi-plateformes. Ils m'ont toujours paru comme des compromis boiteux répondant avant tout à des logiques de coûts et de conforts.
Bien sur, une demande de client peut être : - cher, couvrir tout notre parc hétérogène, technologie éprouvée.
-
idéalement, je préfère du natif, en particulier avec Os X et iOs. (et oui, j'utilise des logiciels QT par exemple, la vie n'est pas idéale ;) )
"Mais je suis taquin."
Le pire, c'est que je le sais ^^'
"Et je me fais eu comme un jeunot" :p
Et d'une manière général, le dev hybride, c'est un peu comme le mariage : c'est régler des problèmes qu'on n'aurais pas eu en natif. Et ça prend finalement souvent le même temps.
@ fte : « Un moteur node.js, react, TypeScript, une webview, et tu obtiens des performances remarquables à la fois sur iOS et Android avec un langage plus sympathique que JS et une très vaste collection de librairies de toutes sortes. […]
Donc oui, pourquoi Xamarin ? »
Parce que malgré les défauts d’un approche comme Xamarin, ça permet tout de même de s’approcher bien plus du niveau d’une application native qu’un site web dans une webview.
@ Hasgarn : « Mais à choisir entre un FrameW html/css/Javascript et Xamarin, je prends Xamarin. »
Ah ben sur ce point-là aussi, on est d’accord !
Mais bon, comme tu l’as fait remarquer dans ton « parce que » en réponse à fte, le niveau de maîtrise de tel ou tel couple langage/framework peut amener certains à faire une choix différent (bien qu’il soit souvent regrettable que ce critère prime sur d’autres).
Y a plus qu'à espérer que maintenant, Microsoft donne le traitement MSDN à Xamarin parce que côté doc, c'est vraiment le désert.
Ces solutions magiques ça reste moyen mais bon. Quand iOS est arrivé des devs se sont formés à ce langage devant la demande abondante des entreprises. Pour Android, ce sont les parts de marché qui ont poussé les entreprises à faire des apps. D'ailleurs les apps Android n'était pas aussi bien que sur iOS. Sont elles aussi bien aujourd'hui ?
Microsoft arrive sur un marché déjà installé et n'a rien de révolutionnaire pour l'instant même si le concept d'apps universelles est sympa. Quelque soit la solution choisie, elle restera difficile à mettre en place.
Cette news tombe pile au moment ou je vais attaquer un proto, un Gui de bdd, grille image+texte, quelques action associées (requêtes bdd).
Je me dis "hmmmr, ne soit pas con, prend un framework qui couvre toutes les plateformes d'un coup pour ce genre d'app, un peu comme Slack"
Electron.io ? Xamarin ? Autres ?
Il est temps que Microsoft se bouge le fion car leur store est juste dégueulasse. Vide, pas d'app Google, manque énormément de petites app (banques, transport en commun de sa ville, etc.), jeux, appli connu, etc... A l'époque leur OS avait des bug de 2007 de la concurrence( MAJ automatique des app boiteuse par exemple) J'y suis resté 3 mois et je me suis barré, j'en pouvais plus. C'est dommage car les Lumia sont d'excellents smartphones.
Microsoft fait tout ce qu'elle peut, et elle est même particulièrement agressive.
rachat, ajout rapide de frameworks, voir même TROP DE FRAMEWORKS DIFFERENTS RAAAAH, pousse tout le monde et mon chat à passer à windows 10 qui ajoute justement tous ces trucs pour encourager à faire du windows phone et autre apps pour le store.
Dans le fond, je dirais même que Microsoft en fait trop parce qu'elle nie qu'elle devrait abandonner et admettre qu'elle n'est pas comme Apple.
Entre Google et Apple, il n'y a pas de place pour un Windows.
La solution Microsoft n'intéresse pas les développeurs et le public.
Je ne connais pas Xamarin, mais j'ai utilisé son ancêtre - MonoTouch - et c'était une belle daube bien instable... et pas portable pour autant vu que ce n'était qu'une série de bindings C# au dessus des APIs natives d'Apple. Just une couche de bug supplémentaires...