Customizing UIActionSheet Buttons

One of the great benefits of iOS development is that Apple has provided the ability to customize almost any element thus not limiting a designer or developer with a stock look and feel.  Just take a look at subtle examples in Twitter for iPhone to the extreme of the Outside Weather app or Starbucks.  I am working on a nice size project and one of the requirements is to have the UIActionSheet buttons be a different color than the default gray color.  This turned out the be as straightforward as trying to change the look and feel of a tabbar.

::NOTE TO APPLE:: Customizing Tabbars and UIActionSheet buttons should be a lot easier. ::END NOTE::

It took a few hours, but I finally knocked it out.  At first glance I figured that each one of the buttons would be an instance of UIButton and I could located them in the view hierarchy and just update the background color either in a delegate method or subclass UIActionSheet and override drawRect:.  NEGATIVE.  

My next possible approach was to create my own custom view(s) and slap them on the UIActionSheet's main view and send everything else to the back.  Granted that has worked for some people and is a totally viable option, but I found it to be a very hacky solution for what I was doing.

After looking up a few questions on StackOverflow it turns out that sometime after iOS 3.1 the subviews in the UIActionSheet are an undocumented class instances of UIThreePartButton.


After digging up that little nugget about UIThreePartButton I finally had turned a corner.  The next hurdle was trying to find the correct method to use from the UIThreePartButton class to change the background color.  Unfortunately, there isn't a backgroundColor property for that.  Granted since I am dealing with a class that inherits form UIView I could set the subviews backgroundColor property to [UIColor redColor], but when I did that I didn't get the expected result of a button with a red background.  The button became a red tint and the view behind the button was red as well.  Obstacle.  Looking at the methods/properties that I DID have I went on a little intuition that Apple wasn't using a color, but a stretchable background image for the button.  I grabbed the background graphic that I wanted and used - (void) setBackgroundImage:.  SUCCESS!!!!!!!

I wasn't quite finished.  Background button was what I wanted, but I needed to change the font color from black to white.  But wait there isn't a method to set the font. However, UIPushButton inherits from UIThreePartButton so once again going on an educated guess/intution I was able to use setTitleColor:forState: and perfection.  Excatly what I wanted and needed.  UIActionSheet with red buttons and white font.

Even though I can't submit any app to the AppStore because of the undocumented class working through the exercise was very enlightening in the areas of ui customization, design patterns and general problem solving skills which should always be in the top of a developer's skillset.

I posted my example on github.  It was compiled with 4.0 with XCode 4 Preview 3, but XCode 3.x should work.  If you run into any problems then let me know.

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.