Sortie de l’application mobile Xebia pour iPhone et iPad

appli-XebiaC’est avec une joie non dissimulée que je vous annonce aujourd’hui la sortie de l’application Xebia pour iPhone et iPad. Publiée il y a tout juste quelques jours sur l’App Store, l’application vous propose de réunir au sein d’une seule et unique interface l’ensemble des flux d’informations de Xebia, ainsi que des bonus agiles qui viendront s’étoffer avec le temps.

L’application est optimisée pour iOS 7, mais fonctionne parfaitement sur iOS 6.

Où trouver l’application ?

Vous pouvez retrouver l’application mobile Xebia sur son mini-site dédié à l’adresse suivante: http://xebia-app.com, ou bien directement sur l’App Store.

Les fonctionnalités

Au menu des réjouissances :

  • L’application Xebia vous permettra de consulter l’ensemble des articles du blog dans un format spécialement adapté aux mobiles et tablettes Apple. En particulier, la mise en page des articles prend en charge la mise en forme des codes sources afin de rendre la lecture plus agréable.
  • Vous pourrez également retrouver les articles du blog Xebia grâce à leur tag ou encore leur catégorie. 
  • Si vous n’êtes pas un aficionados de Twitter ou déjà abonné à notre timeline, vous pourrez tout de même suivre les tweets de Xebia en consultant les dernières infos en un clin d’oeil sur un écran dédié.
  • En bon craftsman et agiliste convaincu, vous pourrez retrouver l’ensemble du deck de cartes Xebia Essentials, et éplucher leurs conseils avisés ! 
  • Par ailleurs, il sera possible de consulter les dates des prochains Tech Events et de visionner ceux déjà passés si vous les avez manqués. 
  • Enfin, si vous souhaitez être informé en premier de la sortie d’un nouvel article ou bien encore du dernier Tech-Event, sachez que vous pourrez être notifié en push à peine quelques instants après publication !

Du côté de la technique

Côté client

L’application Xebia est une appli native basée sur une stack Open-Source (AFNetworking, DTCoreText, MBProgressHUD, ParseKit, ShareKit, PKRevealController, SDWebImage, SVPullToRefresh, TTTAttributedLabel, et bien d’autres…).

Elle est construite dans le Cloud grâce à Travis-CI, et est disponible en Open-Source sur GitHub.

Côté tooling, elle s’appuie sur XCTool, l’outil de build de Facebook, ainsi que CocoaPods pour la partie gestion de dépendances.

Côté serveur

L’application mobile Xebia s’appuie sur un backend Node.js qui sert l’ensemble des informations via une API REST spécialement développée pour les besoins de l’application. Les différents flux d’informations sont synchronisés régulièrement dans le but de les stocker en cache et de les resservir dans un format adapté, avec des performances optimales. C’est par ailleurs ce même backend qui a la charge de servir les notifications de l’application mobile via l’APNS d’Apple.

Le fruit du travail sur le backend Node.js est disponible sous forme d’une présentation couverte lors de l’Open-XKE que vous pouvez retrouver à l’adresse suivante: http://akinsella.github.io/node-overview/

Quid d’une application mobile Xebia pour Android ? 

L’application mobile Xebia pour iPhone et iPad a été développée par mes soins dans sa première version dans le but de partager la passion de Xebians. Sachez qu’il n’existe pas actuellement d’équivalent à cette application pour Android, mais vous pouvez d’ores et déjà retrouver l’application Xebia Essentials de Gautier Mechling (Nilhcem) sur le Play Store de Google.

Feedback

Bien entendu, tout feedback est le bienvenu. N’hésitez pas à partager vos idées d’améliorations, anomalies rencontrées ou bien encore les fonctionnalités que vous attendez !

UITableView + API GitHub + CocoaPods = Keep it Simple, keep it Stupid!

Nous avons vu dans un article précédent comment utiliser RestKit pour se faciliter la vie lorsque nous travaillons avec des services web exploitant le format JSON. Toutefois, l’utilisation d’un framework fullstack peut se révéler contraignant dès lors que l’on sort du cadre pour lequel il a été destiné. Malheureusement, cela arrive souvent assez rapidement.

