iPhone Programming Tutor

Developers, developers, developers, developers...

2009-01-21T12:28:00.002-06:00

It seems like the seminar I went to yesterday was fairly far below my level. The man presenting did a very nice job but it was all stuff I was doing almost a year ago, now...

He showed how to use Dashcode to make webapps and he showed XCode and some cool things with native apps. Unfortunately, the rest of the room wasn't necessarily right for this presentation, either. There were questions directed towards him like "How can we use flash?" or "I know python, how can I use that to create an iPhone app?"

Hopefully that session doesn't turn into 20 more people creating a 99 cent flashlight or tip calculator.

I'll try to be on to post more about whatever topics come to mind, but for now, everyone should check out this game called "Blackout" It's only 99 cents and it's a highly addictive puzzle game. Here's the link.

It's been a while

2009-01-20T12:31:00.002-06:00

Hello again everyone.

Sorry it's been a while since I last posted, but recently I've been moving back to school, starting classes, working on a fairly large update to one of my apps, talking to a company about possible contract work for the iPhone, and trying to find some free time in there is not as easy as you might think. :)

Anyway, I'm going to be working on a few things here for the next couple hours, and then I will be attending a session here at my university on iPhone Development. I'll be sure to pass along anything that seems helpful or lesser-known. Hopefully they cover at least one or two areas I might not know as much about. We'll see just how much they can cover in 2.5 hours...

If you would like to see any topics covered, leave a comment or shoot me an email (buschmaster@gmail.com works just fine)

Another resource

2008-12-31T11:01:00.002-06:00

I'd like to make sure everyone knows about another blog that's out there doing things similar to this one. It is located at: uchidacoonga.com. Any developer should read as many blogs like this as possible, if nothing else it can be a helpful reminder and you may learn some things about the areas you aren't quite as experience in.

Don't forget about the blog we mentioned a couple days ago either: iPhone Development.

Also, hopefully you're using Safari or Firefox if you're browsing this blog, so feel free to subscribe to our RSS so you know when we post updates!

Interface Builder 101: An Overview

2008-12-30T21:25:00.007-06:00

Interface Builder can be a valuable tool in any developers toolbox when used properly. It can make creating complex user interfaces as easy as a drag and drop, instead of many lines of code. In this tutorial we will create a simple application using Interface Builder that has a button and a label, when the button is touched text will be displayed in the label.

The first thing we will do is create a new Window based application in Xcode, lets call it "IBPractice." In the project window double click MainWindow.xib to open it with Interface Builder. From the Library drag a UIButton and a UILabel into your Window.

We should probably resize the label to make sure our text shows without being truncated. To do this click on the label to show its borders, which are represented with a series of points, and drag them to make the label larger. Move to the Inspector to set the alignment of the label to center and to have no text. This is what we want our Inspector to look like:

Now double-click on the button and set its title to “Show Text” by simply typing it in and pressing enter.

Now click somewhere in the view that is not the label or button. Now in the Inspector click the “i” button.

Under “Class Identity” in the text box enter MainView. This will later become a class file. Under “Class Actions” click the “+” and make a new action, call it “showText.” Then under “Class Outlets” click the “+” to add two outlets. Outlets are what lets xcode and interface builder know what objects we are talking about. Name the first outlet “theButton” with a type of “UIButton” and the second type “theLabel” with a type of “UILabel.” We should have the following now:

Now we must move to the Connections tab in the Inspector window.

Here is where we will tell Interface Builder what outlet is connected to what object. Click and drag the circle to the right of “theLabel” into our UILabel in the view window. This tells Interface Builder that anytime we call “theLabel” in our code that we want to do things to that UILabel. Now click and drag the circle to the right of “showText” into our button. This will bring up a menu of options, we want to select “Touch Down.” Each of these options require a different touch to initiate the action. Touch Down says that as soon as the object is touched to fire the action associated with it, in this case, that action is “showText.” Now we have one last thing to do in Interface Builder before heading back to Xcode.

Select File -> Write Class Files. Be sure to have “Create '.h' file” checked, then save. Then click the check box next to IBPractice and select Add.

It is now time to return to Xcode. In Xcode open MainView.h and replace your @interface line with

