Interview : les défis du développement sur iPhone

Christophe Laporte |
En l'espace de quelques mois, Apple a créé un véritable écosystème autour de sa plate-forme mobile. L'App Store recense officiellement plus de 140 000 applications et est utilisé par 75 millions de personnes. Un succès difficilement plausible lorsqu'Apple a présenté son kit de développement il y a près de deux ans. Se rendant compte du potentiel des terminaux mobiles d'Apple, des milliers et de milliers de développeurs (plus de 32.000 éditeurs rien que sur l'App Store américain) se sont équipés de Mac, ont installé Xcode, se sont mis à l'Objective-C et ont commencé à développer des applications pour l'iPhone.

Le succès est tel que la conférence des développeurs (WWDC) affiche complet maintenant chaque année. Le succès de l'App Store a créé des besoins : ces derniers mois, on a vu quantité de livres relatifs à la programmation sur iPhone sortir en librairies. D'autre part, de plus en plus d'organismes proposent des formations au développement sur l'iPhone. C'est le cas notamment de Pythagore F.D. Les cours sont animés par Benoît Widemann, un vieux "routier" du monde Mac, à qui l'on doit de nombreux programmes. Les plus anciens se souviennent de JoliTerm et JoliPhone.

Quel est le profil des développeurs iPhone ? Quelles sont les difficultés que rencontrent les personnes qui se mettent à l'Objective-C ? Quelles sont les erreurs à ne pas faire lorsque l'on développe une application l'iPhone ? L'iPad sera-t-il un succès ? Autant de questions auxquelles Benoît Widemann a bien voulu répondre.


Quels sont les profils des personnes qui assistent aux formations iPhone ? Des développeurs web, des développeurs Mac, des développeurs Windows, des profils plus atypiques ?

La majorité des élèves vient du monde .net ou du php, parfois Java. Il y a peu de développeurs Mac, les tutoriels sont amplement suffisants lorsqu'on maîtrise déjà Cocoa sur Mac. J'ai eu aussi des transfuges de FileMaker ou 4D, un qui n'avait pratiqué que du C pur, novice en programmation objet. Curieusement, les handicaps ne sont pas toujours là où l'on s'y attend.


On a l'impression qu'Apple a réussi avec l'iPhone ce qu'elle n'a jamais réussi totalement avec le Mac : à savoir amener un nombre très important de développeurs à se pencher sur sa plate-forme mobile. Qu'en pensez-vous ?

C'est indiscutable. Le succès de l'iPhone, comme celui qui s'annonce pour l'iPad, y sont évidemment pour beaucoup. On voit les étudiants arriver en masse, mais aussi des développeurs expérimentés se tourner vers la plate-forme. On voit des SSII s'y intéresser et pousser leurs collaborateurs à s'y former. On voit des PME souhaitant porter un produit vers l'iPhone chercher en vain un prestataire qualifié disponible, et décider finalement d'envoyer ses propres développeurs en formation. On voit des "web-agencies" poussées vers l'iPhone par les demandes de leurs clients, alors qu'ils n'ont pas d'autres compétences en interne que PHP et Flash pour développer...

On insiste beaucoup sur le côté grand public de l'iPhone à cause de sa simplicité d'emploi, des nombreux jeux disponibles sur l'App Store. Mais voyez-vous parmi les gens que vous formez des personnes qui ont pour vocation par la suite de mettre au point des outils pour les professionnels, des solutions verticales … ?

Oui, c'est même la majorité. L'explosion actuelle est nettement ciblée sur le développement de solutions verticales, plus encore que vers le grand public. Il ne faut pas oublier qu'il y a déjà 130.000 programmes disponibles, donc la concurrence est rude sur les applications horizontales. A contrario un développeur compétent trouvera du boulot facilement dans des domaines inattendus, la demande étant extrêmement diverse.

Le SDK de l'iPhone est souvent mis à jour. En tant que formateur, est-ce que cela vous pose des problèmes ?

Les mises à jour majeures suivent les évolutions du hardware. Le 3GS a ajouté la boussole, la version 3.0 des améliorations sur Cocoa Touch, des objets enrichis, etc. Je suis en train de préparer un chapitre sur l'iPad que j'ajouterai au cours dès que la confidentialité sera levée. Techniquement il y a peu de différences, en revanche la conception de l'interface utilisateur est sensiblement revue. On profite de l'espace disponible sur l'écran pour sauter des étapes hiérarchiques dans la navigation, comme le fait l'application Mail.



Au niveau de la formation, quel est/sont les points les plus délicats sur lesquels les élèves connaissent le plus de difficulté ?

Tout dépend de leurs compétences au départ. Ceux qui n'ont aucune pratique de la programmation objet tendent à buter sur l'architecture des applications. Ils comprennent les exercices grâce aux explications, mais sortent du cours avec une conscience aiguë de l'expérience qui leur reste à accumuler sur les mois suivants. Ils maîtrisent les bases de l'API Cocoa Touch et sont à même de travailler dans une équipe, à condition d'être "coachés" par un chef de projet pour l'architecture des objets.

Pour ceux qui arrivent au contraire avec un bagage plus élevé, la difficulté est plutôt de parvenir à désapprendre les habitudes inappropriées. En général ça se passe bien... mais certains partent sur le SDK comme des fusées alors qu'ils n'ont même jamais utilisé un iPhone, et n'en ont d'ailleurs pas l'intention. Ceux-là le considèrent comme un gadget indigne de leur talent, ils ne sont vraiment là que parce que leur employeur les y oblige. Il est très, très difficile de réussir la formation dans un tel cas, mais on voit parfois un éclair d'illumination se produire à mi-parcours !

La gestion de la mémoire reste un point noir. Ceux qui viennent de Java ou de PHP sont horrifiés d'avoir même à seulement s'en préoccuper. Les oublis de désallocation constituent les erreurs les plus fréquentes dans les exercices. Les chaînes de caractères aussi perturbent beaucoup certains élèves qui se demandent pourquoi un langage si moderne est en même temps à ce point en retard sur des opérations pourtant basiques.

Est-ce que la conception d'une interface adaptée à ces appareils, la philosophie générale d'iPhone OS, l'intégration de la gestuelle multi-touch, etc ne sont pas finalement des choses aussi importantes que l'apprentissage de la programmation ?

Absolument. Il est impossible de développer une application iPhone acceptable sans être soi-même un utilisateur habitué à l'iPhone, imprégné des guidelines sur l'interface. Il faut passer du temps à jouer avec, télécharger des tombereaux d'applications, se servir réellement du plus grand nombre possible en les poussant dans leurs retranchements. On découvre ainsi les pièges dans lesquels ne pas tomber. On perçoit le haut niveau de qualité auquel la barre s'est stabilisée, même si l'on trouve tout et n'importe quoi sur l'App Store.

Et est-ce qu'il n'y a pas là-aussi un très gros travail pédagogique à faire auprès de ces développeurs ?

Il faut souvent les freiner sur le code et les pousser vers l'analyse des comportements d'utilisateurs. Par exemple, le temps d'activité d'une application iPhone est incroyablement bref : on lance, on regarde un truc et on quitte, parfois en quelques secondes à peine. C'est de ce genre de choses dont il faut s'imprégner quand on développe, car on a facilement tendance à l'oublier quand on est concentré sur la liste des fonctionnalités de son application et tous les merveilleux avantages qu'elle va offrir à l'utilisateur, qui s'en fiche totalement. Le choix de quelques fonctionnalités simples et directes, bien ciblées, n'est pas facile. Il faut apprendre à couper tout ce qui dépasse et se concentrer sur l'usage réel de l'application par ses futurs utilisateurs.

Et est-ce que d'ailleurs le premier conseil n'est pas de leur dire de s'attacher les service de gens (graphistes, designer) spécialisés dans ces domaines ?

C'est encore une compétence rare. La simple préoccupation du design d'interface et de l'ergonomie reste l'exception parmi les développeurs. De leur côté, les graphistes sont rarement intéressés par l'ergonomie, la plupart se contente de râler parce que Flash ne marche pas sur l'iPhone et n'imaginent pas une seconde que l'accessibilité puisse les concerner. Il m'est arrivé d'intervenir dans des écoles de design sur le sujet et clairement, il y a du chemin à faire...




A écouter les développeurs iPhone, on a l'impression que la gestion de la mémoire reste un gros point faible actuellement, par rapport à ce qu'il se fait ailleurs. Qu'en est-il exactement ?

Les avis sont partagés. Personnellement j'aime bien le système du retain/release, c'est simple, efficace et ça se trace bien en debug. La gestion automatique avec le garbage collector est applaudie par certains, moi je suis un peu dubitatif et je suis ravi qu'elle soit restée optionnelle.

Objective-C est une surcouche du langage C avec un runtime dynamique. Si on essaie de le transformer en langage de plus haut niveau qu'il n'est réellement, on s'éloigne de ses fondamentaux et de sa philosophie. J'ai l'impression, en fait, que le garbage collector est surtout une concession ajoutée pour attirer vers Cocoa les développeurs Java. En pratique, je préfère m'en passer et ça ne me manque pas du tout.



Lorsque l'on développe sur l'iPhone, l'effet halo est obligatoire du fait qu'il faut impérativement un Mac, enfin si on veut utiliser les outils d'Apple. Est-ce que cela va créer des vocations sur Mac ?

C'est possible. Toutefois, l'API du Mac est beaucoup plus vaste et complexe que celle de l'iPhone. Le Mac est un vieux système, qu'il faut digérer avec tout son historique pour le maîtriser. Certaines fonctionnalités sont inaccessibles en Cocoa. On trouve encore des reliquats de Mac OS 9 dans les API, on a parfois l'impression de fouiller dans un fond de tiroir pour retrouver une vieille ficelle. À l'inverse, l'iPhone a été débarrassé de toutes ces lourdeurs, il est donc bien plus facile à aborder. Le fait que son API soit moins complète la rend aussi plus digeste. Et à certains égards, elle est plus avancée que celle du Mac.

Par ailleurs, les modèles économiques construits autour de l'iPhone sont clairs et simples. L'iPad arrive avec une nouvelle virginité, des services à inventer, des applications à écrire, des marchés à prendre. La situation du Mac est plus hasardeuse, certainement beaucoup plus encombrée et concurrentielle. Mais on en fait toujours avec plaisir !

On voit de plus en plus de solutions pour concevoir des applications iPhone en Flash, en Java ou en C#. Croyez-vous au potentiel de ces solutions ? Est-ce que cela peut être une menace pour Xcode ?

Sans doute pas une menace : Xcode continue d'évoluer pour répondre aux besoins des développeurs. Il y a cependant quelques produits intéressants. On peut citer par exemple Corona, qui s'appuie sur OpenGL en ressemblant furieusement à ActionScript (voir notre article Apple aurait voulu Flash sur iPhone). Ou encore Cappuccino et le langage Objective-J, lequel est une extension objet de Javascript conçue comme Objective-C, Cappuccino reprenant point par point les fonctionnalités de Cocoa (voir notre article Cappuccino marie Cocoa avec le web). Il y a même un générateur d'interface, Atlas, qui ressemble à Interface Builder (voir Atlas : pour créer des applications web Cappuccino).

Dans ces deux exemples, on a affaire à des produits qui couvrent des besoins distincts de ceux déjà couverts par Xcode. Corona intéressera ceux qui disposent d'une base de code en Flash et souhaitent la porter à moindre frais vers OpenGL. Cappuccino sert à développer des applications web en réutilisant son savoir-faire de développeur Cocoa, mais ne remplace pas celui-ci pour l'iPhone car le différentiel de performances à l'exécution est considérable et le restera encore un bon moment.

À long terme, c'est beaucoup moins certain. Si le "cloud computing" démarre vraiment, ce qui me semble très probable avec l'arrivée de l'iPad, on va voir apparaître des applications web offrant des services en ligne à valeur ajoutée, exploitant les niches les plus improbables, et dont le seul nombre justifiera l'évolution des outils de développement. Rapidement, les performances des machines et du réseau seront suffisantes pour que le gros des développements se contente d'applications web, à la manière des sites de jeux en Flash d'aujourd'hui, mais s'appuyant sur les standards du web (HTML 5, Javascript). Le recours aux langages de plus bas niveau pour développer finira par devenir l'affaire d'un petit nombre de spécialistes, un peu comme l'assembleur aujourd'hui.

On n'a jamais disposé d'une telle panoplie. Les outils sont monstrueusement puissants. Les idées et les concepts circulent bien grâce à l'internet. La qualité du code s'améliore : open source, bonnes pratiques, standards, contrôle de flux, analyse automatique du code source, tests unitaires, outils de debug et d'optimisation... Les développeurs sont vraiment gâtés ! À se demander comment il est possible que certaines applis persistent à ramer autant...

Par rapport à ses API, son environnement de développement… avez-vous une idée vers quelles directions Apple va aller ? Avez-vous des "désirs" à ce niveau ?

Ça rejoint la question précédente : la grande révolution récente sur Mac est le bridge Cocoa, qui permet d'exploiter l'API depuis d'autres langages comme Python, Ruby, AppleScript ou Javascript. On est ici dans un contexte de scripting orienté objet extrêmement moderne, où les langages partagent bien des concepts.

On sent une évolution rapide et une convergence générale. Apple, via le WebKit d'une part, via ses réticences connues sur Flash, pousse très fort le HTML 5 et la modernisation des CSS. Tout ça aura certainement un impact sur l'apparence des applications, tant sur le Mac que sur l'iPhone, sinon sous Windows puisque le WebKit y est présent avec Safari et Chrome. Firefox vire Flash à son tour... les lignes bougent et les standards du web jouent leur rôle à plein.

Les application web fonctionnent déjà sur l'iPhone. On peut mettre en ligne une application sous forme de page web et installer son icône sans passer par l'App Store (et sans jailbreak...). Lorsqu'on mesure ce que ces applications web peuvent faire avec HTML 5, CSS 3 s'appuyant sur Core Animation, et le bridge Javascript-Cocoa pour le code, on imagine facilement qu'à moyen terme, Objective-C sera réservé aux "gros" développements et que la plupart des applis prendront des chemins plus proches du scripting. Ça sera encore plus sensible avec l'iPad, où le WebKit va se déployer sur un écran plus grand.



A titre personnel, que pensez-vous de l'iPad ? La mayonnaise va-t-elle prendre ?

Bien sûr qu'elle va prendre. Ça va être un massacre.

L'iPad va toucher un nombre incroyable de professions et d'activités. C'est du pain béni pour les développeurs, une ouverture pour des nouvelles applications dans tous les domaines, de la niche professionnelle la plus verticale au jeu de plateau le plus grand public. Sa compatibilité avec les applications iPhone va évidemment aider son lancement, mais c'est réellement avec ses propres applications que l'iPad va décoller, celles qui l'exploiteront pour ce qu'il est et non comme un gros iPhone. Vous croyez qu'il y a une application pour tout sur l'iPhone ? Attendez de voir ce qui va se passer avec l'iPad... Les développeurs ne vont pas chômer, c'est sûr.

Un détail intéressant est l'ouverture de la téléphonie IP en 3G, verrouillée jusqu'ici pour ne pas mettre en péril les opérateurs... et discrètement déverrouillée en même temps que l'annonce de l'iPad dépourvu de téléphonie classique ! Les opérateurs devront suivre la demande et proposer des forfaits "data-only" illimités à des prix raisonnables, que l'on espère proches des 15-30$ annoncés aux USA. Le GSM ira doucement rejoindre le Bibop dans les oubliettes, en quelques années à peine.

Un iPad n'est pas un iPhone, ni un Mac, c'est un objet nouveau qui va permettre des usages nouveaux, intéresser d'autres populations d'utilisateurs, bousculer les habitudes, alléger les cartables des enfants, faciliter le suivi des patients à l'hôpital. Ce n'est pas, comme certains l'ont écrit, un simple terminal de "consommation". Bien au contraire, c'est un outil avec lequel on produira des données multiformes (la caméra viendra) et qui appellera le développement d'applications pour les manipuler. C'est l'objet avec lequel le "cloud computing" va massivement décoller et trouver sa justification. Je pense qu'on reparlera bientôt de MobileMe et des prochaines surprises d'Apple sur le sujet. La concurrence avec Google sera rude... La clé USB est aussi morte que la disquette !
avatar Nesus | 

superbe article et fine analyse^^

avatar Le_T | 

Article très pertinent !
Je trouve que c'est une bonne idée de demander lavis Dun pro du dev de nous donner sont avis sur les techno logicielles develloper et utiliser par iPhoneOS.
Merci,

avatar Dr_cube | 

Même si je n'ai pas l'expérience de Benoît Widemann, je suis développeur iPhone depuis plus d'un an et demi et j'ai enseigné le développement mobile (iPhone/Android) à des étudiants cette année. J'ai le même avis que lui sur quasiment tous les points évoqués.
En tant que spécialiste des IHM pour mobiles, je tiens à ajouter que la qualité des IHM est le point le plus important pour faire un logiciel sur iPhone ou iPad. Je ne sais pas exactement quel est le public de B. Widemann dans ses formations, mais les ingénieurs formés aujoud'hui sont généralement très largement sensibilisés à l'ingénierie des IHM. Durant mes études j'ai longtemps étudié le problème des IHM pour mobiles, alors même que l'iPhone n'était pas encore sorti. Le problème se pose depuis longtemps, et il est maintenant traité dans les formations des ingénieurs. Au niveau de la recherche, c'est encore "work in progress". Il reste beaucoup de problèmes à étudier, notamment en ce qui concerne la mobilité, et c'est assez excitant.

En outre, je suis persuadé que Google gagnerait à mettre plus de soins sur ses IHM mobiles. Android est une catastrophe sur ce point, et c'est le plus gros point faible de Google.

Faire des IHM, ce n'est pas seulement faire de jolies dégradées et de jolies transparence. Il s'agit d'un travail d'ingénieur à part entière. Apple a parfaitement intégré ce principe depuis le Mac des années 80. Je suis toujours étonné de voir que Google ou Microsoft ne présentent sur mobile quasiment que des IHM issues d'un joint fumé par un designer, sans aucune étude ou aucune science derrière.

avatar Manu | 

Je suis extrêmement réjoui de voir un pro du développement confirmer et surtout apporter plus de précisions sur les pensées que j'ai longtemps développées sur les forums de l'iPad et ce avant même son lancement. pour moi c'est simple. c'est le PC/Mac le plus approprié pour le Cloud.

Je suis même sûr que ce sont les développeurs qui vont l'emmener dans l'Entreprise. A commencer par IBM lui même qui mise sur l'iPad pour en faire un outil de choix pour accéder à ses service Lotus et autres.

La caméra pour moi est une seconde étape. Apple fait toujours bien de proposer des technos qu'il faut au bon moment et non tout en même temps. il faut laisser aux développeurs le soin d'aborder calmement ce nouvel outil qui implique de nouveaux usages.

avatar Macinlove | 

Je n'ai aucune compétences en développement, mais je me sens nettement plus éclairé après avoir lu cette excellente interview.

Ce qui serait encore mieux c'est que MAc Gé nous propose un petit lexique à l'usage des nuls comme moi. En termes clairs et simples, Cocoa, Java, Objective-C, Runtime, etc...

avatar Yohmi | 

Article particulièrement intéressant, et accessible surtout, ce qui est assez rare sur ce sujet (car ce n’est vraiment pas évident).

Merci beaucoup :)