Nous verrons dans cet article comment reproduire une application similaire à celle construite grâce à RestKit, sans pour autant abandonner l’idée de gagner du temps grâce à l’utilisation de quelques librairies bien choisies :

Le monde iOS, comme tout environnement mature, dispose de nombreuses librairies Open Source intégrables dans vos projets via l’utilisation d’un Dependency Manager. Dans notre cas, nous utiliserons CocoaPods déjà présenté dans un article précédent.

La création de ce tutoriel fait suite à une présentation en XKE d’une session d’1h30 d’introduction aux développements iOS. Ce tutoriel est donc réalisable en un temps raisonnable en suivant les instructions ci-dessous.

Création du projet

Avant d’utiliser CocoaPods, vous devrez créer un projet de type Empty Application pour iOS via XCode:

Vous aurez ensuite à créer un fichier Podfile à la racine de votre projet XCode avec les dépendances suivantes:

platform :ios, '5.0'
pod 'JSONKit', '1.5pre'
pod 'Underscore.m', '0.2.0'
pod 'AFNetworking', '1.1'
pod 'MBProgressHUD', '0.6'
pod 'SVPullToRefresh', '0.4'
pod 'SDURLCache', '1.2'
pod 'AFHTTPRequestOperationLogger', '0.10.0'
pod 'DCKeyValueObjectMapping', '1.3'

Puis, vous devrez exécuter la commande suivante pour générer le workspace et intégrer le code des dépendances:

pod install

Il faudra alors relancer votre projet en ouvrant le fichier *.XCodeWorkspace, plutôt que le fichier *.XCodeProject. Vous serez alors prêt à développer votre application.

Continuer…

Intégration de RestKit avec une UITableView

Nous avons découvert dans un précédent article comment utiliser RestKit pour récupérer des structures de données JSON depuis une ressource HTTP et les mapper sur un modèle métier. Nous allons voir dans ce nouvel article comment adapter le code existant pour afficher les résultats dans une UITableView iOS. Pour cela, nous allons continuer à travailler avec les APIs GitHub, et nous fixer pour objectif d’afficher les utilisateurs d’une organisation.

Notes: 

  • La version actuelle de RestKit est la 0.20. Cet article met en oeuvre la version 0.10.

Installation

Dans un premier temps, nous allons créer un projet adapté pour iOS via Xcode. Vous devrez sélectionner dans l’assistant de création de projet une application pour iOS avec un template de type Empty Application.

Capture-d’écran-2012-10-28-à-09.27.53.png

Dans un second temps, nous allons cibler dans notre fichier de Podfile la plateforme iOS, puis ajouter une dépendance appelée SDWebImage qui sera présentée plus tard:

platform :ios

pod 'JSONKit',                          '1.5pre'
pod 'LibComponentLogging-Core',         '1.2.2'
pod 'LibComponentLogging-NSLog',        '1.0.4'
pod 'Reachability',                     '3.0.0'
pod 'RestKit',                          '0.10.1'
pod 'Underscore.m',                     '0.1.0'
pod 'SDWebImage',                       '2.6'

Les autres dépendances ont été ajoutées lors de notre précédent article. Pour plus d’informations sur l’utlisation de CocoaPods, c’est par ici

Description de l’API GitHub

En complément de l’accès au listing des repositories d’une organisation, nous allons utiliser une seconde ressource de l’API GitHub qui permet de lister les utilisateurs d’une organisation. L’URL est la suivante:

https://api.github.com/orgs/:organization/public_members

Continuer…

Introduction à RestKit

Lorsque vous développez une application iOS ou bien OS X travaillant avec des flux de données JSON, vous pouvez décider de vous contenter d’utiliser ce que les SDK d’Apple proposent ou bien vous pouvez vous reposer sur des librairies qui vous facilitent le travail.

Si vous optez pour la première solution, le travail à accomplir peut se révéler complexe et fastidieux. Mieux vaut s’appuyer sur des librairies reconnues pour leur qualités telles qu’AFNetworking pour la gestion des appels HTTP ou bien encore JSONKit pour la sérialisation & désérialisation de payloads JSON.