@interface MainView : UIView {

This tells Xcode that MainView is a subclass of UIView.

Now move to the MainView.m file. Within the brackets of – (IBAction)showText is where we will create our code to make things work. We will tell our program to display “Hello World” within our label. To do this add the following line of code:

theLabel.text = @"Hello World";

And that is all! We have created a very basic interface using Interface Builder. Using what you learned here you should be able to make much more complex interfaces.

The source code for this tutorial can be downloaded here.

UITableView Part III

2008-12-29T23:58:00.004-06:00

We may take a break after this look at the UITableView and how to drill-down, but with these three sections on UITableViews down you should have a very strong understanding of how the UITableView Controller works. So we will open up our code from the last part again and get right into it.

This section will cover how to drill-down. There are three main things to understand when learning to drill down.

-Handling which row was touched

-Setting something to be an identifier in the next level so we know which one was selected there as well

-Pushing that view onto the stack

The first thing we will have to do is create a new UITableViewController class, so select File -> New and grab a UITableViewController. I named mine "SecondLevelController." In the .h of the new file we will add a property of an NSString. This will be:

NSString *myTitle;

And:

@property (copy, readwrite) NSString *myTitle;

Just as we have in the past. Also, make sure to synthesize it!

@synthesize myTitle;

Beyond that all we will do for now is make sure viewDidLoad holds:

self.title = myTitle;

That's all for now, since this is just a simple example of this. We'll go back into the RootViewController class. Remember to add this up by the other imports:

#import "SecondLevelController.h"

Now, we'll handle the selection of the row. Remember from before? There was this class for us:

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath

Well, we'll be using this to handle the selection, so we can add a few lines of basic code. Here's how I have mine setup:

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {

[tableView deselectRowAtIndexPath:indexPath animated:YES];

SecondLevelController *anotherViewController = [[SecondLevelController alloc] initWithStyle:UITableViewStylePlain];

anotherViewController.myTitle = [tableView cellForRowAtIndexPath:indexPath].text;

[self.navigationController pushViewController:anotherViewController animated:YES];

[anotherViewController release];

}

What is being done here is the same row is being deselected as before. This doesn't cancel the selection, or anything, all it does is drops the blue color on the background of the cell.

Then it creates the next view controller, and sets its myTitle property. The reason I did this was to show an example of how we can use indexPath and a property to make sure the next level of our drill down has the unique attribute it needs. Then we push the view controller onto the stack. When you run this you'll see it's how we want it. The title is set with whatever you select in the list.

Here's the source code of up until this part: Download Source Code for UITableView Part III

While I won't go too far into depth I can explain briefly another practical use of this. One method I have used is to keep my entire drill-down navigation in an NSArray.

If I were to have an organization of something such as the NFL we might have something like:

-Divisions

--Teams

---Players

What I would do is have the NSArray hold the divisions which would be stored as an NSDictionary each.

The NSDictionary would have fields such as "Name" (String), "Teams" (Array of type NSDictionary), and "Conference" (String)

The "Teams" are the next level of navigation, which would have the fields such as "Name" (String) and "Players" (Array of type NSDictionary)

This may be difficult to understand with only words, but through the use of the ideas from above you could definitely create a drill-down of your own with your needed implementation.

UITableView Part II

2008-12-29T22:12:00.006-06:00

Let's keep the ball rolling on that UITableView.

Before I get started... I'm going to assume you understand all the points from the first part, or you are using the same code to follow along this time. If you need to, post a comment and I'll be glad to help you with any specific areas in the first part of the UITableView stuff we will be covering.

This one will cover the editing modes of our UITableView.

Luckily for us, Apple has once again made this very easy on us. You will notice near the top of our RootViewController commented out we have a viewDidLoad class. We can get rid of that comment because we want to use it now. Also, remove the comment before the last line of it so we have our editing button. We can also add a title here. A title should always be used in our UITableView so people know what they're looking at. It's very easy and quick to add, so we hardly have any excuses. We can simply add this:

self.title = @"Table Testing!";

So what we have for that section is:

- (void)viewDidLoad {

[super viewDidLoad];

self.title = @"Table Testing!";

// Uncomment the following line to display an Edit button in the navigation bar for this view controller.

self.navigationItem.rightBarButtonItem = self.editButtonItem;

}

Already we should be seemingly close to our desired effect. Visually it would seem so if you choose to run it now. I ran it in the simulator and it looks like this:

Even though visually it would seem as though we are very close to our goal, that wouldn't happen to be the case just yet as we have almost all of our programming yet to do. For now, we'll hop back to the app delegate so we can create a couple support methods. We'll need to be able to remove items as well as move items to fully show the UITableView editing experience. So that will basically require two methods. I'll call them removeFromList and moveFromOriginal: toNew:. So in the TableViewPraticeAppDelegate.h they will be:

-(void) removeFromList:(NSInteger)index;

-(void) moveFromOriginal:(NSInteger)indexOriginal toNew:(NSInteger)indexNew;

And these can be added before or after the -(void) createArray; Order doesn't matter in these cases.

Here is my implementation for the removal from the list:

-(void) removeFromList:(NSInteger)index {

   NSMutableArray *tempArray = [[NSMutableArray alloc] initWithArray:theArray];

   [tempArray removeObjectAtIndex:index];

     theArray = tempArray;

}

This can be done a great number of ways, but I decided to go with this route. Another fairly simple option would be making theArray an NSMutableArray for ease of use, but I like using an NSArray when possible. What I am doing is creating a new array with the same objects and then removing the object we no longer need from that list and resetting our "theArray" as the correct array.

My implementation for the moving items on the list is very similar:

-(void) moveFromOriginal:(NSInteger)indexOriginal toNew:(NSInteger)indexNew {

   NSMutableArray *tempArray = [[NSMutableArray alloc] initWithArray:theArray];

   id tempObject = [tempArray objectAtIndex:indexOriginal];

   [tempArray removeObjectAtIndex:indexOriginal];

   [tempArray insertObject:tempObject atIndex:indexNew];

   theArray = tempArray;

}

This will grab the temporary object (i.e. the object which is moving) so we can remove it from the list and then add it back in where we now want it.

That will handle that end of things, so now we just need to edit two methods that already exist in the RootViewController. Towards the bottom you will see commented out:

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath

Get rid of those comments, and we can use some pre-existing code along with simply calling our methods we just created. Our end result will be this:

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath {

TableViewPracticeAppDelegate *appDelegate = [[UIApplication sharedApplication] delegate];

if (editingStyle == UITableViewCellEditingStyleDelete) {

// Delete the row from the data source

[appDelegate removeFromList:indexPath.row];

[tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:YES];

}

else if (editingStyle == UITableViewCellEditingStyleInsert) {

// Create a new instance of the appropriate class, insert it into the array, and add a new row to the table view

}

}

As you can see I have once again called the appDelegate and will be using that to call the removeFromList we just created. Make sure you add the .row after indexPath, otherwise your program will crash and burn like a Zeppelin filled with a highly flammable gas.

We can use a similar approach for moving, once again, here is my class once the comments were removed for that as well:

- (void)tableView:(UITableView *)tableView moveRowAtIndexPath:(NSIndexPath *)fromIndexPath toIndexPath:(NSIndexPath *)toIndexPath {

TableViewPracticeAppDelegate *appDelegate = [[UIApplication sharedApplication] delegate];

[appDelegate moveFromOriginal:fromIndexPath.row toNew:toIndexPath.row];

}

So this one will once again use the indexPath.row idea to pass along the actual row number we are in. With both of these methods created the only thing left to do is make sure to remove the comments surrounding:

- (BOOL)tableView:(UITableView *)tableView canMoveRowAtIndexPath:(NSIndexPath *)indexPath

We want all areas to be movable, so we will leave this at straight forward return YES;

Since it's boring to be playing with two rows, I went back and added a bit more to my NSArray I was creating. I made it originally have the objects "Hello", "World", "How", "You?", "Are" and then moved it around to create the sentence I wanted and then removed world to create a simple "Hello How Are You?" sentence. This will give you a much better feeling of playing around with an editable UITableView.

Your editable UITableView should function just fine, no matter what you throw at it. But what you may notice is if you close the application and then launch it again later, the list will be as it was originally. You may not want this to happen, so as I introduced the App Delegate and its purposes and a possible use in the last section, I will introduce NSUserDefaults in this one.

NSUserDefaults can store information for your application beyond just when it is open. So while the app delegate was very useful when dealing with information what was currently running, we can use NSUserDefaults to keep that information safe while we're not running the application.

Note: There are many other methods in storing information, this is only one and you should not live and die by only one method of storing information.

We can do all of these changes within the delegate's .m file. First off, we need to store the information when the application is closing. Find:

- (void)applicationWillTerminate:(UIApplication *)application

Inside of this we can put things we want to happen if the user closes the application. So naturally this would be the easiest way to store the information each time we're done editing our list. We do that by first calling the NSUserDefaults, which is again very easy:

NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];

