Archive for February, 2011

Bang head here

Sunday, February 20th, 2011

So I’ve gotten pretty good with basic iPhone programming.  Or at least, good enough to pass as semi-qualified.  I’ve managed to get an app in the App Store and it’s selling about a copy a day so far – not a huge amount of income, but probably a lunch or two a month.  I’m fairly happy with that, since this is the first app I’ve done specifically for myself, from my own idea.  I’m working on another one now that I’m hoping will have a slightly broader appeal, but I’m still not expecting it to go gangbusters.  I am, however, earning a few more things about programming that I didn’t necessarily expect to – and thanks to Admiral Frijole (yes, that is a nickname), learning a lot more than I expected to about interface design.  See, he’s able to think like Apple (though he’ll tell you it’s thinking like a user of the iPhone, not like Apple), and has pointed me in a few different directions to make the interface not just better, but completely different from anything I would have thought of on my own.

The hardest part now is figuring out how to go from sketches / mockups to the code – I’ve got a few ideas, I just need to see which one(s) work.

In the meantime, I promised a practical demonstration of doing things in code as opposed to in Interface Builder (IB), so let’s look at how I built the initial tab environment for the app that’s selling now.  First, I start with the fact that I need a TabBarController in order to make the tabs at the bottom easily, so I make the header file for the AppDelegate look like this:

#import <UIKit/UIKit.h>

@interface Brewinator_Pint101AppDelegate : NSObject  {
     UIWindow *window;
     UITabBarController *tabBarController;
}

@property (nonatomic, retain) IBOutlet UIWindow *window;
@property (nonatomic, retain) IBOutlet UITabBarController *tabBarController;

@end

Now that we have the basic TabBarController defined, we simply need to built it out. I’ll be straightforward and tell you now that I’ve left some of the actual code out of this sample code that have no bearing on the interface, so the code you see will get you a pretty interface but not much else. In the applicationDidFinishLaunchingWithOptions() function in the AppDelegate.m file, I added the following code:

    UINavigationController *localNavController;

    tabBarController = [[UITabBarController alloc] init];
    NSMutableArray *localControllers = [[NSMutableArray alloc] initWithCapacity:2];

    TypeViewController *typeViewController;
    typeViewController = [[TypeViewController alloc] initWithTabBar];
    localNavController = [[UINavigationController alloc] initWithRootViewController:typeViewController];
    [localControllers addObject:localNavController];
    [localNavController release];
    [typeViewController release];

    NameViewController *nameViewController;
    nameViewController = [[NameViewController alloc] initWithTabBar];
    localNavController = [[UINavigationController alloc] initWithRootViewController:nameViewController];
    [localControllers addObject:localNavController];
    [localNavController release];
    [nameViewController release];

    tabBarController.viewControllers = localControllers;

    [localControllers release];
    // Add the tab bar controller's view to the window and display.
    [self.window addSubview:tabBarController.view];
    [self.window makeKeyAndVisible];

A few things to point out here. The TypeViewController and NameViewController classes are defined elsewhere; the header files for those classes need to be #imported in the AppDelegate’s .h or .m file appropriately. The initWithTabBar() routine called on each of them also needs to be defined and implemented properly inside each ViewController’s .h and .m file respectively.  If you want more than two tabs, you will need to initialize the localControllers array with the appropriate capacity and then repeat each ViewController “stanza” once per desired tab.

Once those are taken care of, you should be able to build and run the code in the simulator, and it will give you an interface with two tabs at the bottom that you can switch between.  Until you define the interface in each ViewController’s loadView() function, they won’t really look like much, but that’s a post for another day.

For now, enjoy your tabbing display!

Learning the iPhone way

Tuesday, February 8th, 2011

So in my update of a few days ago, I promised some information about iPhone programming.  Some of this will apply to everyone, some of it will only apply to certain people, and some of it may very well be unique to me.  So, without further ado, let’s open the ball on this series of “mini-lessons” – I can’t quite call them tutorials, but they’re awfully close and may serve as tutorials for some.

