›

Envie de m'y mettre !

muqaddarmuqaddar Administrateur
19:45 modifié dans API UIKit #1
Coucou les amis,

J'ai bien envie d'essayer cet iPhone SDK puisque j'ai enfin l'iphone depuis 1 mois !
Souvenez-vous, j'ai programmé un an en cocoa en 2005, mais pour le Mac... (les plus vieux du site le savent) avant de me remettre au Web.

Dois-je avoir peur de me mettre à  l'iphone ? Mes souvenirs vont-ils m'aider ? Y a-t-il de grandes différences ? Je veux dire, à  part la gestion du tactile, part-on sur les mêmes bases ?

J'ai une petite idée d'appli dans ma tête.
Bien entendu, je vais faire cela à  mes heures perdues...

:p <3 <br />

Réponses

  • ChachaChacha Membre
    19:45 modifié #2
    dans 1231933175:

    Dois-je avoir peur de me mettre à  l'iphone ? Mes souvenirs vont-ils m'aider ? Y a-t-il de grandes différences ? Je veux dire, à  part la gestion du tactile, part-on sur les mêmes bases ?


    Mon expérience à  moi :
    L'environnement te sera familier : Cocoa, documentation, interactions entre les objets, philosophie Cocoa, conception des interfaces sous IB et lien avec le code de XCode...

    Par contre, la transition n'est pas si facile, car l'interface utilise à  fond les "controlleurs" pour l'abstraction, et ne serait-ce qu'une UITableView est difficile à  mettre au point, car assez différente d'une NSTableView. Les controlleurs sont vraiment omniprésent, et les .NIB ont tendance à  être éclatés en plusieurs .XIB.
    De plus, CoreAnimation est quasiment incontournable, donc il faut avoir saisi le concept et ses coups tordus.
    Au total, la transition vers iPhone SDK, j'ai trouvé ça plus dur que prévu.

    +
    Chacha
  • AliGatorAliGator Membre, Modérateur
    janvier 2009 modifié #3
    Salut chef !

    La majeure partie est très ressemblante entre Cocoa et CocoaTouch.
    Les différences qui me viennent à  l'esprit :
    • Il n'y a pas de Garbage Collector dans l'iPhone (et c'est tant mieux si tu veux mon avis :P mais de toute façon ça va pas te changer car en 2005 il n'existait pas)
    • Certaines API ne sont pas encapsulées en Objective-C, il faut donc parfois faire appel à  des fonctions C. Par exemple pour le dessin dans une Custom View, il n'y a pas les NSBezierPath, il faut passer directement par CoreGraphics et appeler genre CGContextAddPath(...), etc
    • D'autres API ne sont carrépent pas disponibles car trop lourdes (mais y'a toujours une solution pour contourner). Par exemple le parsing XML en DOM n'est pas dispo, poru des raisons d'utilisation mémoire évidentes, mais il est toujours dispo en SAX bien sûr sans problème.
    • l'API iPhone utilise beaucoup les @property qui sont une nouveauté de l'Objective-C 2.0 (et que perso je trouve assez pratiques). Elles existent aussi pour Cocoa sur Mac bien sûr, mais on sent qu'elles sont loin d'être omniprésentes, de par le passif de Cocoa créé à  l'origine en Objective-C 1.0... alors que sur iPhone dans les nouvelles classes développées ils en profitent pour utiliser massivement les @property
    • Un truc un peu déroutant au début, pour la gestion de l'interface, c'est les ViewControllers, à  quoi ils servent et comment ils sont organisés. C'est pas bien méchant mais la première fois que tu ouvres un projet iPhone depuis un template faut prendre le temps d'étudier et bien capter comment c'est organisé.


    Sinon les trucs pour lesquels il faut faire gaffe quand on développe sur mobile, en particulier des applications qui prennent vite de l'ampleur, c'est la gestion mémoire, puisque sur un iPhone comme tout autre mobile on a une mémoire plus limitée que sur un ordi.
    Donc ça implique par exemple préférer le release à  l'autorelease quand c'est possible, tant qu'à  faire, mais surtout séparer au mieux son interface dans des fichiers NIB séparés plutôt qu'un seul gros NIB.

    Après, tu peux voir sur cette page tout ce qu'il faut savoir pour "migrer" du Cocoa/Mac à  l'iPhone (nécessite de te connecter avec ton login ADC), ainsi que les différences majeures entre les 2 frameworks.


    [EDIT] Pour reprendre un peu ce que dit chacha, je confirme donc l'éclatement des NIB et l'omniprésence des ViewControllers... par contre je n'ai encore jamais eu à  toucher à  CoreAnimation. La seule chose relative à  CoreAnimation à  laquelle j'ai déjà  touché c'est de faire [tt][UIView startAnimations:nil context:NULL][/tt] au début d'un bloc et [tt][UIView commitAnimations]; à  la fin, pour que les modifications (de position, orientation, etc...) que j'ai faite entre ces 2 lignes soient animées... on peut pas dire que ça soit compliqué et tordu :P
  • Philippe49Philippe49 Membre
    19:45 modifié #4
    Un autre aspect fort amusant de cette programmation c'est que le dialogue programme/utilisateur est différent. En travaillant d'abord uniquement avec le simulateur, j'ai continué un peu l'interfaçage Cocoa classique, mais l'utilisation de mon ipod touch a fait complètement basculé ce "design d'interface" : utilisation de l'UIAccelerator, du glissé sur l'écran, recherche naturelle par l'utilisateur des zones actives très différentes, standards d'interface très précises sur l'iPhone.

    Les arborescences (views, viewcontrollers) suivent également des modèles différents.   
  • muqaddarmuqaddar Administrateur
    janvier 2009 modifié #5
    Merci à  tous les 3.
    Je viens de télécharger le SDK et j'ai créé rapidement un projet de chaque type pour voir un peu les différences (tabbar, navigation, utility...etc).

    Je me suis rapidement rendu compte que vos remarques sur l'éclatement des Nibs est justifié. Cela ne me dérange pas bien au contraire. Dans le cas d'une appli avec une TabBar, je trouve cela plutôt sain d'avoir un Nib par vue. Surtout si elles sont destinées à  des choses bien différentes.

    Quand je me suis arrêté en 2006, j'utilisais les bindings, mais pas CoreData. Apparemment CoreData n'est pas implémenté sur l'iPhone et c'est tant mieux. Les bindings le sont-ils ?
    Comment stockez-vous vos données ? Les incontournables plist ? Tous sous sqlite ? (zut, je l'utilisais pas à  l'époque). Et si vous avez des fichiers importants (genre 500 ou 1000 entrées c'est déjà  pas mal pour un smartphone) ?

    [EDIT] Je viens de trouver ma réponse pour les bindings.
    Donc pour charger une tableView en données, je supose qu'il faut se retaper les méthodes datasource à  l'ancienne ?
  • amnesicamnesic Membre
    19:45 modifié #6
    dans 1231946512:

    Comment stockez-vous vos données ? Les incontournables plist ? Tous sous sqlite ? (zut, je l'utilisais pas à  l'époque). Et si vous avez des fichiers importants (genre 500 ou 1000 entrées c'est déjà  pas mal pour un smartphone) ?


    Sqlite est vraiment très efficace pour le stockage et avec le Cocoa "wrapper" FMDB c'est un vrai plaisir à  programmer :

    http://blog.saers.com/archives/2008/03/14/sqlite-for-iphone-sdk/

    Sinon j'ai trouvé les PDFs des cours de stanford pas mal du tout aussi pour appréhender le dev pour iPhone :

    http://www.stanford.edu/class/cs193p/cgi-bin/index.php
  • muqaddarmuqaddar Administrateur
    19:45 modifié #7
    Merci amnesic.

    Moi je vais commencer par étudier tous les petits exemples d'applis :
    http://developer.apple.com/iphone/library/navigation/SampleCode.html
  • Eric P.Eric P. Membre
    19:45 modifié #8
    Bonsoir,

    Je suis passé de REALbasic à  Xcode pour le développement sur iPhone et j'ai été bluffé par les possibilités.
    Il ne s'agit pas d'un téléphone mais d'un véritable ordinateur.

    Eric
Connectez-vous ou Inscrivez-vous pour répondre.