I’m doing some iPad coding and I really like the UIPopoverController widget for displaying various things. It is versatile and you can put almost anything in it. This widget can be used like a menu or contain a tableview or a palette with shapes or just anything. The possibilities are endless, almost. So when I needed to use a popover in an iPhone application that I wrote I was so disappointed it was an iPad only class. I wanted to implement a right navigation_bar_button so the user could set the sort order in a tableview and I thought the popover was the right way to do it. I have not found any explanation why Apple has chosen to only use it on the iPads bigger screen. I can understand that you have to be a little careful with the use of it but to omit it on the iPhone is just not right. So I looked on the net for an open source implementation and found Werner Altewischer’s WEPopoverController. It did the thing it should nicely but it had some images in the resource group and since I collect reusable classes in a static lib I thought I’ll fix this. But after some coding I found myself rewriting almost the whole functionality.

My basic ideas when writing reusable classes are:
• API should mimic Cocoa as much as possible
• Encapsulated design
• Prepared for static library, aka a Core Graphics implementation.

In this case I also wanted it to look as identical to UIPopoverController as possible and totally API compatible. I also wanted some extra functionality, like being able to set the backgroundColor and if the popover should have a gradient top etc.

When developing I tend to make the file structure as simple as possible so I try to keep the whole functionality in one .h and one .m file. This is not an important concern if the class will end up in a static library but as I tend to use it in various projects, to test it thoroughly, before they end up in the lib I do not want too many files clobbering up the projects where I test it. So almost like Java’s inner classes, supporting classes, if not really needed outside of the implementation, is hidden into the .m file of the main class. This is maybe not optimal in the development phase because the .m file tends to be quite big and it can sometimes be hard to find the methods, but nevertheless is looks good in the project it is used.

Next, the application Opacity is fantastic to make icons and other graphic resources with and it can make them not only in different graphic format but also in code, as Views, CALayers and even as Quartz functions. So it is easy to first draw the resource and then let Opacity convert it to a view class. The code may not always look that readable but it is a fantastic leaning start and later you can specialize, generalize and clean it up. So it was a great start for the Core Graphic code that was to be the base of the Popover view and I learned a lot from it.

When ready I will make the Popover code open source on my GitHub repository.