En utilisant ces librairies vous pourrez mettre de côté une partie de la complexité, il vous restera tout de même à gérer une stratégie de mise en cache des données et vous devrez mapper les payloads JSON avec une représentation objet.

Toutefois, si vous ne souhaitez pas gérer ces problèmes à la main, il vous reste la possibilité d’utiliser la librairie RestKit qui propose:

  • La consommation de données JSON depuis un serveur distant
  • Le mapping entre les structures de données JSON et les objets de votre modèle de données
  • Le stockage en cache de requêtes effectuées
  • Le stockage en base de votre modèle métier via l’utilisation de CoreData
  • L’initialisation de votre base de données

Initialisation du projet

Si vous souhaitez manipuler le code source fourni dans cet article, vous devrez utiliser CocoaPods que nous avons découvert dans un article précédent.

Avant d’utiliser CocoaPods, vous devrez créer un projet en ligne de commande pour OS X via Xcode:

xcode

Ensuite, vous aurez à créer un fichier Podfile à la racine de votre projet Xcode avec les dépendances suivantes:

platform :osx
pod 'JSONKit',                      '1.5pre'
pod 'LibComponentLogging-Core',     '1.2.2'
pod 'LibComponentLogging-NSLog',    '1.0.4'
pod 'Reachability',                 '3.0.0'
pod 'RestKit',                      '0.10.1'
pod 'Underscore.m',                 '0.1.0'

Puis, vous devrez exécutez la commande suivante:

pod install

Il faudra alors relancer votre projet en ouvrant le fichier *.XCodeWorkspace, plutôt que le fichier *.XCodeProject. Vous serez alors prêt à tester RestKit.

Continuer…

Programmation fonctionnelle en Objective-C

underscoremDans un article précédent, nous avons entrevu les possibilités offertes par l’utilisation des Blocks en Objective-C. Leur similarité avec les expressions lambda de la programmation fonctionnelle que vous pouvez retrouver dans Java 8, Scala ou bien encore JavaScript est évidente. Cependant, nous ne sommes pas habitué avec Objective-C à penser ou bien écrire dans un style fonctionnel. Cependant, il existe des libraries qui permettent de faciliter l’usage de l’approche fonctionnelle. Plusieurs projets ont même fleuri depuis la mise à disposition des blocks avec la sortie d’iOS4.
En JavaScript, la librairie underscore.js est très appréciée par les développeurs web pour sa simplicité et son efficacité. Cette librairie a d’ailleurs tellement de succès qu’elle a traversé la frontière des langages pour être implémentée en Objective-C! Il en existe à ce jour au moins deux implémentations, toutes les deux sous license MIT.

Le projet Underscore.m semble fournir un support plus abouti des fonctionnalités proposées par la librairie JavaScript originale, et surtout propose un site documentaire complet qui permet de démarrer rapidement et de trouver un grand nombre d’exemples.

Installation

Pour démarrer un projet avec Underscore.m, rien de plus simple, il suffit d’utiliser CocoaPods que nous avons découvert dans un article précédent.

Pour rappel, si vous n’avez pas encore installé CocoaPods, il suffit de lancer les commandes suivantes pour installer l’outil (A condition d’utiliser une version 1.9 de Ruby):

$ gem install cocoapods
$ pod setup

Continuer…

Utilisation des Blocks en Objective-C


Introduits en 2010 avec la sortie d’iOS4, les Blocks ont profondément changé la manière d’écrire des applications en Objectif-C.

L’implémentation de callbacks via la création de protocole est un procédé verbeux mais qui a l’avantage de rester simple à comprendre. Les blocks quant à eux ont une syntaxe déclarative moins évidente à appréhender de prime abord, mais sont bien plus expressifs et permettent d’éviter les allers et retours dans le code entre protocoles, interfaces et implémentations.

A travers cet article, je vous propose de découvrir les différences de styles qu’il existe entre l’usage des protocoles, plus classiques, et des blocks qui se veulent plus modernes.

La gestion d’événements dans iOS

