Pierre's Embedded and Mobile Blog

Soulevons le capot des systèmes embarqués et mobiles

October, 2010

Posts
  • Pierre's Embedded and Mobile Blog

    [Windows Phone 7] Les outils de développement en Français sont disponibles

    • 8 Comments

    Jusqu’à présent le kit de dev WP7 était dispo uniquement pour la version US de Visual Studio et Expression Blend. Les versions localisées sont enfin disponibles., y compris en Français!!

  • Pierre's Embedded and Mobile Blog

    [Windows Phone 7] Faire persister son application sous l’écran de verrouillage

    • 1 Comments

    Malgré le fait qu’une application ne peut exécuter du code quand elle est en background, Windows Phone 7 autorise une application à tourner sous le lock screen (ou écran de verrouillage). On peut aussi empêcher que le téléphone se verrouille, ce qui peut être utile pour certaines applications (navigation turn by turn, détection de mouvement, ce genre de choses). En fait, avec la logique Windows Phone 7, il s’agit de dire à l’application de ne pas détecter que l’utilisateur est inactif (ou l’application elle même…) d’ou la présence de 2 APIs

    • Microsoft.Windows.Phone.Shell.PhoneApplicationService.ApplicationIdleDetectionMode, qui permet de détecter ou pas l’inactivité du téléphone, et qui quand elle est activée, tombstone l’application quand le lock screen démarre.
    • Microsoft.Windows.Phone.Shell.PhoneApplicationService.UserIdleDetectionMode, qui permet de détecter ou pas l’inactivité de l’utilisateur et donc déclencher le lock screen.

    Du coup on peut avoir 3 comportements:

    • Les deux modes sont “enabled” : l’écran se verrouille au bout d’un certain temps comme prévu dans les paramètres du terminal et l’application est tombstonée
    • ApplicationIdleDetectionMode est “disabled”: l’écran se verrouille quand l’utilisateur est inactif mais l’application continue à tourner (et donc à consommer de la batterie!!!
    • ApplicationIdleDetectionMode et UserIdleDetectionMode  sont “disabled” et dans ce cas l’écran ne se verrouille pas et l’application continue à tourner (et donc à consommer de la batterie!!)

    Plusieurs warnings sont à prendre en compte quand on utilise ces APIs, particulièrement en regard des critères de certification (critère 6.3)

    • Il faut que cette fonctionnalité soit une option configurable dans un écran de l’application
    • Lors du premier appel à cette API, il faut avertir l’utilisateur (explicitement) et lui demander son consentement!

    Par ailleurs le modèle de multithreading et de tombstoning étant susceptible d’évoluer, il faudra vérifier au fur et à mesure des versions du SDK le comportement de son application!!

    Dernier point, une fois que la détection d’inactivité, de l’application ou de l’utilisateur, a été “disabled” il n’est pas possible de la réactiver de façon programmatique: une InvalidOperationException sera levée (à traiter, donc!!).

    La page MSDN qui traite du sujet

  • Pierre's Embedded and Mobile Blog

    [Windows Phone 7] 10 trucs pour passer facilement la certification

    • 0 Comments

    Avec les premières phases de certifications qui démarrent, et un an de recul sur la certifications des applications pour Windows Mobile 6.5, on se rend compte que finalement, la très grande majorité des échecs sont liés à des fautes d’inattention… ou un manque de lecture de la documentation ! Voici donc les 10 points à avoir toujours en tête lorsqu’on prépare la certification :

    1/ LISEZ LA DOC !!!!! tout est dans la documentation. Prendre une petite demi-heure pour lire et comprendre cette documentation vous sauvera peut-être d’un échec cuisant. Mon conseil : annotez la au fur et à mesure de votre lecture. Assurez vous d’avoir la dernière version du document, qu’on trouve sur le portail http://developer.windowsphone.com. Tout y est détaillé. Lisez la doc. (ou je me fâche !!)

    2/ Soignez l’iconographie. D’abord parce que votre iconographie (icônes et screenshots) représentent votre application sur Marketplace et dans le terminal de vos utilisateurs, mais aussi parce qu’une erreur d’iconographie peut vous coûter votre certification.

    • Cas de test 4.6 : les screenshots doivent provenir d’une capture d’écran du téléphone ou de l’émulateur, doivent avoir une résolution de 480x800 pixels et avoir les proportions largeur/hauteur normales de l’application sur le terminal.
    • Cas de test 4.5 : N’utilisez pas les icônes par défaut de Windows Mobile ou Windows Phone

    - Inclure une image de fond au format « panorama » n’est pas nécessaire, mais permettra à Microsoft le cas échéant de « skinner » Marketplace aux couleurs de votre application, et donc vous mettre à l’honneur. Pourquoi refuser ?

    3/ Informations de support (cas de test 5.6) : votre application doit avoir un nom et un numéro de version, et doit inclure des informations de support (url de site web, email) facilement découvrables par l’utilisateur final

    4/ Notifications de type Toast (cas de test 6.2)

    • Il faut fournir à l’utilisateur la possibilité de désactiver les notifications
    • Au premier usage de l’API HttpNotificationChannel.BindtoShellToast, l’application doit demander explicitement à l’utilisateur l’autorisation de recevoir des notifications.

    5/ Applications continuant leur exécution quand l’écran est verrouillé (cas de test 6.3)

    • Ce cas s’applique uniquement aux applications qui continuent à tourner quand l’écran est verrouillé, et ne s’applique pas aux applications dans l’état « suspended ».
    • Il faudra demander à l’utilisateur explicitement la permission d’avoir ce comportement lors du premier appel à l’API ApplicationIdleDetectionMode

    6/ Utilisation du bouton Back – cas de test 5.2.4 : voici un exemple typique d’échec qui aurait été simple à traiter : appuyer sur le bouton back doit ramener à la page précédente de l’application, pas la quitter (sauf si on est sur la première page) ou faire apparaitre un menu ou une boite de dialogue – le plus simple : gardez le comportement par défaut !!

    7/ Thèmes : cas de test 5.1.1 : Utilisez les ressources associées au thème du téléphone plutôt que de hardcoder les couleurs … et risquer de tomber dans un cas ou l’application n’apparaitra pas correctement quand le thème choisi par l’utilisateur est le thème « light » : Et donc testez aussi dans ce mode là avant de soumettre l’application !

    8/ Support des langues : Faites en sorte que la description et le texte dans l’application et dans la marketplace s’affichent dans le langage choisi par l’utilisateur (histoire d’éviter un menu en allemand pour un utilisateur français, et tant qu’on y est, évitez les traductions automatiques débiles du type « la tasse mondiale » quand on parle de « world cup »…

    9/ Erreur à l’upload du XAP : A l’upload du XAP un outil va vérifier son intégrité – l’erreur la plus commune est « Your XAP is missing an interop manifest » : dans votre manifest, spécifiez bien les paramètres d’interop, car même si votre compte développeur n’utilise pas l’interop (privilège réservé aux opérateurs), le message sera généré.

    10/ Version des developer tools : j’enfonce encore une porte ouverte, mais avant de faire certifier votre application, installez, testez et packagez la avec les outils de dev RTM… les applications faites avec des versions précédentes (CTP et beta, publiques et privées) ne passeront pas !

  • Pierre's Embedded and Mobile Blog

    [La question qui tue] Portabilité des applications métier de Windows Mobile 6.5 vers Windows Phone 7

    • 12 Comments

    “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!!

Page 1 of 1 (4 items)