Les défauts des applications universelles

Microsoft a commencé à encourager les développeurs à migrer leurs applications vers des applications universelles, mais certains développeurs ne sont toujours pas convaincus. J'ai écrit il y a quelque temps un éditorial citant des développeurs sur la faisabilité des applications universelles et pourquoi elles ne mettent pas encore le feu au monde. Aujourd'hui, un autre développeur a publié un article sur ses expériences avec les applications universelles (que nous reproduirons ici avec permission)

 

Windows Phone 8.1 XAML et les applications universelles incluaient des API WinRT qui présentaient de nombreux problèmes, dont certains pour lesquels il n'existe aucune solution. Mais d'abord, parlons du nom "Universal Apps". Je pense que c'est assez arrogant d'appeler quelque chose d'universel qui cible deux plates-formes, que peu d'utilisateurs utilisent ou dont ils se soucient franchement. De plus, si vous ne pensez qu'aux plates-formes Windows, ces applications ne sont pas non plus universelles, car elles ne peuvent pas cibler les versions Windows les plus utilisées (7 et XP). Mais je m'égare.

Il fait le point ici, que j'ai fait il y a un moment. Ni WP8.1 ni W8.1 n'offrent encore suffisamment de valeur aux développeurs pour développer pour l'un ou l'autre parce que, comme je l'ai dit, «les utilisateurs de Windows A, mais ces utilisateurs ne veulent pas nécessairement d'applications. Les utilisateurs de Windows Phone veulent des applications, mais il n'y en a pas beaucoup » .

Les utilisateurs ne sont cependant pas la seule chose qui empêche les développeurs de passer aux applications WinPRT 8.1. Il y a aussi des problèmes techniques :

 

Des API plus foirées

Donc, l'API de lecture audio en arrière-plan pour Windows Phone 8.1 est foirée, autre chose ? Bien sûr. BackgroundDownloader est un autre exemple. Dans Silverlight, il y avait un BackgroundDownloader qui était assez limité, mais cela fonctionnait. Dans Universal Apps, il y a un nouveau BackgroundDownloader avec quelques nouvelles fonctionnalités, et certaines essentielles manquantes. Par exemple, dans Silverlight, chaque téléchargement peut avoir une balise, où vous pouvez stocker toutes les données afin que vous sachiez quelque chose sur le téléchargement lorsqu'il se termine (à quelle entité commerciale il appartient, etc.). Plus dans Universal Apps. Il n'y a pas de balise, vous devez donc créer et gérer votre propre type d'index pour tous les téléchargements, afin de pouvoir les faire correspondre à vos entités commerciales. Une gêne, mais rien que vous ne puissiez gérer, n'est-ce pas.

Un commentateur sur le blog a également ajouté que les apis de l'appareil photo n'étaient pas aussi bons que ceux de Silverlight et on m'a dit que les apis 8.1 manquaient d'intégration d'objectif.

L'API de la caméra sur WP8.1 est également horriblement foutue. Il n'y a aucun moyen d'obtenir des images d'aperçu. Avec l'API Silverlight, vous pouvez simplement vous abonner à un événement et pousser les images basse résolution via ZXing à plusieurs ips. Dans WinRT, le mieux que vous puissiez faire est de prendre plusieurs photos les unes après les autres, parfois avec le flash, et de numériser environ 0.8 images par seconde.

Les performances en pâtissent également avec la quantité de travail nécessaire pour obtenir un défilement fluide ayant augmenté en 8.1 par rapport à 8.0.

Performance

Dans Silverlight, j'utilisais couramment le LongListSelector pour afficher des données, en l'utilisant avec un WrapPanel lorsque j'avais besoin de créer une disposition à deux colonnes. Le LongListSelector a disparu, dans Universal Apps, vous devez également utiliser GridView sur Windows Phone. Ou vous pouvez utiliser ListView avec un panneau d'habillage personnalisé que vous écrivez vous-même ou que vous téléchargez quelque part, mais cela demande un certain effort pour qu'il effectue correctement la virtualisation.

Vous utilisez donc GridView sur Windows Phone 8.1 et Windows 8.1 pour le rendre cohérent. Ajoutez-y des dizaines d'éléments avec des images et les performances commencent à en souffrir. Des espaces réservés gris apparaîtront et, plus important encore, ne disparaît jamais. Vous n'avez pas besoin d'images, ajoutez simplement environ 300 éléments de texte uniquement au GridView et les espaces réservés gris commenceront à s'afficher lors du défilement

Le but de cet article n'est pas de dénigrer Microsoft, c'est d'expliquer pourquoi les développeurs ne sont peut-être pas encore disposés à créer des applications universelles. Ce n'est pas une méthode absolument meilleure, il s'agit d'une mise à niveau dans certains domaines et d'un déclassement dans d'autres (les utilisateurs de Windows Phone connaissent bien ce sentiment). Si Microsoft veut attirer les développeurs, ils doivent travailler plus vite qu'ils ne le font actuellement, « bientôt » et « dans les mois à venir » ne sont pas attrayants pour les personnes dont les moyens de subsistance dépendent du fait que « bientôt » soit « hier ». Heureusement, il y a des signes que cela pourrait changer. WP 8.1.1 a apporté de nouvelles API (bien que restreintes) et 8.1.2 est censé (dans un article désormais caché) permettre aux développeurs de créer de nouvelles applications géniales. Microsoft peut changer à l'avenir et c'est très bien. Pour de nombreux développeurs qui subissent des pressions pour créer des applications universelles maintenant, l'avenir ne peut pas arriver assez tôt.

Pour plus que les extraits que vous obtenez ici, lisez l'article complet ici. Pour mon article plus détaillé, voir ici.