Un programme informatique dans la plus simple de ses expressions un simple traitement exécutant de façon séquentielle une suite d’instructions. Cependant, la plupart du temps une application plus complexe aura à réagir à différents événements qu’ils proviennent d’interactions avec le réseau, avec le système de fichier ou bien encore avec la personne qui le commande via le clavier, la souris ou le touché. Le plus souvent ces événements sont notifiés au programme sous forme de callback.

Sous iOS, un callback résultant d’un événement peut prendre 3 formes:

  • Le callback de type Target-action: Lorsqu’un événement survient, un objet target est notifié par l’objet source de l’événement. Pour cela il va appeler un selecteur. Ce selecteur correspond à l’action. Les timers iOS implémentent ce mécanisme:
#import <foundation /Foundation.h>
#import "Logger.h"

int main(int argc, const char *argv[]) {
    @autoreleasepool {
        Logger *logger = [[Logger alloc] init];

        NSTimer *timer : [NSTimer scheduledTimerWithTimeInterval: 1.0
                                                          target: logger
                                                        selector: @selector:(onTick:)
                                                        userInfo: nil
                                                         repeats: YES];

        NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
        [runLoop addTimer:timer forMode:NSDefaultRunLoopMode];
        [runLoop run];
    }
    return 0;
}

Continuer…

Tour d’horizon des nouveautés du langage Objective-C


L’Objective-C a connu ces dernières années différentes évolutions qui ont permis de donner un coup de jeune à un langage qui va fêter d’ici peu ses trente bougies. Pour y voir plus clair dans ces évolutions, je vous propose de (re)découvrir un bref résumé chronologique des évolutions apportées par Apple au langage  :

  • 2006 / 2007 : Apple annonce la révision 2.0 du langage lors du WWDC. Cette révision apporte de nombreuses nouveautés telles que le support des propriétés (On attend toujours pour Java …), des énumérations rapides, des déclarations optionnelles de méthodes dans les protocoles, ou bien encore des extensions de classes.
  • 2010 : Apple introduit une nouveauté comparable à la notation lambda en Java appelée Blocks. Ces blocs de codes ne sont pas de simple fonctions anonymes mais des closures: elles conservent l’accès aux données du contexte dans lequel elles ont été créées.
  • 2011 : Avec l’arrivée d’iOS 5, Apple a introduit la gestion automatique du comptage des références, également appelée ARC pour Automatic Reference Counting, qui a pour but de permettre aux développeurs de globalement s’affranchir des problématiques de gestion de la mémoire. Cette dernière évolution est un tel chamboulement que de nombreux projets ne l’ont pas encore adopté et continuent de fonctionner avec un comptage manuel des références.
  • 2012 : Apple introduit une syntaxe simplifiée via le support des Object Literals à partir d’OSX 10.8 et d’Xcode 4.4. Cette notation est cependant disponible uniquement pour les développeurs iOS utilisant le SDK 6.0.

Ces diverses évolutions ont contribué à moderniser le langage et simplifier son utilisation. Apple proposait d’ailleurs lors du dernier WWDC, deux sessions : l’une ayant pour objectif de présenter ces nouveautés, et l’autre de se familiariser avec afin de les intégrer dans les projets.

A travers différents exemples, je vous propose de découvrir certaines de ces simplifications / améliorations. Si vous souhaitez tester ces fonctionnalités vous pouvez vous équipez de la version 4.4 ou supérieur d’Xcode qui intègre la version 3.1 du compilateur Clang gérant ces nouveautés.

Définition

Un littéral est une déclaration dans le code source d’un logiciel permettant de représenter une valeur. Le littéral le plus connu est la représentation d’une chaîne de caractères dans un code source. Une simple déclaration de chaîne de caractères en Java, par exemple, permet d’instancier un objet String sans passer explicitement par un constructeur : sa construction / instanciation / initialisation est implicite. Le recours aux littéraux dans un code source a pour objectif de simplifier, et de rendre plus lisible et compréhensible un code source.

En Objective-C, la syntaxe littérale pour instancier un objet NSString est la suivante :

NSString *nickname = @"John Doe";

Vous pouvez cependant déclarer le même objet NSString via une syntaxe n’utilisant pas de littéraux :

NSString *nickname = [NSString stringWithCString:"John Doe" encoding:NSUTF8StringEncoding];