Quant au ressenti de ce cher Monsieur sur l’iPad, je partage effectivement ses opinions, à un détail près : je n’aurai jamais les poches assez grandes pour un 9’’, donc je pense que le GSM n’est pas encore à enterrer. ^^

avatar flette | 

Superbe interview. J'ai le projet de faire développer une appli iPhone pour la PME dans laquelle je bosse et, malgré que je sois pas développeur, l'interview est compréhensible et tout en posant les problématiques techniques. Bravo & merci MacG

avatar oomu | 

tiens, je me demande bien ce qu'on peut reprocher à NSString ou le construct @ . Justement je viens d'un monde "php" / "java".

concernant, la mémoire, l'iphone/ipad n'embarque pas le "ramasse-miette" qu'a maintenant Mac os X.

-
>Ce qui serait encore mieux c'est que MAc Gé nous propose un petit lexique à l'usage des nuls comme
>moi. En termes clairs et simples, Cocoa, Java, Objective-C, Runtime, etc...

ben, effectivement, un glossaire dés la page de garde serait utile. Sinon WIKIPEDIA EST LE SAUVEUR DU MONDE.

Cocoa : c'est le "cadre de développement" (framework) : c'est en gros à la fois les fonctionnalités fournies par le système pour construire une application, les bonnes pratiques à respecter, le modèle dans lequel votre application va s'inscrire (un logiciel cocoa est en gros découpé en modèles qui décrivent les données, contrôleur qui manipule les données, et vues qui permettent à l'utilisateur de dire aux contrôleurs quoi faire. ) . Cocoa repose totalement sur des facilités du langage Objective C. Il serait difficile de porter Cocoa à un autre langage sans devoir porter des aspects entiers de Objective C. (principale difficulté de feu cocoa-java)

