[La question qui tue] Portabilité des applications métier de Windows Mobile 6.5 vers Windows Phone 7
“Je suis un pro, j’ai fait le choix de Windows Mobile il y a des années, je vois plein de buzz positif autour de Windows Phone 7 mais il parait que la compatibilité n’est pas assurée… Or j’ai des collaborateurs avec des applications d’entreprise, comment je fais ?”
Mauvaise nouvelle, il n’y a pas de réponse simple. Ce n'’est pas si grave que ça non plus, parce qu’il y a quand même toujours une réponse :) Chaque cas étant particulier c’est difficile de faire des généralités pertinentes, mais on va essayer quand même de se faire une opinion et de “dégrossir” le terrain. En tous cas, On va lister quelles questions et avec quelles informations appeler votre serviteur pour trancher sur une potentielle migration de Windows Mobile 6.x vers Windows Phone 7.
L’usage: terminal durci ou pas?
D’abord si vous faites dans les terminaux durcis… Windows Phone 7 ne devrait pas être dans vos plans. Je ne dis pas que ça n’arrivera jamais (qui sait de quoi le futur est fait…) mais ce n’est pas pour ce type de terminaux que cet OS a été pensé. Windows Phone 7 est avant tout grand public, et l’OS, le SDK, les applications et le mode de déploiement des applications ont été pensées avec le grand public en tête. En plus les spécifications matérielles minimales de Windows Phone 7 sont souvent incompatible avec le milieu durci (écran capacitif obligatoire par exemple).
Ceci étant dit, il existe tout une population “d’information worker” qui utilisent un terminal grand public pour des taches métiers: commerciaux ou agents de terrain avec une application de CRM, chauffeurs, etc. Sans compter la volonté pour un certain nombre d’entreprises de faire une application “intranet” ou “note de frais”. Toutes ces populations pourraient être concernées par des applications métier sur un smartphone sexy avec Windows Phone 7. Ca vaut vraiment le coup de se poser la question. Ou plutôt les questions, car il n’y en a pas qu’une… et tant qu’à faire autant commencer par la question la plus épineuse: le déploiement de l’application en question sur les terminaux.
Le déploiement passe obligatoirement par le Marketplace public
C’est le point sensible. Autant on pourra quasiment toujours contourner une difficulté technique, autant, celle là, ce n’est pas possible. Votre application sera visible par tout le monde. Voire, téléchargeable part tout le monde (à condition d’y mettre le prix que vous fixerez). Ca peut être un showstopper, comme une grande force: après tout, un simple système d’authentification peut vous permettre de protéger votre application tout en garantissant que vous êtes visible sur le Marketplace: prenons un exemple simple: vous avez une application “note de frais” qui est customizable par chaque client: la configuration du client lui est propre et ne doit pas forcément se trouver sur Marketplace. Quelqu’un d’anonyme qui téléchargerait l’application pourrait la voir en mode “restreint” et avoir l’option de vous contacter pour en savoir plus: Marketplace devient alors un vecteur de publicité et de leads. Dans le même genre d’optique, vous pouvez aussi utiliser l’authentification pour débloquer par exemple l’accès à des services spéciaux (internes par exemple) et sans authentification proposer à vos clients une application publique qui pourrait leur servir indépendamment de votre backend.
Si votre application est faite par l’interne, pour l’interne, le cas est plus délicat: quoiqu’il en soit Microsoft étudie toutes les possibilités pour offrir aux entreprises la possibilité de déployer leur application sans passer par les moyens du grand public et saura revenir, on l’espère le plus vite possible, avec des propositions: dans tous les cas, ce n’est pas encore annoncé, et donc pas encore roadmapé…
La technologie / Les fonctionnalités
Une fois l’écueil “publication sur Marketplace” passé, reste à savoir si vous pouvez implémenter votre application sur Windows Phone 7 et combien ça va vous coûter.
Tout a changé avec Windows Phone 7: l’OS, mais aussi le SDK, et le modèle applicatif. Pour de plus amples informations, je vous conseille l’article Comprendre la plateforme Windows Phone 7 sur MSDN. Du coup, il n’y a pas de compatibilité binaire entre Windows Phone 7 et les versions précédentes de l’OS ou entre le kit de développement Windows Phone 7 et les kits de développement précédents. D’une manière ou d’une autre il faudra réécrire l’application. Toute? Pas forcément… tout dépend de votre technologie de départ et de la modularité de votre code. Si vous avez opté pour le Compact Framework par le passé, alors il y a de fortes chances que vous puissiez réutiliser vos couches métiers, même s’il faudra vraisemblablement revoir la partie réseau. En ce qui concerne la couche de présentation en revanche, elle est à oublier, il faudra tout refaire avec Silverlight. Si vous aviez opté pour des technologies natives (C/C++, Win32, MFC…) alors il faudra tout bonnement tout réécrire.
Une fois la décision sur la réécriture/portage validée, il faudra s’intéresser aux fonctionnalités du SDK. La bonne nouvelle est qu’il y a 98% de chances qu’il soit possible d’écrire une application iso-fonctionnelle à l’ancienne, même s’il faudra surement utiliser quelques ressources de la communauté, et peut-être un peu de malice. En effet, sans background processing par exemple il faudra peut-être recourir à un service online et des notifications en push pour provoquer des synchronisations de données par exemple . Un autre exemple, s’il y a besoin d’une base de donnée locale, Microsoft n’a pas encore porté SQL CE sur Windows Phone 7, mais SQLite existe déjà dans la communauté. Du coup, il est fort probable que votre application puisse, moyennant un peu d’adaptation, être portée. En revanche, il faut rester honnête, certain scénarios vont être impossible à implémenter pour le moment : par exemple le suivi de véhicule avec une application tournant en background dans le téléphone et uploadant régulièrement sa position GPS (il faudrait que l’application soit affichée à l’écran pour que cela marche), ou alors l’accès aux couches basses ou aux API de l’OS comme l’interfaçage avec un équipement particulier qui requiert l’accès à un port série et une pile Bluetooth.
Après cette longue lecture, vous devriez avoir une idée un peu plus claire mais pas forcément très positive de l’idée du portage de votre application: cela représente de toutes façons pas mal de travail. Mais ce travail peut en valoir la peine. Windows Phone 7 marque une nouvelle page de l’histoire des smartphones avec une ergonomie différente centrée sur l’utilisateur. A vous de voir en fonction des usages, des besoins de vos collaborateurs et de l’image que vous voulez véhiculer. Les points bloquants mentionnés tout au long de cet article sont-ils réellement bloquants? ils ne l’ont pas forcément été pour d’autres! Dans tous les cas, toute l’équipe mobile chez Microsoft saura répondre aux questions et dissiper les doutes éventuels. Cet article n’est là que pour expliquer la base, car encore une fois il est impossible de faire des généralités sur les applications métiers… Alors contactez-nous!!
Comments
Anonymous
October 04, 2010
PI : La version SQLite "disponible dans la communauté" est basée sur c#sqlite, un projet. Ce n'est qu'un version incomplète de SQLite et également non stable.Anonymous
October 04, 2010
tout à fait, au fur et à mesure de son utilisation on voit qu'il manque des petites choses.. mais cela fournit tout de même une solution temporaire :)Anonymous
October 06, 2010
C'est une des forces des anciens WM d'autoriser le déploiement d'une application a partir d'un fichier que l'on diffuse sur les appareils. Mettre son application sur le market place c'est un énorme frein d'une part du fait de la visibilité (que vous détournez joliment en argument publicitaire ;-) mais aussi du fait des contraintes de publications.Anonymous
October 08, 2010
ce qui est une force pour certains usages peut devenir un problème dans d'autre, à l'heure du choix, nous avons préféré orienter ces choix au bénéfice du grand public. C'est vrai. Ceci étant dit, ce n'est pas moi qui "détourne" une faiblesse, c'est un feedback que nous avons de nombreux éditeurs de logiciels qui ont choisi ce chemin. Chemin qui ne correspondra pas à tous les besoins, c'est sur... Quant aux contraintes de publications, les critères techniques sont extrêment simples, bien plus simples qu'avec Windows Mobile 6.5 :) Il n'en reste pas moins que pour certaines entreprises, il sera impossible de procéder de cette manière, et dans ce cas la seule réponse que nous pouvons apporter est Windows Mobile 6.5. Les choses changeront dans le futur :)Anonymous
October 14, 2010
Personellement, je prend cette sortie de Windows 7 comme un abandon de Microsoft du monde de l'entreprise au profit du grand public. Si on y ajoute l'incompatibilité des SDK 6.5 avec VS2010... No comment l'avenir s'annonce noir !Anonymous
October 15, 2010
l'avenir n'est surement pas noir - il faut être pragmatique cette année, c'était le dernier moment pour sortir un OS pour mobile, et il n'y a pas de secrets: aujourd'hui même dans l'entreprise, ce sont les téléphones "grand public" qui font la loi. CF l'arrivée de l'iphone par exemple... Le succès en entreprise dépend d'abord et avant tout du succès grand public, et windows phone 7 reste avec l'intégration outlook et office un super téléphone pour 90% du marché entreprise. A mon avis, c'est la bonne stratégie, quitte à devoir attendre un peu pour pouvoir migrer les applications LOB. de toutes façons, un téléphone qui ne marche pas dans le grand public ne marchera pas en entreprise... aujourd'hui même blackberry se tourne vers l'entreprise! le mouvement de la partie terminaux durcis/Semi durcis vers le groupe Windows Embedded est aussi une preuve du commitment de Microsoft vers les terminaux industriels car il garanti une roadmap alignée avec CE (ce que les fabricants demandaient), des cycles de support plus long, et un modèle de distribution plus adapté. Toutes choses égales par ailleurs, et en restant pragmatique sur ce qu'on peut et ce qu'on doit faire, je ne vois pas d'autre stratégie possible. mais il parait qu'on est toujours près à recruter les gens qui ont de bonnes idées :) je ferai passer les CV!Anonymous
October 17, 2010
Je comprends pourquoi tu me disais récemment que mon appli de geoloc avait encore de l'avenir en win 6.5... Pourtant certains disent que l'on peut faire tourner des threads en backgound : bolingconsulting.com/blog (voir §Background operation) Qu'en penses-tu? A+Anonymous
October 19, 2010
je connais ce post de Doug. c'est un comportement non supporté, qui marchait en beta, mais je crois que ça ne fonctionne pas en RTM - en d'autres termes, ça exploitait un bug de la beta :)Anonymous
November 09, 2010
Certes, une question qui tue ! Mais surtout une question récurrente ;-) même si le contexte n'est plus franchement le même : www.histoire-cigref.org/.../portabilite-des-applications-informatiques A voir sous forme de clin d'oeil... et n'hésitez pas à commenter pour apporter votre expérience à l'écriture de cette "histoire vivante de l'informatique aux systèmes d'information" que nous avons entreprise !Anonymous
January 31, 2011
J'arrive après la bataille, mais quand on doit développer maintenant une application pour un parc existant de terminaux durcis en WM6, on fait comment ? VS2010 pas compatible. Le passage en Phone 7 impossible sur ces engins. VS2008 n'est plus vendu nulle part. Sa version Express n'est pas supportée par le SDK "mobile". Qu'est-ce qu'on a comme solution de rechange ?Anonymous
May 04, 2011
La solution de rechange existe : ne plus travailler avec Microsoft -:)Anonymous
May 09, 2011
Visual Studio 2008 est encore tout à fait disponible, notamment par l'intermédiaire des canaux de distribution Windows Embedded (qui gèrent maintenant Windows Embedded Handheld, équivalent de Windows Monbile 6.5 pour les terminaux durcis, mais normalement également chez vos fournisseurs habituels - n'hésitez pas à utiliser le formulaire de contact qui m'envoie un email directement, si par hasard ça n'était pas le cas, on en trouverait un autre :)