IPhone

IPhone

Sortie de l’application mobile Xebia pour iPhone et iPad

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!

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.

(suite…)

Intégration de RestKit avec une UITableView

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

(suite…)

Introduction à RestKit

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.

(suite…)

Utilisation des Blocks en Objective-C

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;
}

(suite…)

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

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 ‘@’.

(suite…)

Android, retour d’impressions

Android, retour d’impressions

Après quelques semaines d’utilisation, je commence à me faire une idée des capacités de la plateforme et de ses qualités ert défauts! Et il y a de quoi parler, à commencer par l’émulateur. Ce dernier m’a semblé de prime abord de très bonne facture, mais il s’impose vite la conclusion suivante: l’émulateur propose des performances catastrophiques! Le PC sur lequel je développe est un portable Athlon XP 3000+, ok il n’est pas tout neuf, mais cela reste honorable, étant donnée que l’ordinateur dispose de 1,5Go de RAM et d’un disque 5400 tpm, les performances restent donc correctes. Cependant, dès que l’émulateur est lancé, le pourcentage d’utilisation CPU monte à 95 % très facilement et le pc ne répond pas vraiment bien (C’est le moins qu’on puisse dire) . Ce qui me trouble le plus reste les performances des programmes exécutés sur l’émulateur. Je ne suis pas arrivé à des performances correctes sans faire des concessions importantes sur le design applicatif et encore avec difficulté.

Je comprend l’angoument autour de la plateforme, mais également pourquoi on voit si peu de programmes disponibles (Je ne pense pas que ce soit lié au concour Android de Google uniquement). La source du problème n’est pas tant dans la plateforme que dans les performances de l’émulateur qui ont de quoi dégouter du développement sur Android et pousser à explorer les progrès fait sur J2ME et les JVM MIDP de Sony et Nokia qui semblent d’ailleurs très intéressant.

Même si les constructeurs proposent des machines performantes, il va falloir que Google fasse un effort sur son émulateur pour proposer des performances acceptables sur son émulateur. Dans le cas contraire, il se pourrait que certains développeurs soient rebutés. Pour l’instant j’en fait parti.

Autre bémol et de taille: c’est l’obscurantisme des API de la plateforme et le peu d’explications qu’on peut trouver. On est bien trop amené à essayer de deviner comment utiliser les API.  Les API étant complètement nouvelles, elles obligent le développeur à un apprentissage nouveau. De plus les API sont complexes et accrobatiques à utiliser. Souvent élégantes dans le concept, il faut tout de même avoir de bonnes notions de développement pour les exploiter correctement.

j’appuye cette petit analyse sur un retour d’expérience réel , j’ai essayé d’exploiter des API REST simples et cela me pose trop de difficultés pour en rendre le développement sympathique: j’ai plus tendance à m’arracher les cheveux entre la complexité des API et les performances de l’émulateur.

Gageons que la plateforme est encore jeune, et des best practices Android simples et efficaces  apparaitrons, mais pour le moment ce n’est pas la panacé. Et un travail urgent est à faire sur les performances de l’émulateur. Pour am part, le constat est simple: j’arrêtele développement Android ou bien j’achète un nouveau PC…

Un dernier mot: Je suis en 1280 et l’émulateur prend une grande partie de mon écran! C’est quand même assez embêtant. Google est capable de penser des API complexe, mais pas à un détail aussi simple.

A noter: les JVM de Sony et de Nokia embarquent aujourd’hui tout un ensemble d’extensions intéressantes, sur lesquelles je reviendrais un autre fois, mais qui permettent de développer facilement aujourd’hui des applications intéressantes sans vraiment de difficultés particulières. Les problématiques d’antant n’existent plus vraiment sur MIDP aujourd’hui.

Depuis quelques jours, j’ai un W910 de Sony, et il faut dire que je suis impressionné par les progrès effectués et la diversité des API MIDP proposées (Sensor API, Content handler API, MMAPI, Bluetooth API, …). De plus, les JVM sony, par exemple, en sont à leur 8ème génération, ce qui en fait un choix de plateforme proposant de nombreux avantages (performances, stabilité, support d’API étendues, …) et un choix pour le moment bien plus sûr qu’Android.

Ma conclusion, est donc la suivante: comme de nombreuses personnes, je suis rentré dans le jeu des Buzz (IPhone /Android), mais rien ne vaut les valeurs sûres telles que MIDP ou le DotNet CF ou bien la plateforme de dev Symbian ou Palm. Attendons donc quelques mois que la plateforme Android murisse et que les premiers modèles sortent avant de trop en dire sur Android. N’oublions pas, entre autre, pour le moment qu’Android repose sur une plateforme Linux qui n’est compatible ni Symbian, ni Windows Mobile, ni Palm. Le marché est de ce fait extrêmement restreint. De la même manière que l’Iphone, le marché Android risque de rester une niche un certain temps. L’arrivée de l’IPhone et d’Android ne font que segmenter le marché et rendre la tâche plus difficile pour les sociétés travaillant dans le domaine de la mobilité. Il existe au bas mot 6 plateformes importantes: Midp, Windows Mobile, Symbian, Palm, l’IPhone et Android!

N’hésitez pas à faire part de vos impressions!

Eh hop, une bonne claque à MAC et l’IPhone !

Eh hop, une bonne claque à MAC et l’IPhone !

