Voici quelques notes prises lors de mon auto-apprentissage sur le développement d’applications iphone.

En effet, étant du genre « c’est quoi déjà? », j’ai regroupé quelques informations dans cet article afin de pouvoir centraliser certaines informations que j’ai trouvées pertinentes… En espérant que cela puisse vous aider aussi.

L’essentiel des informations étant en anglais, j’ai donc laissé l’information dans la langue originale.

Some Objective-C stuff

• When declaring a method, « - » is fr instance methods, « + » is for Class methods.
• If you message nil, it returns zero.
• with NSString inValue returns 0 if it’s not an integer. If it starts with an integer but followed by « crap » (9873ikdi) it will return the integer (9873). Same thing with floatValue, doubleValue…
• If you overwite the -(id) init method, always return the result of [super init].
• when release method is called, the retain count is decreased, if it’s zero then the dealloc s called
• never call -(void)dealloc directly, except if you overwite the -(void)dealloc method, you should call [super dealloc].
• if your method returns an object that you created in the method:
  • use the [newObject autorelease] or
  • prefix your method name with « alloc », « copy » or « new » to inform the developer that he will have to release it
• balance the number of retain and release
• If you use autorelease, the object will be put in the autorelease pull. At the end of the event handling cycle,  the autorelease pull will call the release method on the objects in the pull, and if the retain count hits 0, the object is deallocated)
• « attribute.property = value » will call the setter, but « property = value » will access the property directly
• you can overwite -(void) awakeFromNib method in your AppDelegate to initialize values

From « iPhone Application Programming Guide« 

• When your application quits, you should save out information about your application’s current state in addition to any unsaved data. At launch time, you should look for this state information and use it to restore your application to the state it was in when it was last used.

• All applications should respond to this notification and do their part to help relieve the memory pressure. For information on how to handle such notifications in your application, see “Observing Low-Memory Warnings.”
• Icon.png is mandatory
• an application can be interrupted by an incoming phone call, an SMS message, a calendar alert, or by the user pressing the Sleep button on a device.(…) If the user decides to take a call or reply to an SMS message, however, the system does proceed to terminate your application.
• A keychain is a secure, encrypted container for passwords and other secrets. The keychain data for an application is stored outside of the application sandbox.
• Avoid writing cache files to disk. The only exception to this rule is when your application quits and you need to write state information that can be used to put your application back into the same state when it is next launched.
• Unlike most desktop applications, where the user manually chooses when to save files to disk, your application should save changes automatically at key points in your workflow. Exactly when you save data is up to you, but there are two potential options. Either you can save each change immediately as the user makes it, or you can batch changes on the same page together and save them when the page is dismissed, a new page is displayed, or the application quits. Under no circumstances should you let the user navigate to a new page of content without saving the data on the previous page.
• If your application accesses the network using the Wi-Fi radios, you must notify the system of that fact by including the UIRequiresPersistentWiFi key in the application’s Info.plist file. The inclusion of this key lets the system know that it should display the network selection panel if it detects any active Wi-Fi hot spots. It also lets the system know that it should not attempt to shut down the Wi-Fi hardware while your application is running.
• UIView:

NSFetchedResultsController: A « helper » controller between TableViewController and Core Data.

• Load data lazily
• multiple NIBs so you don’t load everything at the same time
• Every controllers can receive didReceiveMemoryWarning… By default, it will unload all the views that are not on screen… So ViewDidLoad can be called more than once (at te beginning and after a memory Warning when the view needs to be reloaded)

More to come from the « iPhone Human Interface Guide« …

Sources:

http://developer.apple.com/iphone/index.action

http://deimos3.apple.com/WebObjects/Core.woa/Browse/itunes.stanford.edu.3124430053.03124430055