[Build 14] – App packaging and deployment for windows

Mail de Mehdi
Samedi 5 avril 2014 10:17

App packaging and deployment for windows


Speaker
: Barclay Hill, Jason Salameh


Premières nouveautés
:
Seulement les ressources nécessaires (fichier de localisation, images seront téléchargées (on nous annonce un gain de 10% ou plus au niveau du stockage)

Pour les images, le système est capable de choisir quel scale d’image il lui faut.

Le speaker nous montre un projet universal app, plus précisément les manifets des projets puis, il génère une app phone, il nous montre les bundle (comme quoi ce n’est pas obligatoire mais que ça serre à optimiser les packages)

Les applications Silverlight sont générées toujours avec un xap mais sont déployés comme un appx (en plus du manifest normal on a un manifest du style Windows 8)

La création d’une application WP 8.0 est toujours possible.

Les mises à jour de 8 à 8.1 et de 8.1 Silverlight vers universal app est dans un seul sens, pas de retour en arrière possible.

Avec les applications Silverlight on joue avec deux manifest, dans cet exemple, le speaker change le mode de notification et le passe vers du WNS (dans le manifest silverlight) on voit alors que des options disparaissent, ce qui est normal puisque c’est le nouveau manifest (type Windows) qui gère ça.

Pour les nouvelles features, elles sont toutes gérées dans le nouveau manifest.

Dans le store, on peut maintenant réserver un nom d’application pour toute la « famille » phone/windows en même temps.

On parle maintenant des améliorations de stockage :

On peut partager des fichiers entre applications !
Résultat, on consomme de 10 à 25 % de mois en disque. Le speaker nous conseille de ne pas minifier les fichiers (exemple de jQuery) pour que toutes les applications qui l’utilisent, prennent un seul fichier commun.

Les utilisateurs peuvent maintenant installer des applications sur carte SD, les applications peuvent être encryptées et les développeurs peuvent interdire l’installation des apps sur les cartes SD avec une option dans le manifest.

C’est l’utilisateur qui choisit ou il installe les applications par défaut depuis l’application storage sence.

Il nous montre un exemple d’appli lourde (Halo) qui tourne très bien sur une carte SD (milieu de gamme) avec un téléphone bas de gamme.

Mehdi

[Build 14] – Windows Runtime for Windows Phone Developers

Mail de Mehdi
Vendredi 4 avril 2014 10:31

Windows Runtime for Windows Phone Developers

// Speakers : Doug Holland, Jerry Nixon

On débute la session par un petit Historique de WP (7.0 Silverlight, 7.5 Silverlight, 7.8 Silverlight, 8.0 Silverlight, 8.1 Silverlight et maintenant WinRT)
Le speaker commence par nous dire pourquoi nous devons rester sur du Silverlight : Beaucoup d’investissement (une base importante de code) utilisation de certaines API toujours pas disponible avec WinRT (exemple : VoIP, Lock Screen WP) et que Microsoft respecte nos investissements et que Silverlight pour WP continuera à être supporté/amélioré en parallèle que WinRT.

Ensuite il nous dit pourquoi nous devons re targeter nos applications en Silverlight 8.1. La réponse est simple : pour avoir accès à plusieurs nouvelles API (accès à la carte SD, GeoFencing, App Sharing)

Et enfin, il nous dit dans quel cas nous pouvons/devons choisir WinRT. Et là aussi la réponse est plutôt simple : plus de convergences (avec Windows) nouveaux contrôles (lesquels ? aucune présentation) choix de langage …

Petit rappel sur le async await (avec comme règle toute méthode qui dépasse les 50 millisecondes doit être en asynchrone pour ne pas bloquer l’interface et c’est ce qui fait dans WinRT).

Si on choisit le développement avec WinRT le speaker nous présente plusieurs API qui ne sont plus disponibles et qui sont généralement remplacées par l’API équivalente sur Windows.

Si on utilise Microsoft.Phone.Task :
– MarketplaceReviewTask n’est plus disponibleet doit être remplacé par un lacement d’une uri qui redirige vers le store
– Même chose pour le MarketplaceSearchTask
– Le WebBrowserTask est remplacé par Windows.System.Lancher.LanchUri
– AdressChooserTask remplacé par Windows.ApplicationModel.Contacts.ContactPicker
– PhoneCallTask remplacé par Windows.ApplicationModel.Cells.PhoneCallManager
– SmsComposeTask remplacé par Windows.ApplicationModel.Chat.ChatMessageManger
Microsoft.Phone.BackgroundAgent est remplacé par BackgroundTask (comme sur windows 8) avec plus de features.

La navigartion sur WP ne se fait plus par chemin, mais par type de page (comme sur windows 8)

Le bouton back ne ferme plus automatiquement l’application.

Les fichiers de localisation sont maintenant de resw en XAML nous avons maintenant x : UId l’identifiant qu’on utilise uniquement dans ces fichiers. On peut spécifier une propriété genre LeUidDunElement.text ou LeUidDunElement.Foreground.

Dernier point de la session, on nous reparle de la particularité du fileOpenPicker, quand on l’utilise on quitte l’application (elle passe donc en suspended voir elle est tuée par l’OS) donc quand on sélectionne un fichier l’application est relancée on passe par l’event activeted avec en arguement l’activation par fichier.
Mehdi

[Build 14] – Modern Camera and Imaging Apps in Windows and Windows Phone

Mail de Mehdi
Vendredi 4 avril 2014 10:31

Modern Camera and Imaging Apps in Windows and Windows Phone
// Speakers :
Jeff Day, Rene Schulte
// On nous présente les nouveautés de la fonction caméra.
Première constatation (comme dans les autres sessions) l’API de caméra se cale maintenant sur celle de windows.

Windows.media.capture

On peut toujours utiliser l’ancienne api, mais elle n’est disponible que pour les applis Silverlight.
Nouveautés :
– On peut enregistrer une (des) photo(s) durant une vidéo.
– Full acess video library i/o access
– HDR
CameraCaptureUI n’est pas disponible sur téléphone on passe plutôt avec le fileopenpicker qui nous permet soit de récupérer une photo de la pellicule ou capturer une nouvelle photo.

Le workflow est donc différent pour les appli Windows phone, pas de async await, mais plutôt on « quitte » l’appli pour ouvrir le fileopenpiker ensuite quand on revient vers l’appli l’event activated est déclenché, il faut donc faire les branchements qu’il faut pour gérer cela.

Pour de la capture en temps réel le partage de code est possible puisqu’on utilise une UI spécifique qu’il faut développer.
La nouvelle api nous donne accès à de nouvelles fonctionnalités comme la brillance le zoom le focus le contraste …
Avec ScreenCapture, on peut maintenant capturer en vidéo ce qui se passe dans l’application (valable uniquement sur phone).
Deux démos :

– La première « basic capturing » exemple de capture vidéo sur windows et WP.

– La deuxième un peu plus avancé ou le speaker nous montre comment coder une capture avec le mode HDR qui n’est disponible que sur WP (et que sur certains téléphones avec une puce spécifique, les téléphones actuels ne seront pas forcement supportés cela dépendra du driver, et donc du constructeur) pour l’instant aucun téléphone ne le supporte, il n’y a que le simulateur qui le fait 🙂 . C’est au développer de vérifier la disponibilité de cette fonction dans le code, aucun flag n’est présent dans le manifest pour alerter l’utilisateur de cette capacité spécifique.

 

Mehdi

[Build 14] – What’s new with Windows Phone Silverlight Apps !

Mail de John
Vendredi 4 avril 2014 06:11

What’s new with Windows Phone Silverlight Apps!

 

Différences entre les applications XAML et les applications Silverlight.
Le framework XAML est le framework du futur. C’est là où les prochaines mises à jour auront lieu. Mais le framework Silverlight continuera à être mis à jour quelques temps afin de suivre les évolutions du framework XAML pour les applications existantes.

La convergence entre les API est de l’odre de 90%.


Cependant certaines API n’ont pas encore migrées :

– Lenses
– VOIP
– Camera Capture Task
– Clipboard
– Lockscreen Wallpaper
– Ringtone et Alarmes
– Simple sound effects (XNA)
– Photos Extensibility
– Search Extras

 

On enchaîne par une démonstration de la migration d’une application Silverlight 8.0 vers Silverlight 8.1

Les applications Silverlight 8.1 s’exécutent dans le même contexte que les applications WinRT. Pour cette raison, les applications Silverlight 8.1 disposent maintenant d’un fichier appxmanifest en plus de l’historique fichier WMAppManifest.xml. Les deux doivent être mis maintenus à jour.

Lorsque l’on migre en 8.1 il y a quelques « breaking changes » :

– CLR/Silverlight bug fixes
o Array.Sort (IntrospectiveSort à la place du QuickSort)
o DateTime.Parse (correction de bugs)

– Différences au niveau de contexte d’exécution des applications WinRT
o Fast App Resume est activé par défaut (resume vs replace)
o Appuyer sur back ferme l’application, à la différence des Universal Apps, mais il existe une API spéciale qu’il est recommandé d’utiliser pour que les applications Silverlight 8.1 fonctionnent comme les Universal Apps.

Fonctionnalités non supportés dans Silverlight 8.1 :
– Background Audio (existe dans les Universal Apps)
– Continuous Background Execution Agents (GPS Apps)

Nouvelles fonctionnalités et mises à jour :

– Nouvelles API disponibles pour les applications Natives (C++)
– WinRT APIs
– SD Card Support
– Share Source
– Share Target
– WNS Push Notification Trigger
– WNS Notifications
– Storage
– GeoFencing
– Bluetooth 4.0
– Background Tasks
– Known Folders (Audio/Video/Photos/…)
– Appointments / Calendar Enhancements
– Email with Attachments
– Web Authentication
– Data Roaming
– Accessibility (UIA, Large Text, High Contrast)

On a ensuite une démonstration du remplacement d’un EmailComposeTask par un Share Contract avec une pièce jointe suivi d’une autre démonstration où on ajoute une BackgroundTask.

Le Store supporte maintenant 3 versions d’une application (7.1, 8.0 et 8.1).
Avant de pouvoir déployer une application 8.1 pour la première fois, il faut réserver un nom spécifique à cette version. Ce nom doit se trouver dans le appxmanifest et il faut l’éditer à la main en mode texte (voir slides de la présentation).

 

 

John

 

[Build 14] – From 4 to 40 inches Developing Windows Applications across Multiple Form-Factors

Mail de John
Jeudi 3 avril 2014 10:41

From 4 to 40 inches Developing Windows Applications across Multiple Form-Factors

Rappel de la différence entre la layout et les assets.
Layout: Physical Size and Shape, Viewing Distance, Effective Resolution
Assets: Detail Level, Scale Factor, Mastering

Il ne faut plus se demander quelle est la taille de mon application. Il faut se demander quelle forme a mon application (tall, thin, wide).

Démonstration de l’adaptabilité du layout et de la taille du contenu d’un jeu de morpion.
La résolution effective de l’application est importante, pas la taille de l’application.

Démonstration de l’utilisation des VisualState dans Blend pour s’adapter à la taille de l’application. (Utilisation d’un petit helper une classe de base d’une page qui change le VisualState en fonction de la taille).

Choisir de bons assets en fonction de la résolution. Si une image a beaucoup de détails en grande résolution et qu’on la redimensionne en une image à faible résolution elle sera très pixélisée. Il faut choisir une image avec moins de détails à faible résolution quitte à ce que l’image ne soit pas tout à fait la même que celle à haute résolution.

La densité relative des pixels d’une image est importante pas la densité réelle de pixels (DPI).
Il est important d’appliquer les conventions de nommage pour les assets (exemple image.scale-240.png) qui permettra de choisir automatiquement la bonne image en fonction de la résolution. Il faut quand même préciser la taille d’affichage de l’image car sinon le moteur de layout (HTML ou XAML) multipliera la taille de l’image au lieu de s’adapter au DPI.

Génération des assets :
– Déterminer la taille désirée de l’image en pixels effectifs
– Déposer ces assets dans le dossier partagé
– Multiplier la taille du layout par 2.4
– Déposer ces assets dans le projet Phone
– Vérifier que le résultat est le bon sur les appareils cibles (les émulateurs et simulateurs sont insuffisants pour une vérification d’assets)
– Si le resultat est bon vous avez fini
– Sinon essayez un scale factor supplémentaire de 1.4 ou 1.8

Création des masters assets :
– Dans l’idéal utilisez des assets vectoriels
– Sinon des bitmaps ayant un scale factor supérieur ou égal à 400%
– Exportez cet asset dans les scale factor cible nécessaires
– Ne pas oublier le niveau de détail
– Ne pas s’inquiéter si on a un asset à basse résolution

Mais où est le code ?
La plupart du temps il est inutile d’écrire du code pour gérer ce sujet.
Cependant voice quelques informations utiles pour la suite.
DisplayInformation.GetForCurrentView() :
– ResolutionScale (Windows (enum))
– RawPixelsPerViewPixel (WP (double))
– RawDpiX, RawDpiY (Ignore unless measuring real-world objects (ruler, hardware,etc..))
– LogicalDpi (avoid unless working with Direct2D or legacy code that assumes 96 DPI)

Silverlight : Information importante pour la migration d’application Silverlight vers WinRT. La résolution effective minimale pour les téléphones a changée. Il faut multiplier les constantes de taille par 0.8.

Utilisez les bons mots !
– Bien : Effective resolution / shape / scale factor
– Mal : physical resolution / orientation / DPI
Architecturez pour un layout flexible. Préférez l’utilisation de composants à celle de pages monolithiques :
– Laissez le moteur de layout faire son travail
– Focalisez-vous sur le bon set d’assets
– Commencez avec des master assets de haute résolution
– Ne générez que les scales factor nécessaires
– Assurez-vous que le niveau de détail est approprié

John