This will get the NSUserDefaults for us and what's important to know is that this works similar to an NSDictionary, not an NSArray. So we can set things as values for keys, rather than putting in an object at an index. So we can store the array as "lastArray" by putting in:

[defaults setObject:theArray forKey:@"lastArray"];

Seems simple enough, now we just need to check for it when our application is launched. So let's replace this snippet from the applicationDidFinishLaunching:

// Create the array

[self createArray];

With this new section:

NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];

if([[defaults objectForKey:@"lastArray"] count] > 0) {

// We already have an array, let's use it

theArray = [defaults objectForKey:@"lastArray"];

} else {

// Create the array

[self createArray];

}

This seems to be an elegant way to check, that way, if the user has either launched this for the first time or if they have deleted everything, it will create the array, otherwise it will use the latest array before the application was closed.

Here's the source code once again: Download UITableView Part II Source Code

Enjoy!

More on the app delegate

2008-12-29T21:33:00.003-06:00

In the last post I made where I discussed the UITableView I touched very briefly on the app delegate and how we can use that to access information we may want available to many different classes.

Basically, what we can do by using the code snippet to get the delegate is easily access information from wherever we are. This is incredibly helpful for things like drill-downs. To me, the main advantages of this approach are that you don't have to be passing information from class to class every time, and you can access the same information from all over your application very easily.

