framework

Google IO kicked off yesterday with the keynote at the Moscone Center in San Francisco. The keynote is always an exciting event with the big names on center stage filling your ears with all the great new and upcoming tech. While this years keynote steered away from hardware and more specifically Key-lime Pie, it was till jam

For the most part iOS will let you code anything you want, however occasionally you will find the need to do something out of the ordinary, or reuse an existing class. Trying to do this with public APIs can be a headache, and often requires tons of code. You may heave heard of private APIs, and also may have heard about how apps get rejected from the AppStore for using them. This is often true, but if you know how to safely and properly use private APIs then you can harness their power.

During iOS development at b2cloud, apps contain our in-house development framework FivePin. FivePin lets us easily and quickly track down bugs and other problems that may come up while building apps. We unveiled the FivePin.framework a while back at a talk and today it’s finally public.

If you’ve ever needed to have an object with multiple delegates you may have created an array and then added each of your delegates to it. This does work but there’s a simpler way which is much easier to implement. Using the NSNotificationCenter you can have objects subscribe to the events/messages they want to know about and get called whenever that ‘event’ takes place. The Cocoa framework uses this as well, and let’s you subscribe to things such as an app entering the background, changing orientations, when it’s running out of memory and when the keyboard is presented or dismissed.

When developing on the Mac and using custom frameworks in your application, when you compile the frameworks are copied into your applications bundle then linked at runtime. These frameworks will most likely be bundled up with their headers. Some of the frameworks you include may not be things you want to make public to the world, which you are essentially doing by including the headers with the framework.

After developing iPhone applications for a while you tend to develop some ‘must have’ pieces of code that you use on all of your apps. Being able to share the code on multiple projects is great but having the code duplicated among many projects is very annoying, especially if you make an update, you would need to change all files to reflect the changes. Of course you could just reference the same source files from all your apps, but this can cause conflicts when other developers try to pull the project from the repo as the path to the source files has probably changed. It’s time to make a Framework, a compiled binary of your source that can be included in your projects, keeping the source in one place.