Java : autre grand langage/cadre de développement de l'industrie. Créé par feu-Sun (maintenant oracle) et maintenu par toute la clique d'industriels (opensource tel apache, ou directement ibm par exemple). Java c'est aussi bien un langage (une grammaire), qu'un cadre de développement (Java Enterprise) qui fournit toutes les briques imaginables pour concevoir un logiciel professionnel.

Objective-C , le langage au coeur de cocoa. Objective-C est une extension du langage C pour lui apporter le modèle de programmation dit "objet", très inspiré de Smalltalk. Ses 2 principales caractéristiques (selon moi) sont d'être basé "message" et d'intégrer un moteur d'exécution (runtime) pour que les applications objective-C soient dynamiques (changer leur comportement à chaud pendant l'exécution)

avatar oomu | 

le "runtime" est un sous-programme, presque indépendant, qui va être intégré dans le logiciel proprement dit. Le runtime gère toutes sortes de tâches nécessaires au bon fonctionnement du programme. Grâce à lui, le développeur n'a pas eu besoin d'écrire le fonctionnement exacte de tout le programme : la plupart des tâches routinières sont déjà écrites.

Ainsi tous logiciel Mac Cocoa ont tous ce fameux runtime en leur sein. Il est donc naturel qu'un logiciel objective-C (cocoa) exige + de ressource qu'un simple programme C, mais le confort gagné est incommensurable et profite dans une myriade d'aspects à l'interface du Mac/iphone.