The way you can do this is actually fairly simple. Firstly, import your app delegate's .h. In our last example this was as simple as:

#import "TableViewPracticeAppDelegate.h"

And then one simple line and we're there! Where you want to use this be sure to put this line of code:

TableViewPracticeAppDelegate *appDelegate = [[UIApplication sharedApplication] delegate];

This is again assuming the last post's project/file names, but I assume everyone could easily modify this code to meet their own needs. Since theArray was setup as a property in the app delegate, we were able to call it no problem. If we wanted to get an object called "someItem" all we would need would be

[appDelegate someItem];

Hopefully this clears up any confusion in case anyone was struggling with that particular section of the UITableView Part I.

A UITableView Primer

2008-12-29T12:22:00.006-06:00

Many people struggle with the UITableView so we'll start off with the basics here. I'll cover the basics in this tutorial and in future tutorials try and build on that.

How I think of the UITableView is that I have an array, and it uses that arrays attributes to display my information in a very nice way. So the first thing that should be done should be to create a "Navigation Based Application" in XCode, I'll call mine "TableViewPractice." We see two classes: the delegate, and the RootViewController. In short, what is happening is that the delegate is making sure that the view is created and shown by the RootViewController.

First let's add a couple things in the app delegate's header file. We'll add a property for an NSArray -- So everything after your imports and opening comments becomes this:

@interface TableViewPracticeAppDelegate : NSObject {

UIWindow *window;

UINavigationController *navigationController;

NSArray *theArray;

}

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

@property (nonatomic, retain) IBOutlet UINavigationController *navigationController;

@property (nonatomic, retain) NSArray *theArray;

-(void) createArray;

@end

Now we have the .h file ready, so let's jump into the .m file. First off, we need to synthesize the array, so do that by adding this after the @implementation line:

@synthesize theArray;

I typically create another class in the delegate to create the array of information which needs to be displayed using my UITableView. I've called mine createArray as you can see above, and it can be void for my particular implementation. We'll keep it simple, something like this:

- (void)createArray {

NSArray *myArray = [[NSArray alloc] initWithObjects:@"Hello", @"World", nil];

theArray = myArray;

}

The delegate looks good, let's move onto the UITableView class (RootViewController)

Now, each method in this will be called automatically, so no need to link anything up per se, because a UITableView class is ready to run with these methods. I'll try and explain each one briefly before showing how we will implement it, they are fairly self explanatory but make sure you understand them and use them properly.

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

Return the number of sections in a tableview, since our array is very basic, we can simply return 1.

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section

This can be used to specify how many rows are in each section, since our UITableView only has one section, we can use this fairly easily as well.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

This still remains fairly simple in a basic implementation, but can be used to change the appearance of the given row in the UITableView. This also exposes us for the first time to "indexPath." Don't be intimidated by this, this can be used greatly to our advantage.

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath

This can be used to handle if a row is touched. You can choose to implement this or not. In this basic example we will only use this is a very simple form.

There are a few more methods that go into editing a UITableView, but since we aren't going to be implementing that we'll cover it at the time in which it seems more relevant.

