IPhone development tips - Revision history

Lensovet: tethering note

2010-03-28T08:10:05Z

tethering note

Lensovet: audiosession-related stuff

2010-03-27T20:18:02Z

audiosession-related stuff

Lensovet: lowercase title woot!

2010-01-07T21:23:40Z

lowercase title woot!

Lensovet: viewWillAppear + Xcode tips

2010-01-07T21:06:02Z

viewWillAppear + Xcode tips

Lensovet: Created page with '*Distinction between calling [self.property release] and self.property = nil :The latter will allow you to assign the variable later and should generally be used when you want to…'

2009-12-28T04:33:24Z

Created page with '*Distinction between calling [self.property release] and self.property = nil :The latter will allow you to assign the variable later and should generally be used when you want to…'

New page

*Distinction between calling [self.property release] and self.property = nil
:The latter will allow you to assign the variable later and should generally be used when you want to "clear" a variable for memory saving purposes but will have a need to assign a value to it again sometime in the future. <tt>release</tt> will completely invalidate the object and attempting to call ''anything'' on it afterwards will result in a EXC_BAD_ACCESS error every time. What does this mean in the grand scheme of things? You will most likely use <tt>release</tt> in only one place in your code – the object's <tt>dealloc</tt> method.
*Watching out for deallocation and unloading of views
:Keep in mind that if a bunch of view controllers nested one above the other, there's a bunch of unloading and deallocating happening when these views disappear (hopefully, as you should be keeping your memory usage to a minimum). In one of my view controllers, I was overfreeing controller properties because I attempted to free them inside both <tt>viewDidUnload:</tt> and <tt>dealloc</tt> methods. Just remember that a view should only be getting dealloc'ed after it's been unloaded, so you only need to free most things in <tt>viewDidUnload:</tt>.

@@ Line 10: / Line 10: @@
 *GPS shuts off when user locks the screen manually or the device auto-locks
 :You can use <tt>[UIApplication sharedApplication].idleTimerDisabled = YES;</tt> to keep the screen on, but this is bad for the screen itself and takes a nice toll on battery life. Instead, set up an <tt>AVAudioSession</tt> with the <tt>AVAudioSessionCategoryPlayback</tt> category, then set the <tt>kAudioSessionProperty_OverrideCategoryMixWithOthers</tt> property (so that the user's iPod can keep playing) and a more aggressive I/O buffer using <tt>kAudioSessionProperty_PreferredHardwareIOBufferDuration</tt>. Then, use <tt>AVAudioPlayer</tt> to play a "recording" of total silence on endless loop for when you need to keep GPS running. <em>Note</em>: accelerometer and WiFi still shut off when the screen is locked.
 *Calling <tt>[[AVAudioSession sharedInstance] setPreferredIOBufferDuration:</tt> always errors, regardless of what value you use!
 :See [http://stackoverflow.com/questions/1714507/recording-audio-on-iphone-error-with-setpreferrediobufferduration/2530737#2530737 my response on StackOverflow]. Basically this is a bug in the interface and you '''have''' to use the plain C method instead of the Objective-C one to get this to work.

← Older revision		Revision as of 20:18, 27 March 2010
Line 8:		Line 8:
	*Xcode is unable to connect to your device for some reason		*Xcode is unable to connect to your device for some reason
	:Sometimes Xcode will show your phone as being connected but will be unable to initialize it for development purpose for some bizarre reason. Simply restart your phone to fix the problem.		:Sometimes Xcode will show your phone as being connected but will be unable to initialize it for development purpose for some bizarre reason. Simply restart your phone to fix the problem.
		+	*GPS shuts off when user locks the screen manually or the device auto-locks
		+	:You can use <tt>[UIApplication sharedApplication].idleTimerDisabled = YES;</tt> to keep the screen on, but this is bad for the screen itself and takes a nice toll on battery life. Instead, set up an <tt>AVAudioSession</tt> with the <tt>AVAudioSessionCategoryPlayback</tt> category, then set the <tt>kAudioSessionProperty_OverrideCategoryMixWithOthers</tt> property (so that the user's iPod can keep playing) and a more aggressive I/O buffer using <tt>kAudioSessionProperty_PreferredHardwareIOBufferDuration</tt>. Then, use <tt>AVAudioPlayer</tt> to play a "recording" of total silence on endless loop for when you need to keep GPS running. <em>Note</em>: accelerometer and WiFi still shut off when the screen is locked.
		+	*Calling <tt>[[AVAudioSession sharedInstance] setPreferredIOBufferDuration:</tt> always errors, regardless of what value you use!
		+	:See [http://stackoverflow.com/questions/1714507/recording-audio-on-iphone-error-with-setpreferrediobufferduration/2530737#2530737 my response on StackOverflow]. Basically this is a bug in the interface and you '''have''' to use the plain C method instead of the Objective-C one to get this to work.

← Older revision		Revision as of 21:23, 7 January 2010
Line 1:		Line 1:
		+	{{lowercase title}}
	*Distinction between calling [self.property release] and self.property = nil		*Distinction between calling [self.property release] and self.property = nil
	:The latter will allow you to assign the variable later and should generally be used when you want to "clear" a variable for memory saving purposes but will have a need to assign a value to it again sometime in the future. <tt>release</tt> will completely invalidate the object and attempting to call ''anything'' on it afterwards will result in a EXC_BAD_ACCESS error every time. What does this mean in the grand scheme of things? You will most likely use <tt>release</tt> in only one place in your code – the object's <tt>dealloc</tt> method.		:The latter will allow you to assign the variable later and should generally be used when you want to "clear" a variable for memory saving purposes but will have a need to assign a value to it again sometime in the future. <tt>release</tt> will completely invalidate the object and attempting to call ''anything'' on it afterwards will result in a EXC_BAD_ACCESS error every time. What does this mean in the grand scheme of things? You will most likely use <tt>release</tt> in only one place in your code – the object's <tt>dealloc</tt> method.

← Older revision		Revision as of 21:06, 7 January 2010
Line 3:		Line 3:
	*Watching out for deallocation and unloading of views		*Watching out for deallocation and unloading of views
	:Keep in mind that if a bunch of view controllers nested one above the other, there's a bunch of unloading and deallocating happening when these views disappear (hopefully, as you should be keeping your memory usage to a minimum). In one of my view controllers, I was overfreeing controller properties because I attempted to free them inside both <tt>viewDidUnload:</tt> and <tt>dealloc</tt> methods. Just remember that a view should only be getting dealloc'ed after it's been unloaded, so you only need to free most things in <tt>viewDidUnload:</tt>.		:Keep in mind that if a bunch of view controllers nested one above the other, there's a bunch of unloading and deallocating happening when these views disappear (hopefully, as you should be keeping your memory usage to a minimum). In one of my view controllers, I was overfreeing controller properties because I attempted to free them inside both <tt>viewDidUnload:</tt> and <tt>dealloc</tt> methods. Just remember that a view should only be getting dealloc'ed after it's been unloaded, so you only need to free most things in <tt>viewDidUnload:</tt>.
		+	*Passing viewWillLoad/viewDidLoad/viewWillAppear/viewDidAppear/etc methods to child view controllers
		+	:Say you have a view controller which manages a child view controller. The child view controller's viewWillAppear and related notification methods will not be called automatically by the OS for you. Your parent view controller needs to call those methods manually.
		+	*Xcode is unable to connect to your device for some reason
		+	:Sometimes Xcode will show your phone as being connected but will be unable to initialize it for development purpose for some bizarre reason. Simply restart your phone to fix the problem.