le Runtime peut être aussi externe : il est démarré puis charge le logiciel pour lui donner vie. On préféra ici dire Machine virtuelle, comme Java ou C#/.NET. mais dans le fond, ca rend un service similaire.

-
j'oubliais, mais C#/.NET est un langage/cadre de développement de Microsoft. C# est le langage, comme Objective-C est le langage, .NET est l'ensemble des briques prêtes à l'emploi, comme Cocoa. Dans son fonctionnement, .NET est plus proche de Java.

avatar Macinlove | 

@ oomu : merci pour tes définitions (même si Wiki t'a donné un coup de main ;-)

avatar thierry61 | 

ITV très intéressant, c'est sur. Faut que le relise.
Je ne suis pas développeur, mais je rapproche l'état d'esprit de cet échange de certains propos que j'ai entendu de la part de gens qui, par le passé, n'auraient jamais parlé d'apple (hein ? le mac ? c'est quoi ce truc ?) mais évoquent aujourd'hui le phénomène iPhone et sa plate-forme de développement / commercialisation de logiciels en des termes que personne n'aurait utilisés du temps de l'Apple-fabricant-de-Mac-uniquement.

avatar Cactaceae | 

@ yohmi

Je pense que par disparition du GSM il a voulu parler de la norme GSM, pas de la téléphonie. La voix sera sur IP exclusivement, mais pas besoin de poches de 9" pour ça ;)

