iOS Development Code Kitchen

December 6, 2010 · Posted in advice, code, iphone, projects, work · Comment 

I’ll be putting on a workshop on iOS and iPhone development this Saturday from 9AM to 5PM on the Virginia Tech campus. The event is free so if you’re in the area feel free to sign up:

http://www.ltzllc.com/2010/11/ios-development-code-kitchen/

The event will run all day and will be hands-on programming, but all levels of experience are welcome and encouraged to come.

Building a Game

July 9, 2010 · Posted in code, iphone, projects · Comment 

A lot of my peers went to school to become game developers. Instead, most went on to work for big software companies in northern Virginia. I studied human-computer interaction and wanted to fix everything from poorly designed user interfaces to frustratingly complex household items. Instead, I became a Mac, iPhone, Flash and game developer. In a way, we both went where the money was.

How to start your game

I’ll assume you already have a game idea. No matter how ambitious you want to be though, think in milestones

  1. Display some graphics.
  2. Animate your graphics, either manually, or with basic input controls
  3. Get hit detection working.
  4. Everything else! (level loading, artificial intelligence, etc.)

If you can even make it to the fourth milestone, you’re farther than 90% of most game developers. If you make it past milestone four, you’re farther than 99% of game developers. Only the passionate, motivated and able ship. This is how I’ve started all of my games and it’s important to achieve tangible results to keep yourself motivated. In fact, this same step-by-step process can be used in regular application development as well.

Design

Start your development with a skeleton application. This does one of two things: first, it forces you to plan the architecture of your application by creating the objects (in files) that you’ll need in your development and second, it provides an outline for you to work from. So first, think about what display controllers and object controllers you’ll need, what model objects you’ll need and then go ahead and create the files for those. Also go ahead and fill in some functions too for the basic functionality. The point is, make sure you break up the functionality into bite size chunks. It’ll make your life easier, trust me.

Put in the functions you think you’ll want and then just put in print or trace statements to make sure they’re being called correctly. Then, just build it piece by piece, usually starting with getting something like a player character on the screen (DisplayController, PlayerController, GameController), then getting him to move, moving him via inputs (InputController), then applying constraints like hit detection or getting him to jump (implementing basic gravity), etc, etc. Just keep introducing and implementing new features, one at a time, playing the game, realizing you want to tweak something and playing it some more. This is called iterative design.

Get those milestones done as quickly as possible, keeping your code organized in your skeleton application. Don’t worry about graphics at first. Personally, I stick in multi-colored boxes instead spending a lot of time on graphics I may not use in the end. Objects will be added as you realize you need them, but the idea is to keep it organized, simple and cohesive.

When designing your class structures and diagrams, keep the low level functionality, like file access and keyboard inputs, abstracted and hidden in wrapper classes. The reason you abstract objects is for a couple of reasons: One is to be able to add in hooks before and after a part of code. For example, instead of calling the system clock directly, you want to calculate the elapsed time if your game was paused or suspended on the computer. If you abstracted this in the beginning with a GameClock object, you’d only have to change it once, in a single place. If you called it directly, you’d have to go back to every place in your code and calculate that value. Keep object responsibilities where they belong!

Start Programming!

To start you off, check out a game template designed for the Corona SDK (free 30 day trial), written in Lua. I recommend you create a template of all your project tyes as it’ll help jump start your next big idea and also keep you organized from the start.

Naming Conventions – Why Your Code Sucks

July 1, 2010 · Posted in advice, code, projects · 5 Comments 

I’ve seen a lot of poorly written and ugly looking code in my time. That’s not even considering the undocumented and uncommented code. We all know we should comment our code but how many of us do it consistently? I admit, when I’m in a coding frenzy, stopping to write comments just gets in the way of my thought process and can be distracting. I will however write a bunch of comments before I write the code, of the operations I think I need, in order to give me an outline of where I need to get to. For example:

// Get URL string for video file
// Load video file from URL request
// Load video file into video player
// Set up video player
// Play video

I may not know all the APIs to load and play the video just yet, but at least I’ve given myself an outline and as I fill in the code below each comment, I can see exactly what I’m doing and where I need to go.

