Ios

If you've done any work with background refresh (application:didReceiveRemoteNotification:fetchCompletionHandler:) on iOS 7 you know that it can be a pain to debug your code with. Some things I've discovered: Background refresh will start your app if it's not running.If you force-quit an application, it's not eligible to be started by a push notification. Restarting the app or rebooting is the only way to again receive background push wakes.You can't really debug wake by push other than with logging.Touching UI code in application:willFinishLaunchingWithOptions: is risky with background push since it fires but didFinishLaunchingWithOptions won't if it's immediately backgrounded. If you're using UIStateRestoration, make sure you're limiting UI code in willFinishLaunchingWithOptions to setting up the root view controller.Don't arbitrarily reset the badge count when your app is presented - you should really reset the badge count when the notification is viewed/considered no longer relevant.Update your push service to send "all clear" or zero count badges when things are read via other instances of your app (web, other iOS device, Android too). Your users will thank you that they're cleared everywhere.Take a look at Apple's documentation on app lifecycle - there is an excellent set of graphics to demonstrate where things hook in.

Back in iOS 4, a nifty block-based observer method was added to NSNotificationCenter: (id)addObserverForName:(NSString *)name object:(id)obj queue:(NSOperationQueue *)queue usingBlock:(void (^)(NSNotification *))block; Super convenient, right? I love using blocks to pass simple callbacks to controllers instead of creating a delegate protocol. There is a catch with this method, and it's not terribly obvious unless you're looking closely. The method returns (id) - according to Apple's documentation the return object is "An opaque object to act as the observer". What does this mean? ...

If you're looking to get higher frame rates and general application performance tweaks from your iOS application, you may need to take a look at transparent settings on your subviews. Any time you set a subview to be transparent, the OS has to blend multiple layers together to figure out the end flattened result. This blending takes CPU cycles and can impact performance of your app - especially in something as simple as a UITableViewCell. ...

Yes, there are three ways to represent a null value in Objective-C. NULL = Absence of a value with C-style pointers nil = Absence of value with Objective-C object variables NSNull = A nil boxed as an object for storage in a collection If you try adding nil to a NSDictionary or NSArray, you will find out it doesn't perform as expected. If you absolutely need to store a null value in a collection, you can use NSNull to represent the lack of a value. For example: ...

Ever wanted to have alternated colors on your table view cells? If so, you've probably done something inside of cellForRowAtIndexPath and applied a background color to your cell there. Would you be surprised to know that's completely wrong? Yup. Wrong. WRONG WRONG WRONG. I didn't know this, but any styles applied to cells based on state or whatever should really be in willDisplayCell - NOT when you configure the cell itself! Per Apple's documentation for the Table View delegate - ...

We all like to put the current application version number in an "about" screen somewhere for users to reference. It's a pain, however, to have to update that screen every time we do a release as well as the version in the target configuration for the bundle. So why not pull the version number from the bundle? Here's how to do it: NSString version = [[[NSBundle mainBundle] infoDictionary] objectForKey:(NSString)kCFBundleVersionKey]; NSString *version = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleShortVersionString"]; ...

I spent the past week pulling out my hair trying to submit an update for Centare's EyeOnWeather application to iTunes Connect. I kept getting a reject from the system and all I got for an error message was "Invalid Binary." THANKS, THAT'S SOOPER. Eventually I ended up attempting to contact iTunes Connect Support for further details. I thought it might have been missing icons, malformed Info.plist, something. I haven't changed anything in the project drastically with how it builds, so I was at a loss. Turns out, I was picking the wrong provisioning profile in my setup. Man I felt stupid. Ends up that I'm not crazy - Apple's documentation on how to set up your project for building still only references Xcode 3. Awesome for the rest of the world using Xcode 4. Here are some tips I got from Apple iTunes Connect support for pulling in information to submit to their developer team: ...

I've been using a UITextView in an app and realized that it didn't have any rounded edges like the default behavior exhibited by the built-in iOS apps. For example in the calendar app, setting the Notes field shows: Inside of Apple's Human Interface guidelines it specifically states "A text view is a rounded rectangle of any height. A text view supports scrolling when the content is too large to fit inside its bounds." Adding a UITextView to a view shows square corners by default. So how the hell do you get rounded corners? Interface Builder doesn't show anything about corners. Seems like the only way to get this behavior is by doing the following in code: ...

I'm submitting a new version of my Migraine Diary App to the App Store and was running into problems with Xcode 4 giving me the following error: "[Your App Name] does not contain a single-bundle application or contains multiple products. Please select another archive, or adjust your scheme to create a single-bundle application." There is an issue or maybe it's an intentional design thing with Xcode 4 and how it handles statically built libraries being included in your project. I'm specifically using Core Plot and it's instruction set hasn't been updated for Xcode 4 yet. Here are the things I had to do to get Core Plot to bundle correctly with my App to submit it: ...

I've brought an old project out of the moth balls recently, the Migraine Diary application I wrote as part of my master's thesis. It was my first "real" iPhone app and I call tell I didn't know what I was doing entirely looking through the code. What this has forced me to do, however, is re-learn some of the basics of iOS development and of Apple design patterns. I have been spending some time back in the Apple developer documentation and will probably be posting some of the gotchas that tripped me up two years ago and I'm solving now with the better, more elegant solution. ...