Chrome : Split View sur iOS, la bêta de la version 47 veut flatter les développeurs

Chrome : Split View sur iOS, la bêta de la version 47 veut flatter les développeurs

Et puis un HTTPS avec des erreurs, ce n'est pas du HTTPS

Avatar de l'auteur
Vincent Hermann

Publié dans

Société numérique

23/10/2015 4 minutes
13

Chrome : Split View sur iOS, la bêta de la version 47 veut flatter les développeurs

Google vient de publier une nouvelle version de Chrome pour iOS, ajoutant notamment la pleine compatibilité avec iOS 9. Parallèlement, certaines nouveautés de Chrome 46 pour ordinateurs sont passées inaperçues, tandis qu’une bêta de la version 47 fait son apparition.

Chrome 46 pour iOS apporte donc la compatibilité complète avec la version 9 du système mobile d’Apple. Concrètement, cela se traduit par la prise en charge d’une fonctionnalité exclusivement disponible sur iPad, et encore pas sur tous : la Split View. On rappellera qu’il s’agit de positionner deux applications côte à côte, permettant à l’utilisateur d’utiliser les deux en même temps. Pratique par exemple si on participe à une discussion pendant que l’on cherche un itinéraire sur Plans ou Google Maps.

Cette fonctionnalité n’est cependant disponible que sur les iPad Air 2, les iPad mini 4 et sur les futurs iPad Pro, qui seront disponibles le mois prochain. On aurait aimé par ailleurs que la compatibilité iOS 9 s’élargisse à la prise en charge du 3D Touch sur iPhone 6S et 6S Plus. Contrairement à Safari par exemple qui permet d’accéder directement à certaines fonctions comme la liste de lectures et les signets, l’icône de Chrome reste désespérément statique.

Ajoutons que Chrome 46 permet d’enregistrer des cartes bancaires pour se simplifier la vie dans le cas où on réaliserait régulièrement des achats en ligne depuis son terminal mobile. La mise à jour est en tout cas disponible dans l’App Store, pour un poids d’environ 85 Mo.

Chrome 46 pour les ordinateurs entérine la coupure du son sur les onglets

Parallèlement, certaines nouveautés de la version 46 pour les ordinateurs sont passées un peu inaperçues lors de son arrivée. On note par exemple que la possibilité de couper le son d’un onglet a quitté les « flags » pour devenir une fonctionnalité standard : il suffit de faire un clic droit sur un onglet pour le museler. Dommage cependant que la capacité de cliquer directement sur l’icône de haut-parleur ait disparu.

Notons également une évolution d’icône pour signaler quand une connexion HTTPS contient de petites erreurs. Auparavant, l’icône affichée était celle d’un cadenas accompagné d’un petit triangle jaune. Désormais, Chrome considère que des erreurs, même minimes, sont équivalentes une connexion HTTP classique. L’icône affichée sera donc celle d’une page blanche pour avertir l’utilisateur qu’il n’y a pas de chiffrement. Seront de fait directement impactées les pages présentant un contenu mixte d’éléments chiffrés et d’autres en clair, notamment les images. Sur son blog, Google avait expliqué que ce changement devait encourager les éditeurs à basculer sur des connexions totalement chiffrées.

chrome https

Chrome 47 fournit d'importantes améliorations aux développeurs

La bêta de Chrome 47 est par ailleurs disponible pour l’ensemble des plateformes aptes à recevoir des préversions, dont tous les systèmes fixes et Android. La nouvelle mouture permet sur ce dernier de mettre en place des écrans de chargements pour les applications web épinglées sur l’écran d’accueil. C’est le développeur qui peut choisir quoi afficher : nom, couleur de fond, icone et couleur de la barre de notification. L’écran n’est utile que lorsque l’application met du temps à charger, histoire d’occuper les yeux de l’utilisateur pendant ce temps.

Chrome 47 apporte également une importante possibilité pour les développeurs web : requestIdleCallback(). Toutes les fonctions qui l’utilisent sont accompagnées d’une limite, mais le résultat peut arriver avant de l’atteindre. La méthode sert surtout à planifier des actions particulières, et donc des charges, durant les périodes où la machine est considérée comme inactive (idle). Rien n’empêche par ailleurs d’enregistrer un résultat temporaire, qui sera alors complété par la même fonction lors de la période inactive suivante.

Toujours pour les développeurs, mais avec un impact potentiel très concret pour l’utilisateur, les notifications peuvent désormais être paramétrées pour rester affichées sur l’écran jusqu’à être manuellement validées. Google indique que cela devrait rendre certaines notifications beaucoup plus utiles puisque leur défaut actuel est de nécessiter la présence devant l’écran au moment où elles surgissent.

