These days I’ve been working on some fairly advanced iOS development techniques on my various projects: I’ve taught myself (badly) about Core Audio, I’m learning OpenGL, I’m developing a series of applications using Core Data, asynchronous parsing of JSON from a streaming HTTP connection, etc. It’s extremely fun and easy once you understand the basics.

What I tend to forget however is that you have to crawl before you can walk, and many people still struggle with some of the simpler techniques that I’ve learned that may not be so obvious, even when reading books or tutorials on Objective-C programming.

Since my previous series of articles on Core Animation (Part 1, Part 2, Part 3, Part 4) were so well received, I thought I’d do another series of articles titled “Back To Basics”.

So without further ado, I give you the first part in my series: Positioning UIViews.

(more…)

Like most developers, I look to Apple’s default application templates to get up-to-speed on what would appear as being the Right Way™ of developing apps on iOS. In practice however what you need to realize is Apple’s templates are meant to be the easiest introduction to a set of tools that can be fairly complicated for beginners to understand.  Core Data is one of those areas. The problem is when you try to grow your application you’ve built on top of Apple’s sample template. You’ll experience some annoying growing pains, and will need to give your code a thorough washing and a fresh coat of wax to be able to mature your application.

In my code I’ve learned to share and reuse my classes with other applications I’m writing by encapsulating a lot of the boilerplate into reusable classes, as well as wrapping my whole Core Data model in a reusable static library. This wasn’t the most intuitive thing to get right, but now that it’s done it was really worth the effort. Let me show you how it’s done.

(more…)

I’ve written about building iOS applications with Hudson Jenkins, but until recently there hasn’t been a convenient way of getting those applications to your testers. Of course the most important part of your build output will be the app bundle you send to Apple’s iTunes Connect web interface, but throughout your development cycle you’ll want to test your app.  Sure you could build and deploy a debug build straight to your own personal device, but you get the most benefit from having other people beta test your app.

With recent releases of Xcode and the iOS SDK, Apple improved their AdHoc distribution support with two main enhancements:

1. Mobile provisioning files can now be embedded in the App’s IPA itself, meaning you don’t have to maintain and update separate .mobileprovision files separately;
2. A specially-formated manifest Plist file can be created that, when linked to properly, allows test devices to install new versions of your AdHoc app without needing to plug into a computer to sync the app using iTunes.

These improvements are huge, but require some changes to your build scripts and your Continuous Integration environment.  I’d like to show you how to do this in your own installations, and show you some options for how to distribute your apps to your testers.

(more…)

This is the fourth in a series of posts I’m writing on animating iOS interfaces using Core Animation. In the first post I created a planetary orbit demo using nested CALayer objects. The second post showed how to dress up a UI by animating an image. The third post shows how you can trigger animations in response to button actions.

This post will show how you can create the beginnings of a full game using Core Animation combined with CAShapeLayer and UIBezierPath objects.

Read on to see more

(more…)

This is the third in a series of posts I’m writing on animating iOS interfaces using Core Animation. In the first post I created a planetary orbit demo using nested CALayer objects. The second post showed how to dress up a UI by animating an image.

This time I’ll show how you can trigger animations in response to button actions to illustrate to the user that an action is taking place.

Read on to see more

(more…)

This is the second in a series of posts I’m writing on animating iOS interfaces using Core Animation. In the previous post I created a planetary orbit demo using nested CALayer objects.

This time I’m going to show how you can dress up a UI by creating a simple effect using an image and Core Animation.

Read on to see more

(more…)

One of the greatest things about the iOS platform and applications people see on it is its beauty. Smooth gradients, consistent transitions, and animations that illustrate the transition of UI elements from one state to another. Animations are more than flashy eye-candy; they tell the user what’s happening. If an element is being deleted, instead of it simply disappearing it fades or slides out of view. Unlike traditional desktop or web applications where a “2 items deleted” statusbar message is necessary, these animations are in many cases enough.

Knowing where to start with animations can be a problem for developers though, because there’s many different steps involved. Instead of walking you through it fully here in the blog, I highly recommend you watch the WWDC 2010 videos on the topic. I truly mean it; anything I do here will simply be a rehash of that material, and I don’t see the point in reproducing perfectly good documentation unnecessarily.

• WWDC 2010 Session 123 – Building Animation Driven Interfaces
• WWDC 2010 Session 424 – Core Animation in Practice, Part 1
• WWDC 2010 Session 425 – Core Animation in Practice, Part 2

Read on to see more

(more…)