Let's get down to the actual implementation inside the UITableView!

Like I mentioned earlier, this is basically all structured around the array and its traits. Knowing that the implementation should be fairly simple. To do this I will use the app delegate to give us the array. We can do that by using this line of code:

TableViewPracticeAppDelegate *appDelegate = [[UIApplication sharedApplication] delegate];

This is a powerful line of code, and will make it so the number of rows can easily be expressed:

return [[appDelegate theArray] count];

So that whole section will become:

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {

TableViewPracticeAppDelegate *appDelegate = [[UIApplication sharedApplication] delegate];

return [[appDelegate theArray] count];

}

Pretty simple, right? With only one section this becomes easy, because we know we can return the count and it will work. For multiple sectioned tables, we would want to create a switch, but this is clearly not needed in our implementation.

For the cellForRowAtIndexPath method we can use the app delegate again. Under the comment that already exists that reads "// Setup the cell" we can put:

TableViewPracticeAppDelegate *appDelegate = [[UIApplication sharedApplication] delegate];

cell.text = [[appDelegate theArray] objectAtIndex:indexPath.row];

That whole section (For copy and paste purposes) should now read:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {



static NSString *CellIdentifier = @"Cell";



UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];

if (cell == nil) {

cell = [[[UITableViewCell alloc] initWithFrame:CGRectZero reuseIdentifier:CellIdentifier] autorelease];

}



// Set up the cell...

TableViewPracticeAppDelegate *appDelegate = [[UIApplication sharedApplication] delegate];

cell.text = [[appDelegate theArray] objectAtIndex:indexPath.row];

return cell;

}

Now this should look how we want it, try and run it!

I mentioned earlier that we would only go into the basics of the didSelectRowAtIndexPath. So if we peak at that we can change it to:

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath*)indexPath {
  // Navigation logic may go here. Create and push another view controller.
  // AnotherViewController *anotherViewController = [[AnotherViewController alloc] initWithNibName:@"AnotherView" bundle:nil];
   // [self.navigationController pushViewController:anotherViewController];
   // [anotherViewController release];
   [tableView deselectRowAtIndexPath:indexPath animated:YES];
}

I left Apple's little comments in there because it will make sense when we try to implement it later. All this will do will deselect the row that was selected, so you will see it selected for a second, then deselect itself with some nice fading animation. Since this is only one level deep this is basically all it will need.

To sum up what is happening in a basic way:

-The UITableView is calling all of those methods automatically

-We're using the indexPath to find out where we are at that particular moment

-We're setting the text of each row using indexPath.row.

In the next posts I'll be sure to cover editing, more on selecting, and other stuff we can do with UITableViews.

Here's the source of this tutorial: Download Tutorial Source Code

A few things that are already available...

2008-12-29T12:08:00.003-06:00

There are quite a few things that are already available to us as iPhone Developers. Some of these things could end up saving us an awful lot of time. If anyone has any ideas as to things that could be added to this list, let me know!

Cocos2d iPhone - This is a framework for building 2d games based around OpenGL ES 1.1

Sio2 Project - This is an open source engine built for 3d games and is also based around OpenGL ES 1.1

Chipmunk Physics - A complete physics suite, it is built into Cocos2d, but can also be used outside of Cocos2d as well

Unity3d - I've never had any personal experience with this, but everyone I've heard from who has has loved it. They have a free trial, but the full program is quite expensive (at least for me!)

You might have noticed that each of these seems to be geared towards game creators. I can see two likely reasons for this. The first would be that games seem to be doing very well in the App Store and many people would love to get involved with them. The second would be that games can be one of the most difficult areas in programming and these can be used to simplify the process and reduce redundant programming.

You may not find these tools useful for yourself, but I have experimented some with each of the top 3 and can see the merit for any of them. I will probably not cover much on these tools beyond this post, but felt that iPhone developers may want to know about them.

Welcome!!

2008-12-29T12:04:00.003-06:00

Hi everyone,

I've created this blog to help people who are developing for the iPhone and iPod Touch. Everyone should check out the iPhone Development blog as well as it is very well written and has been incredibly helpful. It is located here: iPhone Development. I'm fairly open as to what topics I may be covering. I'll try to cover each topic well rather than covering random little tidbits - but the first few days may seem like just that. If you have any suggestions for future topics, or any ideas for the blog you would like to share leave a comment and I'll be happy to try and help or look over what ideas you might have.

Hope I can help, happy reading!