L’argument le plus employé en faveur des applications est une meilleure expérience utilisateur. La fluidité de Flipboard par exemple, a encore du mal à être atteinte dans un navigateur, mais pour le reste, ce que l’on croyait réservé aux applications natives, comme le GPS, est maintenant accessible par les pages web grâce au HTML5.

Les détracteurs des applications, pointent leur côté “fermées” où toute interaction avec l’extérieur est guidée/choisie par les développeurs. Il existe bien des mécanismes inter-application comme les intents d’Android ou les URL Schemes d’iOS, mais rien de comparable avec la vraie liberté qu’apporte un élément fondamental du web : le lien.

Alors que l’avenir des sites pour mobiles semblait scellé au profit des applications, la décision de faire une application mobile ou un site mobile reste un choix délicat.

C’est peut-être la gestion des mises à jour, les évolutions plus aisées et la présence sur un grand nombre de plateformes à la fois qui feront des sites un choix décisif. Développer une fois et déployer sur de multiples plateformes, voilà ce que permettent de faire plus aisément les applications web.

Un mode “hybride” est aussi apparu : des applications natives encadrent ( wrapping ), à la manière d’un navigateur, des applications web, à l’instar de Gmail et de Facebook sur mobile.

Il s’agit tout de même de faire la différence entre un site web et une application web. S’il s’agit simplement de présenter du contenu, un site est bien adapté, d’autant que s’il utilise les techniques de conception adaptables, ( responsive web design ) justement, la consultation depuis un mobile ou un ordinateur de bureau se fera sur les mêmes pages, effaçant ainsi le problème du double développement et en gardant l’aspect identitaire du design. En revanche, s’il s’agit d’un utilitaire, d’un outil d’administration, ou typiquement d’une application de la catégorie “productivité”, on devra se référer à cette règle, certes un peu facile à ce moment de la réflexion :

Si ça peut se faire sur le web, faite le sur le web, sinon faite une application .
(source)

Enfin, un élement de plus pour apporter du crédit aux applications web : Apple est un des grand promoteur du HTML5, même si c’est potentiellement pour lui une solution perturbatrice de son marché d’application. On peut penser à un risque … mais bien calculé ?

Dernière minute qui sème encore le doute : Facebook abandonne HTML5 pour son application iOS, qualifiée de trop lente.

Sources :

• responsive web design
• Les applications natives seront elles remplacees par celles en HTML5 La fin du regne du natif annoncee pour l an prochain
• 7 Things Making Digital Publishing Better Now
• Wired 97
• Wired 2000
• Why apps are not the future
• The App is Dead (OK Not Really, But The Browser Is Back)
• How Facebook Mobile Will Evolve With HTML5

Entre les puces RFID, les ordinateurs de bords, les GPS et les smartphones, se sont plus de 24 milliards d’objets connectés qui sont prévus à l’horizon 2020.

Projection sur le nombre d’objets connectés en 2020+

La proposition open source d’IBM part du constat qu’aujourd’hui les communications inter-machines sont souvent basées sur des protocoles propriétaires ou HTTP via SOAP et REST. Ces derniers sont gourmands en bande passante et leur traitement demande de l’énergie .

MQTT ( Message Queuing Telemetry Transport ) serait le pendant du HTTP pour la communication entre les appareils et fonctionnerait sur le modèle pub/sub ( Publication/Souscription).

Source : RWW

Alors que l’ASCII ne peut représenter que 128 caractères, Unicode est constitué de plus de 109000 caractères, et pourrait en contenir potentiellement des millions.

Puisqu’il s’agit d’une norme, comparer deux textes Unicode ne devrait pas poser de problèmes. Sauf que…  il peut y avoir plusieurs représentations d’un même caractère en Unicode : la Forme Normale Canonique (NFC) ou la Forme Normale Décomposée (NFD).

Sous la forme NFC, le caractère “é” possède son propre code , alors que sous la forme NFD il est décomposé dans sa forme de base “e” combinée avec son signe diacritique (l’accent) ” ‘ “.

Donc, pour deux mots codés Unicode semblants similaires, il faudra faire attention à la normalisation ( exemple Python ) :