avatar ispeed | 

L'iPhone et l'iPad on s'en fou

avatar kubernan | 

- L'une des approches intéressantes et parfois nouvelle pour beaucoup de développeurs qui se mettent au monde Mac est de penser les choses en termes de solutions et non en termes de fonctions.
C'est d'autant plus vrai pour le développement sur iPhone.

- Quand un développeur cri au loup concernant la gestion mémoire, il faut alors s'en méfier car :
1- La gestion mémoire version Objective-C est d'une simplicité enfantine (La règle doit tenir en quelques lignes);
2- Il y a toutes les chances que le dit développeur en question n'a jamais fait de C (en passant directement à Java par exemple), ce qui est à mon avis souvent pénalisant pour sa flexibilité intellectuelle en terme de programmation.

- Je ne vois pas trop où est le problème avec les chaînes de caractères dans Objective-C mais bon.

Bon article en tout cas.

avatar coincoin13 | 

Je ne vois pas trop où est le problème avec les chaînes de caractères dans Objective-C mais bon.

sans doutes une allusion aux stringWithFormat:"%@%i%d..etc

avatar iBenji | 

Cette interview est vraiment intéressante. Dommage qu'elle soit si courte... :'(

avatar Newton Pippin | 

"C'est l'objet avec lequel le "cloud computing" va massivement décoller et trouver sa justification"

mouais, je préfère être old school et ringard mais garder tout pour moi sur mes disques durs et être le seul responsable et maitre de mes données. Pareil pour les applis si elles prennent le chemin d'abonnement à l'année, il sera temps d'appliquer la théorie de Coluche "il suffirait que les gens n’achètent plus pour que ça ne se vende pas"

le cloud computing ? sans moi...

avatar pecos | 

@coincoin13 :
ben... venant du PHP/javascript et faisant du dev iPhone depuis un an pour mon plus grand bonheur, je t'avoue que la première fois que j'ai dû concaté,er deux strings et que ça marchait pas avec chaine = chaine1.chaine2.etc...
J'ai bien failli laissr tomber cocoa.
Non je déconne, mais bon ça pourrait être plus limpide que d'utiliser [NSString stringWithFormat:@"%@%@%@",...,...,...]
Sinon, aucun pb de mon côté avec la gestion de la mémoire, et je suis totalement d'accord avec le dernier paragraphe sur l'iPad.
Vite, le mois de Mars !!!!!

avatar gloup gloup | 

[quote="Newton Pippin"]le cloud computing ? sans moi... [/quote]

Perso je suis bien content d'avoir une copie de mon carnet d'adresse et de mes calendriers dans le nuage. On peut faire autant de copie de sauvegarde que l'on veut, on n'est pas à l'abir de la foudre, d'un incendie ou d'un vol.

Le tout est de trouver une société digne de confiance pour y laisser des données personnelles. Je crois qu'Apple (Mobile Me) n'a pas intérêt à décevoir ses clients à ce niveau là. :-)