Ceux qui veulent en savoir plus sur la bêta de Chrome 47 pourront se rendre sur la page qui lui est consacrée.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Chrome 46 pour les ordinateurs entérine la coupure du son sur les onglets

Chrome 47 fournit d'importantes améliorations aux développeurs

Fermer

Commentaires (13)


Pas convaincu sur le changement d’icônes. Je pense que pas mal de personnes vont regarder les caractères “https” sans voir qu’il n’y a pas de cadenas…


Moi quand c’est vert ça va.



Quand c’est pas vert ça ne va pas. Aussi simple :)



Bon… maintenant reste plus qu’a savoir comment vont se débrouiller nos potes Daltoniens&nbsp;<img data-src=" />


“L’écran n’est utile que lorsque l’application met du temps à charger,

histoire d’occuper les yeux de l’utilisateur pendant ce temps.”

&nbsp;Tout va bien les devs vont pouvoir continuer a coder comme des porcs… <img data-src=" />


Oui parce que tout le monde a une connexion fibre.

Enfin j’imagine que les app web sont distantes, sinon effectivement <img data-src=" />


Si tu as besoin d’envoyer 10Go au client pour qu’il puisse commencer a utiliser l’appli c’est qu’il y a un petit soucis.

Je me rapelle de certains jeu en flash où pendant le chargement du jeu tu avais un autre mini jeu pour patienter…








Oulanos a écrit :



Moi quand c’est vert ça va.



Quand c’est pas vert ça ne va pas. Aussi simple :)



Bon… maintenant reste plus qu’a savoir comment vont se débrouiller nos potes Daltoniens&nbsp;<img data-src=" />





Avec le joli cadenas :)



La homepage de nextinpact contiens du contenu mixte (static.nextinpact.com en http)








Krogoth a écrit :



Si tu as besoin d’envoyer 10Go au client pour qu’il puisse commencer a utiliser l’appli c’est qu’il y a un petit soucis.

Je me rapelle de certains jeu en flash où pendant le chargement du jeu tu avais un autre mini jeu pour patienter…







J’ai une connexion 512k alors une information de chargement ca peut être utile <img data-src=" />



Si tu savais ce qu’on peut faire avec 512kb… (donc 1 sec de chargement).


C’est quoi ce ton condescendant sur une réplique hors des réalités ?

Ton cerveau est coincé sur les demo c’est çà ?



Je suis d’accord pour dire que certains programmes manquent d’optimisation, sont lourd etc. mais troller dans l’autre sens c’est franchement crétin.


Ne te méprend pas. Je ne cherche vraiment pas à être condescendant mais trop souvent on avance l’argument du bon débit ou des l’augmentation de puissance des machines etc pour faire de la merde. Avec 512Kb tu peux vraiment faire quelque chose de sympa.



Dans le web trop souvent on peu voir par exemple des dev utiliser jQuery pour utiliser une simple fonction javascript de quelques centaines d’octet.



A force de compter sur la techno et de se faire assister on finit par faire de la merde et ca ne gène personne c’est ca?


Ce n’est absolument pas ce que j’ai dis non plus.

Fait ton propre framework javascript et tu verras si tu peux rester ultra light longtemps. Heureusement, les navigateurs ont un support javascript meilleur que par le passé et surtout un support CSS plus cohérent à travers les différents navigateurs. Si tu ajoutes les minifier tu finis par gagner serieusement en taille. Mais dans une webapps il y a aussi l’html, les images et le tout pouvant être alourdi par le contenu. Il y a aussi le débit qui joue, la latence et la charge serveur…



Si je reste sur ton exemple JQuery, il intègre énormément de fonctionnalité pratique pour le développeur (sinon il n’existerait pas…). La plus part des framework sont là car il y a des manques à JS.


Je ne critique pas les frameworks mais les devs qui intègrent jQuery dans toutes les pages d’un site pour “par exemple” faire un simple “go to top”. A un moment il faut aussi se poser la question de l’utilité d’allourdir inutilement des plusieurs Ko sa page. Pareil pour les images, combien de fois le poids d’un png pourrait être diminué de 50% avec une baisse de qualité absolument imperceptible?

Et ceux qui ont besoin de ce genre d’artifice pour palier à la lourdeur de leur code sont rarement ceux qui prennent la peine de minifier leur code (voir même d’utiliser les versions minifier des frameworks qu’ils utilisent).