L’intérêt d’une telle notation saute tout de suite aux yeux. La déclaration d’un littéral NSString est similaire à celle d’un littéral C string standard, sauf qu’elle est préfixée par le caractère ‘@’.

Continuer…

Gérez vos dépendances Objective-C avec CocoaPods

La popularité du langage Objective-C est en constante augmentation ces dernières années. Les succès de l’iPhone et de l’iPad en sont à coup sûr une raison évidente. L’Objective-C, cependant, est utilisé depuis bien plus longtemps dans le développement des logiciels Apple. Le langage en lui-même a été inventé en 1983 comme indiqué sur sa page Wikipedia. Apple prend d’ailleurs un soin particulier à faire évoluer son langage en y apportant de nouveaux raffinements chaque année (Spécification Objective-C 2.0, …).

Bien qu’Apple propose une tool chain à la pointe basée sur LLVM et Clang, il faut se rendre à l’évidence: la gestion des dépendances en Objective-C reste un domaine assez peu exploré, et laisse un petit goût amer lorsqu’on a goûté à d’autres langages accompagnés de leur gestionnaires de dépendances. Je pense ici à JavaScript avec Node.JS et NPM, Ruby et ses Gem, ou bien encore notre bon vieux Java et autres languages de la JVM qui fournissent eux aussi une multitude d’outils répondant à ce besoin.

Il semble que les langages des générations C / C++ et Objective-C aient plus de mal à fournir des outils de ce type. L’intégration de librairies et frameworks peut d’ailleurs rapidement donner des maux de têtes aux développeurs, ce qui n’est pas acceptable pour un langage / écosystème de développement qui se veut moderne.

Concernant l’Objective-C, la réponse à l’absence de gestionnaire de dépendance est venue de la communauté à travers la création d’un outil appelé: CocoaPods. Cet outil est basé sur le partage de configurations également nommées Spec. Elles ont pour rôle de décrire le contenu d’une dépendance. L’outil, développé en Ruby, est visiblement assez inspiré de l’éco-système qui existe autour de ce langage.

Installation & Utilisation

Pour installer CocoaPods, vous devez exécuter les commandes suivantes:

$ [sudo] gem install cocoapods
$ pod setup

Un des points très intéressant de cet outil est sa simplicité d’utilisation : il suffit en effet de créer un fichier « Podfile » à la racine de son projet XCode listant les dépendances requises et de lancer la commande:

pod install

pour que l’outil aille télécharger tous les fichiers sources nécessaires sur internet et vous configure un workspace XCode en bonne et due forme sans effort supplémentaire de votre part. Pour ouvrir le workspace XCode configuré avec toutes ses dépendances, il suffit d’exécuter ensuite la commande :

open my-project.xcworkspace

Les pré-requis à l’utilisation de CocoaPods se résument à installer Ruby 1.9 sur sa machine (si ce n’est déjà fait).

Note : Si vous avez exécuté l’installation avec une version de Ruby 1.8, je vous conseille de nettoyer votre dossier .gem dans votre dossier home, et de recommencer l’installation pour éviter tout problème de compatibilité.

Configuration

L’outil est utilisable aussi bien pour des projets iOS que pour des projet OS X. Pour cela, il suffit de spécifier la cible en début de fichier comme indiqué dans l’exemple ci-dessous :

platform :ios

pod 'JSONKit', '1.5pre'
pod 'LibComponentLogging-Core', '1.2.2'
pod 'LibComponentLogging-NSLog', '1.0.4'
pod 'Reachability', '3.0.0'
pod 'RestKit', '0.10.1'

Contrairement à ce que laisse penser l’exemple précédent, différents opérateurs de comparaison permettent d’affiner les versions des librairies utilisées. Il est possible de créer des configurations plus complexes si votre projet le requiert en allant visiter la documentation du projet. Vous pouvez, entre autre chose, créer plusieurs target correspondant, par exemple, à des targets de test ou de debug de vos applications.

Spécifications