avatar thierry61 | 

Newton Pippin : "le cloud computing ? sans moi..."
Oui moi aussi je suis partagé sur certains aspects de ce truc; ça n'empèche que c'est une tendance de fond probable.

avatar Hasgarn | 

C'est vachement intéressant…
Du coup, je songe franchement à m'acheter un iPad 3G.

avatar Dr_cube | 

[quote]Android la cata niveau IHM ??? Au contraire, c'est souvent plus clair que sur iPhone grace au bouton menu par ex. La page d'accueil est aussi bien plus ergonomique.[/quote]
Je n'ai malheureusement pas le temps de détailler. Mais ce que j'affirme peut se justifier. Android est une véritable catastrophe en terme d'IHM. Je parle des version 1.6 et antérieures. Je n'ai pas encore testé la 2.1, mais j'ai vu de nombreuses vidéos qui me laissent penser que Google n'a toujours pas progressé.

avatar momo-fr | 

Content de voir Benoît sollicité de la sorte, c'est un bel exemple de professionnalisme, même si certains lui trouve une tête de techno trop étroite il reste très pertinent dans son analyse et c'est un très bon pédagogue. Bravo Benoît… ;-)

avatar altracan | 

Hey ho des fois il faut arrêter de boire toute la soupe d'apple. Qui va croire qu'il y a 140 000 applications sur iPhone? Je veux dire : qui va croire qu'il y a 140 000 applications RÉELLEMENT DIFFÉRENTES (c'est à dire en écartant la version française, allemande, tagalog, inuit d'une application de sudoku).
Compter de cette façon c'est un peu compter les versions de star wars : beaucoup de cassettes video et de dvd différents mais seulement 6 films...