Why Your Code Sucks

The point of this article is not to talk about comments, but how to avoid writing them in the first place within your functions and still be clear for everyone else, for the most part. This is your code:

newPlPt = crt2pl( nmc.x, nmc.y );

Not even a comment could concisely convey the meaning of that hideous statement. Instead, why not:
newPolarPoint = cartesianToPolar( newMediaContext.x, newMediaContext.y );

Well written code is self documenting. Let me restate that: if you can write code so that someone can jump to any point of that code and understand what’s going on at that point, read it like a sentence, and not have to decipher minute details like what each variable means, then you don’t have to comment most of your code.

There’s no reason you need to shorten the names in your code. Most programmers have never had file size limitations to deal with, so there’s no reason for it. Stop pretending you live in the 1960s and embrace nearly infinite file storage. To save keystrokes perhaps? Please, use a real IDE with code completion and stop doing stupid things like:

public function updateP( p:Player, d:MovieClip, b:MovieClip, t:Textfield);

Function Names

Also, because your functions are essentially actions, they need to reflect that in the name, so put a verb in the beginning of your function such as: getData(), setStatus(), enableWiFi(), hideControls(), handleGraphicException(), launchBall(), etc.

Class Variables

Get rid of the underscores in front of your class variables. For example: _dg; _myNumber;. All class variables should be private anyway, so why do you need that ridiculous convention? It’s a hold over from C where there was no “private” keyword, so you’re using it and you have no idea why.

Also, what’s with the “my” naming convention? You sound stupid when you have those: myInstanceName, myMovieClip, myGraphicsContext. Of course it’s yours, whose would it be, if not yours? If you’re programming with a colleague, do you refer to his variable references as yourInstanceName? Or hisVideoFileURL? Of course not. Don’t be that stupid; you’re reading too many stupid online tutorials by uncreative people who only code because they have nothing else better to do while living in their parent’s basement.

In the very least, be consistent with your naming conventions.

Hungarian vs. Polish notation

Depending on which language you’re coding in,  you may need to use a notation to help you with type casting. Let me rephrase that: if you’re using a loosely typed language, use Hungarian notation. You should probably use this with strongly typed languages anyway because with abstract types, you never know what you could get into and it’s just generally less confusing.

Hungarian Notation: vendorNameTextField or vendorName_txt

Polish Notation: txtVendorName or textFieldVendorName

Why not Polish notation? Not only is it ugly, but why would I sort on variable type instead of the variable name like I can do in Hungarian notation? The notation names come from how the speakers of those languages modify their verbs and nouns. To say: “My ball” in Hungarian is:  “labdám” where “labda” is the root word and the ‘m’ singifies a first person possessive. Hence the ending of the word shows the crucial information. It’s the opposite in Polish notation where the beginning of the word is modified. In the interest of full disclosure, I love the Polish, but I am Hungarian, but I promise that’s not why I prefer one over the other.

Final Thoughts

In the end, be consistent, be clear and spell out your variable and function names.

iPhone Pricing

April 10, 2010 · Posted in advice, iphone, work · Comment 

As with any product or service, the question of pricing is always one of the many challenges of selling a product or service. Many price their products or services low in an attempt to under cut their competition or initially sell a lot and get their name out there. Others charge way more than a person is willing to pay for such a product.

With iPhone development, more often than not, you’re selling a product as opposed to a service, which may be a compliment to your physical or web based service. If your iPhone app is a complimentary product to a service that you already offer and charge for, your iPhone app should probably be free (depending on complexity). Look at it as a value-added feature to put you above your competition and make using your service more convenient and enjoyable. By creating more ways to access your service, you provide more opportunity for your customers to use it more often and really benefit from what you’re trying to offer them.

So what’s the sweet spot for a price for your iPhone app? It obviously depends, but there are some guidelines we came up with.

Be Unique with Your iPhone App

The more unique your application is, the more you can sell it for. By being unique, you have less competition and thus a higher demand.

Complexity of Your iPhone App

If your application can be easily reproduced by a 16 year old kid on a weekend, you either shouldn’t charge for your application, or if you do, don’t charge more than a dollar because that 16 year old kid won’t.