Shadowed view using a rectangular shadowPath

I recently had to improve the performance of a few views that utilized CALayer-based shadows on rounded-rect UIView objects. On this particular iPad application, when the device was rotated, the views rotated quite a lot slower than we would have hoped. It wasn’t a show-stopper, but the jerky rotation animation made it look cheap and unpolished. The easiest way to have our cake, and eat it too, was to set a custom CGPath to the layer’s shadowPath property. This told UIKit to set the inside of the path to opaque, reducing the amount of work the rendering engine needed to perform.

// Add background tile
UIImage *bgImage = [UIImage imageNamed:@"embedded_bg.png"];
self.view.backgroundColor = [UIColor colorWithPatternImage:bgImage];
// Add the reference view
UIImage *image = [UIImage imageNamed:@"dccp.jpeg"];
UIImageView *imgView = [[UIImageView alloc] initWithImage:image];
[self.view addSubview:imgView];
imgView.center = self.view.center;
imgView.layer.shadowColor = [UIColor blackColor].CGColor;
imgView.layer.shadowOpacity = 0.7f;
imgView.layer.shadowOffset = CGSizeMake(10.0f, 10.0f);
imgView.layer.shadowRadius = 5.0f;
imgView.layer.masksToBounds = NO;
UIBezierPath *path = [UIBezierPath bezierPathWithRect:imgView.bounds];
imgView.layer.shadowPath = path.CGPath;
[imgView release];

The resulting image, as you can see above, has a shadow as you’d expect. But since we’ve declared the shape the path will have, the iPad can drastically improve its rendering performance.

Through that process however, I decided to see what sort of effects I could pull off by passing in a path other than the default rectangular bounds of the layer. Since you can create any sort of path you want, I considered the different effects I could get away with by making non-rectangular paths and using them as shadows. (more…)

For myDrumPad the main pad buttons are images. I create a UIButton object, and use setBackgroundImage:forState: to customize which image will be used for each state (UIControlStateNormal and UIControlStateHighlighted mainly).  I customize the title label font, shadow and color, and voilà I have a pad button that simulates the look and feel of  a Korg padKONTROL. There’s just a few small problems with it.

1. The images on the iPad are fairly large, and memory is at a premium.
2. The size of these buttons can change in portrait vs. landscape. It’s time-consuming to export different versions from Photoshop for the different orientations.
3. The buttons are sized differently depending on the size of the button grid (e.g. a 3×3 grid of buttons have larger images than 4×4 or 5×5 grids). If I resize these images on-the-fly, then the edges look blurred and aren’t well-defined.
4. The retina display complicates all of this, meaning I have to have two versions of each image.
5. I want to be able to customize the buttons to have different colors when you’re on different drum sets.

Because of that long list, simply using an image isn’t good enough. But instead of drawing my images using regular Core Graphics drawing routines, I’m going to use Core Animation Layers, or CALayers, to accomplish the same thing. Ultimately I want my buttons to be able to be animated, to change color, and to feel more “alive” than a static image could accomplish. (more…)

One of the things that’s hard as a developer is keeping your legacy code up to date.  It’s all too easy to fire-and-forget; write your code, debug it just enough so that it compiles, and then forget it until it breaks again.  I’m guilty of that as well.  In fact, just today I discovered that my continuous deployment configuration for Boomle was broken…for the past 3 months.

After merging my code from a private repo over to Github, it still didn’t work.  After updating the Hudson build configuration to point at the proper repos and to respond to the proper webhooks (to get automatically triggered on a new check-in), it STILL didn’t work.  You see, not only does configuration change, but SDKs and APIs shift out from under you.  The iOS SDK had changed out from under my project, and the Xcode configuration was pointing at libraries and SDKs that no longer were shipped by Apple.

The lesson for me here is this: I need to get off my ass every few weeks to at least look at my source code.  Kick the tires a little, hit a build every now and then, and check that everything is still okay.  Because the longer you wait, the more things can fall apart.  Each one of those issues I mentioned above would have been simple to fix, had I addressed them right away.  But the more problems that build up, the more difficult it is to clean up your code.

As it is, I still need to integrate Game Center with Boomle, and refactor its drawing routines to be more efficient.

Now, I don’t believe in New Year’s resolutions.  Instead, I believe in making resolutions whenever they’re relevant, and sticking to them without the excuse of a New Year to motivate you.  My resolution is to take care of my projects proactively, instead of forgetting them.  Treat it like the quasi-living thing that I’m anthropomorphizing it to be, because even inactive projects need love too.