This first post won’t really cover any programming, it will cover more of the mindset I found I had to be in to be successful at programming for the iPhone.  The biggest thing I had to learn was how to forget.

That’s right – I had to learn how to forget.

Seems a bit of a paradox, huh?  Well, let me explain.  As a systems administrator, a role I’ve had across 6 jobs and over 13 years, I have to know a moderate amount about a whole lot of things.  I have to know shell scripting, Python scripting, Perl, a bit of C, some C++, a dash of Java (the programming language, not the caffeinated beverage), and a few other things I’ve thankfully managed to forget.  The hardest part of all that is sorting out what environment / language you’re in and using only that language for whatever task you’re undertaking.  When I’m working on a Python script to make my life easier, for example, it’s far more difficult to switch to helping a programmer with a Perl question than it is to start helping a coworker who’s mouse has just started acting wonky.

When I first looked at iPhone programming, I thought to myself, “Oh, Objective C – I can handle that, I know C, it shouldn’t be too hard to translate.”  Just because it has the same last letter, C, doesn’t mean they are at all similar.  The syntax is, at a very high level, somewhat akin to C or C++, but getting anywhere close to the code you find there are more similarities between C and Java than C and Objective C – and it’s even more different from C++ than from C.

Enough with the alphabet soup, you’re saying?  Okay, enough with that.  Put in to plain English, the experience was for me a lot like assuming I could speak French with a reasonable degree of accuracy although perhaps not a collegiate conversational level just because I already knew Spanish.  I really don’t know Spanish, actually – I barely passed Spanish 4 in college, and that only by the kindness of Fate and my instructor taking pity on my poor non-existent language skills.  But I digress. The point here is that I had to get to the point where I realized all of my assumptions about the language, and my expertise therein, were wrong.  That took quite a bit of banging my head against virtual walls, let me tell you.

See, I actually have another app I’ve written, as a contractor, called Successful Roads.  It’s a commercial app designed for assisting construction contractors with raw material amounts needed for road construction projects.  If you’re curious, you can look up the website at http://www.roadformulas.com/. That app was, once I go my head wrapped around Interface Builder (IB), fairly simple to build.

That relative simplicity is what led to my later downfall.  I was thinking I could handle myself since I knew a similar-sounding language, and I’d already done one app.  Boy was I wrong. The first thing I had to realize was that IB was actually hindering my understanding of what was going on underneath the covers. I was hiding code implementation details from myself – hiding details from consumers is okay, hiding them from yourself, not so much. Then I had to realize that in Objective C, things are truly objects, not just fancy bits dressed up as objects. The convention for making “function calls” was sufficiently different that it took me almost two full weeks just to fully absorb it.

After the fact, it seems so incredibly intuitive that things work the way they do, but while I was slogging through, it wasn’t at all.  The biggest lesson I can give you from this experience is a simple one – forget everything you think you ever knew about programming and get a good intro book to iPhone development.  There are several out there; I’ve picked up three or four of them over time.  I’m not going to mention them specifically as I don’t want to be seen as endorsing any one over another, but if you’re curious and wish to contact me privately please feel free to do so.  Once you’ve managed to “forget” everything you ever knew about other languages, any programming experience you’ve had previously should stand you in good stead as you learn what I’ll call “the iPhone way” and begin your journey as an iPhone developer.

Back in the game

Thursday, February 3rd, 2011

The programming game, that is.  I just finished my first “real” iPhone / iPod app and submitted it to the App Store for review.  Yes, I am an iPhone programmer now.  Well, for certain values of “programmer” anyway – this first app is fairly lightweight.  As soon as it gets approved, I’ll link to it in another post, along with the web site, twitter feed, and perhaps a Facebook page.  I’m also going to post some tidbits about what I learned in building this app for anyone interested in iPhone programming.