>>> import unicodedata
>>> c = unicodedata.normalize("NFC", u"é" )
>>> print repr(c)
u'\xe9'
>>> d = unicodedata.normalize("NFD", u"é" )
>>> print d
>>> print repr(d)
u'e\u0301'
>>> c == d
False

Sources :  Nicolas SURRIBAS, doc Python  et Wikipedia

Le projet est hébergé par la Linux Foundation, tourne sur un noyau Linux et l’environnement est basé sur HTML5 permettant un large support par les développeurs mais aussi des matériels. Un OS aguichant à l’heure où les développeurs semblent contrariés par la fragmentation d’Android et délaissent de plus en plus les solutions natives au profit des solutions web (cf. analyse IDC et Appcelerator).

La création d’une application pour Tizen avec le SDK ( mod d’Eclipse ) s’apparente à la création d’une application web : on retrouve les sacro-saints dossiers js/, css/, et index.html. Le code est ensuite à écrire en Javascript agrémenté des API Tizen pour accéder aux fonctionnalité des appareils.

Il équiperait des smartphones HTC et Samsung dans le courant du second semestre 2012.

Source : Clubic

Cette solution permet de développer des applications mobiles en HTML/CSS encapsulées dans des applications natives propres à chaque plateforme.

La boussole, la caméra, les contacts, etc, sont ainsi accessibles en utilisant des APIs.

source : FrAndroid

Le conseil s’agrémente d’un outil, le Mobilomètre, permettant de voir son site comme sur un mobile et donne des recommandations pour améliorer l’expérience.

Appsthru.com n’a pas à proprement parlé de version mobile, le site utilise un design adaptable ( responsive web design )  lui permettant de s’afficher sur les mobiles et les tablettes en ajustant les positions et les proportions de certains éléments comme les menus et les widgets.

Le résultat du test est bon ( autosatisfaction ) :

Les plugins permettent d’insérer rapidement un player pour une playlist, ou encore la discographie d’un artiste donné.

L’API donne accès aux détails d’un artiste, aux titres d’un album etc.

Enfin les SDK permettent d’instancier un player customisable et pilotable pour les différentes plateformes.

Parmi ces bonnes pratiques, Google nous conseille d’omettre la partie protocole des URLs pointant vers les images, les scripts etc, si ceux ci sont amenés à être aussi appelés depuis des pages sécurisées.

Ainsi, au lieu d’écrire :

<script type="text/javascript" src="http://www.google.com/js/gweb/analytics/autotrack.js"></script>

on écrira :

<script type="text/javascript" src="//www.google.com/js/gweb/analytics/autotrack.js"></script>

Ceci évitera les avertissements de contenu mixte lors de l’affichage de la page depuis http ou https.

Il est en revanche un peu tôt pour appliquer certains conseils,  comme celui d’omettre les tags optionnels du HTML5 (html,head) , car tous les navigateurs ne sont pas près, et les habitudes des développeurs bien ancrées …

Source : Webmaster Central Blog

Google et Microsoft proposent déjà des CDN pour les librairies javascript, mais seulement pour les plus connues ( jQuery, Dojo, Prototype par exemple ).

CDNJS est une initiative pour la mise à disposition d’un plus grand nombre de librairies, en laissant chacun en ajouter via un Fork GitHub et une demande d’intégration ( Pull Request ) qui sera modérée par l’équipe.

On y retrouve aujourd’hui plus de 150 librairies, dont les très à la mode backbone.js, cufon, html5shiv, less.js, require.js, underscore.js, etc

Externaliser les librairies fondamentales pour le bon fonctionnement de son site est un sujet sensible, mais le projet est hébergé sur les serveurs de CloudFlare , un des leader de l’optimisation du trafic web. Pour le moment, il démontre un uptime très correct et de temps de réponse s’améliorant.

A noter : seuls les fichiers javascript des librairies sont disponibles via ce CDN, les CSS et autres images et SWF ne sont pas acceptés. Mais la version CDNCSS est dans les cartons …

Cependant, la récolte d’information étant mondiale, et même si en Europe cette tendance est réelle depuis Octobre 2011, la résolution 1024×768 reste encore – mais de peu – la plus utilisée aux Etats-Unis.

source : techcrunch