Proprietary

If your application uses proprietary information, software, APIs or other technologies that aren’t easily implemented or obtained, you can charge more for your application. This relates to complexity, but be aware that people will often create equivalent systems if it’s popular enough so proprietary systems and information require a lot of maintenance to keep them relevant.

Usefulness of Your Application

How often will someone use your app? Is it just a novelty or something someone will only use for a certain chore that they rarely do? If so, the demand for the app diminishes and so should your price.

No application should be more than $10 with few exceptions. Remember that you’re developing for a mobile platform and the software is limited and your price should be limited too.

If it’s a game, how is the quality and length of game play? The quality, the game play and the fun factor all play a part in your price. Obviously, people much prefer spending money on entertainment than on a new fancy laundry list application. Games are usually unique (to the App Store at least), are complex and provide a greater satisfaction to buyers, which allows them to enjoy a higher price tag.

Perspective

Having a higher price on the App Store shows more confidence in your application. Giving your app away usually means you don’t think people would be even willing to spend the price of a soda on your application. These applications are fine, but for some of us, we need to make a living.

Making your app a dollar usually means, I want to make some money, but I don’t think people will pay any more for it. But charging a dollar can also be good if your app has a wide appeal. What you lack in big numbers, you make up with bulk sales. So, if it’s a game, you could potentially have a larger market as opposed to a utility application that the user spends 30 seconds on. So you really need to look hard at your application and keep several factors in mind before you price your app. You can always change it later, so one approach is to start low and see how sales go.

Handling Your Initial View Controllers for iPhone

January 27, 2010 · Posted in advice, code, iphone · 24 Comments 

Programming starts with a

design

A lot of webpages and articles talk about how to program, but they don’t talk about how to design a program. Good program design separates the weekend programmers from the professionals. Sure, anyone can piece together a working application but a good design allows a power and flexibility of adding new features, for example, without having to recode half of your application.

Here, we’ll talk about handling your initial views when your iPhone application loads. This might be a simple task if your application is simple, but take the case of having a welcome screen followed by a login screen followed by a tabbed view controller. You might set it up so that one activates the other upon being dismissed itself.

Here’s an example of how the process might look:

Program loads AppDelegate

Load Welcome view from AppDelegate

Dismiss Welcome view -> Tell Welcome view to load Login view

Dismiss Login view -> Tell Login view to load Tabbed view

What if you had to add a view or remove one, say if the login was no longer needed if you gave your users the option to save their credentials. You’d have to rewrite two different view controllers at least. And this is just a simple example so you can see how complicated this chain of views would get once your application grows. For most programmers this way is fine, and sadly enough most of the time, this is the way it’s done. But true programmers are lazy. Lazy programmers are good programmers. So be lazy and write good code so that when (not if) you go back and edit your code, it’ll be a snap.

A design starts on paper

Your programs should be conceived on paper. Even with applications that attempt to do this, I still find paper the ultimate programming tool (even though I did the one below on a computer).

Class Diagram

Class Diagram

First off, your controllers should be logically separated based on their tasks that they need to accomplish (not based on how the user will view them). So, you should have a controller or controllers to handle logging in and session creation and have appropriate UIViews and UIViewControllers to get and display info to your user. This may not be a one-to-one relationship though. For example, you may not have a UIViewController that’s associated with creating your sessions at all.

Next you will have your application’s business logic view controllers, controllers and all that jazz. The controllers sit independently to the view controllers except, of course, where there’s coupling or interaction. They are not tied directly, or rely upon any particular view. You illustrate those connections on paper (or in this case in the example diagram above). So if your “Add New Event” feature, let’s say, needs access to the session data, draw a line from your SessionController to your EventsController with an arrow pointing in the direction of the flow (from EventsController to SessionController in our case since the Events controller needs to know about the SessionController but not vise versa).

Abstraction solves everything

Since your controller code should be independent of how your views are laid out, you won’t have your AddNewEventViewController (the view that lets the user add an event) handling the actual creation and saving of events but will instead gathering and packaging the information taken from the user and given to an EventsController to handle the manipulation. Who knows, you may have several views that edit an Event in one way or another and if you change something in how the Event is saved, you’ll have to go into the code of each one that touches Event and rewrite code — exactly what we’re trying to avoid.