Cerise sur le gâteau, le système de contribution d’une dépendance est très simple, puisque vous pouvez, vous-même, constituer une spécification de dépendances et la soumettre via un Pull Request sur le repository Github CocoaPods/Specs. Ce repository contient l’ensemble des spécifications de dépendances utilisables avec CocoaPods. La lecture de différents fichiers Spec, en plus de la lecture du wiki du projet, permet de comprendre très rapidement le format.

Exemple de spécification pour la librairie Cordova 2.1.0 (PhoneGap) :

Pod::Spec.new do |s|
s.name = "Cordova"
s.version = "2.1.0"
s.summary = "Apache Cordova is a platform for building native mobile applications using HTML, CSS and JavaScript."
s.homepage = "http://incubator.apache.org/cordova/"
s.author = "Original developed by Nitobi (acquire by Adobe) and all other PhoneGap and Cordova Contributors"

s.license = 'Apache License, Version 2.0'

s.source = { :git =&gt; "http://git-wip-us.apache.org/repos/asf/incubator-cordova-ios.git", :tag =&gt; "2.1.0" }
# s.source = { :git =&gt; "https://github.com/apache/incubator-cordova-ios.git", :tag =&gt; "2.1.0" }
s.source_files = 'CordovaLib/Classes/*.{h,m}'
s.resources = 'CordovaLib/javascript/*.js', 'CordovaLib/VERSION'

s.platform = :ios, '4.3'
s.requires_arc = true

# TODO: Missing AddressBookUI here, but CocoaPods generates incorrect OTHER_LDFLAGS in Pods/Pods.xcconfig. Will analyse this soon..
# OTHER_LDFLAGS = -ObjC UI -framework AVFoundation &lt; - incorrect UI argument here!

s.frameworks = 'AddressBook', 'AudioToolbox', 'AVFoundation', 'CoreLocation', 'MediaPlayer', 'QuartzCore', 'SystemConfiguration', 'MobileCoreServices', 'CoreMedia', 'UIKit'

# Note: This is not the same like the original JSONKit. Cordova developers decide to integrate
# *a changed copy* (with prefixed class and method names) of it instead of using CocoaPods. :S
# But they missed to translate it like the main project to use ARC, yet.
s.subspec 'JSON' do |json|
json.source_files = 'CordovaLib/Classes/JSON/*.{h,m}'
json.platform = :ios, '4.3'
json.requires_arc = false
# TODO requires_arc does not work for subproject, so set compiler flag by hand until CocoaPods 0.15(?) will support this.
json.compiler_flags = '-fno-objc-arc'
end

end

Moteur de recherche

Bien entendu, il ne serait pas possible de tirer toute la quintessence d’un tel outil sans un moteur de recherche de dépendances associé, c’est ce que propose le site CocoaPods.org.

Les fans de la ligne de commande pourront bien entendu lister les dépendances disponibles via la commande :

pod list

ou bien encore trouver la liste des autres commandes disponibles via l’aide :

pod help

Conclusion

Doucement mais sûrement, un éco-système composé d’outils modernes d’aide au développement s’est formé autour d’Objective-C, et CocoaPods en est un rouages important. Parmi ces nouveaux outils, nous pouvons en citer quelques uns: :

  • ios-boilerplate.com est un kickstarter pour démarrer une application iOS.  Ce template permet de gagner un temps précieux au bootstrap du projet, et fait inévitablement penser au désormais célèbre html5-boilerplate.
  • cocoacontrol.com est un site web référençant nombre de composants utilisables dans vos projet iOS.
  • iosframeworks.com est un catalogue référençant classes et frameworks utiles pour vos projets.

Dans la famille des XaaS, je voudrais le BaaS

En ce début de week-end, je suis tombé sur un terme que je n’avais pas encore vu, mais qui m’a tout de suite fait tilt et qui prend tout son sens dans le business de la mobilité.

BaaS est l’acronyme pour Backend as a Service.

Quand on code une application mobile on aime pas trop se prendre la tête sur d’autres sujets que le développement de l’application en elle-même qui demande déjà beaucoup de temps à concevoir et qui devient assez rapidement complexe (Problématiques multi-plateforme, multi-version d’os, …).