Ha je suis bien d'accord que l'app store est un succès mais je serais content d'avoir les chiffres réels de ce qui circule aujourd'hui (et même si c'est seulement 10 000 voire 1 000 applications qui circulent en février 2010 en France)...

avatar BeePotato | 

@ pecos : « Non je déconne, mais bon ça pourrait être plus limpide que d'utiliser [NSString stringWithFormat:@"%@%@%@",...,...,...] »

Mais en fait C’EST plus limpide, puisqu’il faut utiliser stringByAppendingString:. ;-)

Les méthodes utilisant des formats ne sont pas là pour faire une simple concaténation de chaînes, mais pour les cas plus compliqués. Et pourtant, ce n’est pas la première fois que je vois quelqu’un faire cette erreur d’utiliser un stringWithFormat: juste pour concaténer deux chaînes.
Je trouve ça assez bizarre, parce que, puisqu’on parle de limpidité, il me paraît tout de même difficile de trouver un nom plus clair que stringByAppendingString:. Qu’on ne vienne pas me dire qu’utiliser un point ou un opérateur + est en quoi que ce soit plus limpide que ça ! (Plus court à taper, indéniablement, mais plus clair ? Absolument pas.)

avatar jodido | 

@BeePotato
on va pas rentrer dans des débats de geek mais un += est plus simple qu'un MaMéthodePourRajouterDuTexte (j'adore la verbosité de Objective C :D)
Par contre sur d'autres plateformes les MaMéthodePourRajouterDuTexte des classes String sont surtout utilisés pour des concaténations dynamique de texte (quand on ne sait pas exactement combien de chaine on va concaténer).
Quand on connaît exactement il est préférable de privilégier les += qui alloue la mémoire au plus juste pour la chaine de caractère.
Enfin je pinaille et je ne sais pas si c'est applicable pour Objective C (mais pour C++ et C# oui...) je n'ai pas trouver d'information à ce sujet sur la doc Apple :(

avatar yehedmad | 

Sinon pour les allergiques à Objective-C, il existe une solution pour développer des applications en Java sur iPhone, ça s'appelle iSpectrum ( http://www.flexycore.com )

CONNEXION UTILISATEUR