Abstracting the data in this way is called indirection and “All problems in computer science can be solved by another level of indirection;” — David Wheeler, except as Kevlin Henney says, “…except for the problem of too many layers of indirection.”

Singletons, under used

and under appreciated

So, you should have a session controller that sits somewhere ready to be called by who ever needs to validate a session or login (those views that would need access could be your tabbed views, could be your app delegate when your app starts, or could be in your settings views where you type your login info or when you log out). This is usually accomplished with a singleton class where any controller can access that one (and only) instance of your controller without having to pass around references to that controller. It not only cleans up your code, but also helps data integrity by not allowing multiple objects to edit the same data.

Handling your initial views

You should really have a separate controller handle organizing your views rather than the app delegate since the app delegate should really only be used to initialize your app and handle delegation of your application, not controlling business logic. So the structure should look like:

AppDelegate -> MainViewController -> LoginViewController

I like to have an overall MainViewController that handles all the subviews, be it a tab bar view controller, a table view controller, or whatever your main view is going to be. This level of indirection allows you to easily change what your main view controller is later, should your requirements or ideas change. Having said that, the MainViewController is going to need to get and maintain a reference to the application’s window.

To actually add the views, stack them on top of each other. Add the Tab Bar Controller’s view to the Window’s view first, then if needed, add your login views after that to stack them on top, and then remove them as needed when you’re done with them. By removing them from the top, it reveals the bottom view.

In MainViewController’s implementation file, your viewDidLoad: will look like:

[code lang=”objc”]
– (void)viewDidLoad
{
[super viewDidLoad];
[mainWindow addSubview: tabBarController.view];
[mainWindow addSubview: loginViewController.view];
[mainWindow addSubview: welcomeViewController.view];
}
[/code]

Where mainWindow is an IBOutlet to your Window in your MainWindow.xib file (or you could get it programatically if you prefer). Also, loginViewController is a pointer to your view controller that you put on top of the tab bar controller. On top of your login view, put a welcome view displaying any text, graphics or video to show after your application loads; note that this is different from your Default.png initial image. Then when you’re done with your login view, call removeFromSuperview on them to remove them from the view stack. So something like this in your MainViewController (since it handles all manipulation of your main views):

[code lang=”objc”]
– (void)removeWelcomeView
{
[welcomeViewController.view removeFromSuperview];
// Any other code you need to clean up after your welcome view is removed
}
– (void)removeLoginView
{
[loginViewController.view removeFromSuperview];
// Any other code you need to clean up after your login view is removed
}
[/code]

Obviously, when you remove the welcome screen view, under it (since you added it on the stack before the welcome view) is your login view. Then, removing the login view will show the tab bar view since that was added first in your view stack:

(Top)

Welcome View

Login View

Tab Bar View

This way we’re loading all of our views at once and stacking them so the one on top hides the one below. This has a slight overhead since you’re adding all your views when your applications starts but you can always delay adding the tab bar controller to the Window’s view until all the initial views are removed, for example. Then, if you’d like, using the MainViewController, you can add views on top of the tab bar view during execution, for example if you need to login again.

There are a few different ways to handle multiple views and each case is different. This is just one idea, with a few general guidelines. Feel free to ask any questions in the comments if anything wasn’t clear enough.

Sample Code

The following sample code is provided as is for educational and demonstration purposes. I threw it together really quickly and is only used to demonstrate the use of a MainViewController. Normally, you’ll want to make your MainViewController a singleton class, but in this example I passed the MainViewController instance to the subviews in order for them to call different methods on MainViewController to change the current views. By using a singleton design, you can avoid passing around this reference since there is only ever one MainViewController.

Also, this code demonstrates how to create a tab bar programmatically. It needs to be the root view of your window, but that doesn’t mean it needs to be the root view controller. We are still allowed to use a MainViewController as our root to handle all subviews and their controllers.

Download sample code (2010-02-11_TabBarTest.zip)