C’est pour ça que de nombreuses startup et sociétés spécialisées dans la mobilité délèguent le développement de la partie serveur à un ensemble de services webs tel que: Parse ou bien Deployd …

Ces services de nouvelles génération viennent compléter l’écosystème habituel de services sociaux (Twitter, Facebook, …) avec par exemple: Flurry pour les stats ou bien encore Urban Airship pour les notifications push.

La particularité des services comme Parse et Deployd réside dans le fait qu’elles proposent sur le fait de construire non pas un backend, mais directement les données utiles aux applications mobiles. Ainsi on ne pert plus de temps à construire le backend serveur, on ne construit que les structures de données, et on s’intègre avec le framework du services web qui fournit également les librairies côté client.

Ces startups proposent des Backend as a Service qui permettent donc de créer les services web dans le cloud dont on a besoin sans perdre de temps avec la technique. Ils intègrent en général des mécanismes d’authentification, ce qui permet de ne pas uniquement pouvoir stocker les habituels highscores d’un jeu, mais également de pouvoir stocker des données relatives à un utilisateur dans le contexte d’une application mobile.

Différents services de ce nouveau type:

Une vidéo de démonstration du service deployd :

Enfin, voici une map très intéressante tirée de l’article suivant: http://www.kinvey.com/index.php?option=com_k2&view=item&id=217&Itemid=322

Faille Android du jour … Et hop, ton téléphone est wipé !

Mise à jour: Le sujet est tout chaud, il vient juste de tomber. Prenons les hypothèses avec des pincettes, et ne tirons pas de conclusions hâtives. Ce billet émane de premiers éléments qui seront peut-être/sûrement démentis/contredits dans les prochains jours.

La faille du jour ultra critique, au cas où vous seriez pour le moment passé à côté, concerne votre téléphone Android. Elle est plutôt du genre sévère et touche un grand nombre de combinés Android sans épargner les modèles phares et marques leader du marché.

Pour ma part, j’ai un Samsung Galaxy S et, ô surprise, il est vulnérable. Pourtant il fonctionne sur ICS, c’est à dire, la dernière version majeure du système Android.
La vulnérabilité concerne l’exécution automatique des codes spéciaux via le dialer de votre téléphone. Vous en avez peut-être déjà entendu parlé. Par exemple, si vous saisissez le code: *#06# sur votre téléphone, une popup avec son numéro IMEI apparaîtra.
En apparence, rien de très grave. Sachez cependant qu’il est possible de saisir d’autres codes provoquant d’autres actions sur votre téléphone dont un qui permet de wiper (Supprimer) toutes les données de votre cher téléphone Android.
Sachez également, qu’il est juste nécessaire d’ouvrir une page web contenant un lien téléphonique pour exécuter ce type de code. Le problème de sécurité réside dans le fait système Android permet l’exécution automatique de ces codes sans demander de confirmation, il est ainsi possible de créer des QRCode piégés ou bien encore de créer des liens piégés via de simples pages web.

Si vous avez des doutes quant à la criticité de cette faille, rendez-vous sur cette page avec votre téléphone: http://dylanreeve.com/phone.php et voyez comment il réagit. Si le numéro EMEI de votre téléphone apparaît dans une popup sans action de votre part, alors votre téléphone est vulnérable.
Mon Samsung Galaxy S ouvre fièrement une popup affichant son numéro IMEI. Ceci sous-entend qu’il est également capable d’exécuter le wipe du téléphone ou d’autres choses peut-être encore moins sympas dont personne n’a idée pour le moment.
En prenant le temps de la réflexion un instant, on se croirait revenu au temps de Windows 98, et de ses failles béantes découvertes tous les quatre matin ! On peut se demander comment de telles failles de sécurité peuvent encore passer entre les mains des équipes de sécurité chez Google sans être repérées, c’est tout bonnement incroyable!

Sachant que les mises à jours Android sont mises à dispositions, en général, uniquement pour les combinés les plus récents, nous sommes devant une faille avec potentiel destructeur énorme, et qui pourrait n’être jamais corrigée pour une vaste majorité de combinés. Je ne parle même pas du fait que l’utilisateur moyen n’a que peu de chance de savoir qu’il faille mettre à jour son téléphone lorsqu’il en a la possibilité.

