Force UINavigationBar Back Bar Item Display

The latest project that i have been working on has the CRAZIEST workflow that I have ever experienced.  The app isn't in the app store, but is used as a sales tool for the type of services that their company can offer.  Surprisingly, at least to myself, I was able to come up with my own navigation controls to manage the workflow.  The workflow consisted of various tabbarcontrollers, uinavigationcontrollers, fullscreen views, some with navigation bar, some without.  What ended up being the trickest parts to deal with was handling the transitions between full screen views and views with the navigation bar along with the back button.  My first attempt in the transition worked except for the fact that the back bar item was BEHIND the uinavigationbar titleView.

The problem was that I was setting the back baritem to visible in viewWillAppear:animated: and then calling setNeedsDisplay on the navigationbar.  That works, but the "refresh" of the view and animation would stop once the method ended.  The fix ended up being setting the back baritem to hidden and refreshing the navigationbar in viewWillAppear:animated:

Creating a Universal iOS App Tutorial

Just when I thought I had a somewhat decent grasp on developing and deploying iOS apps Apple came out with the iPad and threw a whole new element in the mix when it comes to developing.  Thankfully, the iPad will allow iPhone apps to run on the device, but the user experience is definitely sub-par.  So what is the best approach to providing an native iPhone app and a native iPad app?  The first option is to duplicate your existing iPhone app code base and modify all your views and some of the controllers to take advantage of the features in the 3.2 SDK.  The problem with that is the massive DUPLICATION of code and to be honest it seems quite lazy.  I have seen lots of examples where developers use the idiom check for which device is being used, as well as, runtime checks for selectors in order to leverage the correct methods/classes for the given device.  While this is certainly a better approach then having two separate code bases with 90% of the same code you now have code that is sprinkled/littered with if/else checks.  Unfortunately, you are once again stuck with code that will be maintainable for long.  After reading the chapter on universal apps from the upcoming book from Pragmatic Programmers, iPad Programming, I found a much better design pattern of splitting out the app into Shared, iPhone and iPad resources, classes and delegates.

As a side note, due to the ever exponential growth of iOS device popularity developers are not going to have the bonus of just jumping straight into writing an app like we did when there was just the iPhone.  A lot more thought needs to be given to design patterns (especially regards to the quality of your MVC) and application flow.

In order to make life a little easier on myself since a few universal apps are coming in my near future I decided to create a basic "template" for a universal app.

  • Compiled for 3.2 and 4.0
  • Utilizes navigation controller based app for iPhone device and SplitViewController for iPad
  • Shared "model" class and controller classes
  • Separate resources (classes/xibs) for the different devices

Comments and improvements are ALWAYS welcome.  One improvement that I know I want to make is having the "detail" controller from the SplitViewController to be a UINavigationController.