Je pense que cette vidéo va satisfaire les plus curieux ainsi que les plus septiques d’entre vous au sujet de la plateforme de Google, il n’y a pas vraiment besoin de rajouter de commentaires, mais pour résumer on y voit en vrac:

  • 2 modèles de téléphones compatibles Androi, on dira que ça correspond à 2 profils de téléphons différents: un haut de gamme et un entrée de gamme.
  • du Google Map + l’application Google de visionnage en 3D photo des alentours
  • du jeu avec Quake en OpenGL
  • du browsing avec WebKit
  • quelques fonctionnalités système

On y voit également l’équipe d’Android qui présente les deux téléphones (le deuxième est impressionnant! C’est un prototype en plus …), ainsi la vision de Google en terme de mobilité, qui est de créer un système ouvert, tel que Linux l’a été pour le PC.

Pour ma part, je trouve que Google fait très fort, il propose tout ce que j’ai toujours attendu d’une plateforme de développement pour la mobilité. Et pourtant, j’en ai vu d’autres, j’ai donc de quoi comparer : PalmOS, SuperWaba, Compact Framework sur PocketPC, J2ME. Et pas une seule ne semble rivaliser avec ce que Google pourra offrir avec une plateforme comme Android.

Aujourd’hui les plateformes qui permettent de concurrencer Android sont des systèmes directement comme Windows Mobile 6, l’IPhone et Symbian + UIQ avec leur outils de développements, mais leur apprentissage ou leur prise en main n’est pas aisée, ni à la portée de tous.

Je me demande cependant ce qu’il en est de la capacité du système à prendre en charge les appels WebService, ainsi que la capacité du sytème à prendre en charge les API Web qui font aujourd’hui le Web 2.0 .

Android est là, et l’Iphone dans la place…

Android est là, et l’Iphone dans la place…

hello_world_8.pngC’est y est le SDK Google de la plateforme Android est disponible, vous pourrez le trouver à l’adresse suivante:

Pour ce que j’en ai lu pour le moment, je trouve le concept très intéressant, et Google fournit avec Android en quelques sortes un remplaçant au vieillissant J2ME avec son profil MIDP 2.


Plusieurs points positifs sont à noter:

  • Un environnement intégré à Eclipse!
  • Un emulateur de la plateforme.
  • Une API qui semble complète pour le faciliter le debug sur la plateforme.
  • Une base Java bien sûr :D

Il fallait s’en douter, les premiers sceptiques se plaignent déjà: entre autre de ne pas avoir d’accès natif à la plateforme (du moins pour le moment), qu’Android est trop ressemblant à J2ME, pas assez proche du matétiel, bla bla bla… Pour ma part, la programmation moderne ne nécessite pasde manipuler à outrance des ressources natives (peut-être une déformation de vision liée à l’uitlisation de Java). Il est plus intéressant être en mesure d’exploiter des ressources natives à travers des API exposées, et c’est sur ce point que j’attend Google: exposer la richesse du système sur lequel repose le téléphone à travers des API adaptées via leur SDK. S’ils répondent avec succès à ces besoins, il n’y a pas de raison que la plateforme ne soit pas un succès commercial.

Il semble que HTC ait déjà annoncé 3 téléphone compatible Android pour l’année 2008. Si HTC est de la partie, c’est déjà très bon signe! Pour ma part un GooglePhone de ce type me semble bien plus attirant qu’un IPhone tel qu’il existe aujourd’hui.

L’IPhone est un triste exemple de ce que risquerait de devenir la téléphonie:

  • Une téléphone exclusivement explotable sur un opérateur
  • Un téléphone limité logiciellement (pas de MMS, pas de Vidéo, des fonctionnalités générales très limitées, pas de support pour le moment de développement de logiciel)
  • Un téléphone dont les limitations matérielles sont inversement proportionnelle à l’ingéniosité de son interface graphique (GPS, 3G, Vidéo, APN 2MP, et j’en passe)
  • Un téléphone dont les fonctionnalités dépendent d’accords commerciaux : La vidéo avec YouTube, GoogleMap
  • Des forfaits hors de prix à cause de la gloutonnerie financière de MAC
  • Une faille de sécurité plus que douteuse, mais bien pratique pour créer un buzz de l’IPhone.

Un détail me chagrine quand même concernant l’IPhone … Pourquoi ne sortirait-il pas un nouveau firmware, au hasard vers février, qui permettrait à l’IPhone d’être le premier téléphone ‘Android’, en effet, on sait que MAC annonce une plateforme de développement pour l’IPhone en février 2008, l’IPhone repose bien sur un noyau BSD au MAC dérivé de BSD. Pourquoi pas après tout! Android correspond bien à ce que MAC souhaite proposer une plateforme de développement qui isole les ressources du téléphone du développeur par une couche intermédiaire.

L’IPhone… Un succès annoncé!

L’IPhone… Un succès annoncé!

Bien qu’on en entende parler un peu partout, et qu’on puisse trouver des infos ou bien des vidéos à tire larigot à propos « de vous savez quoi », je pense que visionner cette vidéo ne pourra pas faire de mal tant elle ramène les autres téléphones portables dans la préhistoire!

iphone_hero_20070621.jpg

http://www.apple.com/iphone/usingiphone/guidedtour.html

Je vous le dis le oup est entré dans la bergerie!

2 liens indispensables si vous voulez en savoir plus:

Sachez dans la foulée qu’un IPhone 3G pour l’Europe serait prévu. De plus, un IPhone 2G serait prévu pour début 2008, il proposerait entre autre du Wifi N, une puce GPS, et un meilleur objectif! Pas mal l’air de rien!