Différentes solutions ou workaround existent. Si vous n’avez pas la chance d’avoir un téléphone protégé ou bien même d’avoir une mise à jour de sécurité applicable pour votre modèle de téléphone, vous pouvez dans un premier temps installer un second Dialer via le Google Play afin de vous prémunir de l’exécution automatique de ces code spéciaux. Vous vous verrez proposer à la place une popup de confirmation vous demandant de choisir l’application à utiliser. Vous aurez donc le choix d’annuler l’action.

Si votre système est assez moderne et dispose de Google Chromen vous pouvez attendre une nouvelle version de l’application fixant la faille de sécurité. Sachez cependant que bon nombre d’applications dont les readers fonctionnent avec un composant WebView basé sur le navigateur système. Ce composant n’est pour le moment pas une webview Google Chrome même pour les téléphones les plus récents (Hormis exception pour l’instant me semble-t-il). C’est donc la webview système qui prenda en chargement la page web. Une mise à jour de Chrome ne permettra donc pas de se prémunir des applications embarquant une webview et donc potentiellement affectées par le problème.Quant aux applications proposant la lecture de QRCode, il faudra attendre les mises à jour.

Il est fort à parier que la solution la plus pérenne viendra de la mise à disposition via le Play Store d’applications de filtrage de demande d’exécution de ces codes spéciaux. La question étant de savoir s’il est nécessaire d’avoir un téléphone rooté pour installer une application de ce type.

Nos téléphones auraient-ils besoin finalement d’antivirus sachant que la plupart des failles de sécurités ne sont jamais corrigées du fait de l’obsolescence effrénée de nos combinés et donc de l’absence récurrente de mise à disposition de mises à jours de sécurité pour les modèles les plus anciens.
De même, combien de temps les constructeurs fermeront les yeux sur l’absence de mise à jour de sécurité régulières de nos combinés mobiles ?

Fait étonnant, les derniers Google Phone ne semblent pas touchés. Google aurait-il corrigé en toute discrétion cette faille et aurait-il fait passer une mise à jour silencieuse ? Il semble que cela soit effectivement le cas. Google, ses partenaires et différents opérateurs auraient été prévenus dès la fin du mois de juin, mais seul Google pour ses modèles récents et quelques opérateurs pour quelques modèles très précis auraient effectivement appliqué un patch de sécurité. Les autres combinés étant sujets aux aléas de la qualité des protections implémentés dans les surcouches constructeurs et opérateurs. En tout état de cause, les téléphone équipés de ROM stock ou custom (Rom Cyanogen et compagnie) semblent touchés par le problème.

En tout état de cause, il ne faut pas trop s’attendre à recevoir Over The Air une mise à jour pour un combiné Android qui a plus de 6 mois ou 1 an. Combien cela coûterait aux opérateurs de mettre à disposition des mises à jours de sécurité pour des centaines de modèles qui sont pour la plupart arrivés en fin de vie commerciale ? Nos chers opérateurs doivent-ils d’ailleurs prévoir de tels plans catastrophe ? Qui s’engage à sécuriser votre combiné ? J’aurais malheureusement tendance à dire personne à part vous-même: Soyez vigilant face aux alertes de sécurités concernant les systèmes mobiles:

  • Tenez votre système ainsi que vous applications à jour
  • Utilisez un navigateur updatable
  • Evitez l’usage du navigateur système
  • Utilisez à la place un navigateur updatable, tel que Google Chrome.

Les informations critiques relatives à votre vie privée et professionnelles sont toutes accessibles depuis votre combiné mobile ou même tout simplement stockées dans votre téléphone, il est donc impératif d’être vigilant quant à la sécurisation des données nomades. Preuve, s’il en faut, la mésaventure arrivée au mois d’août dernier à Mat Honan, journaliste du magazine Wired qui a vu sa vi digitale effacée en un claquement de doigt (ici et ).

Cette faille de sécurité met en lumière toute la problématique de la fragmentation du système Android, et c’est Apple qui doit se frotter les mains cette semaine après avoir subit les railleries la semaine dernière lors du lancement de sa nouvelle application Map.