Dive Centers, iPhone apps and More

April 17, 2011 · Posted in news, personal, projects · Comment 

For those of you who follow, you always want to know what I’m up to.

Some might think I’ve spent all this time opening a dive center here in the New River Valley. In fact, I think I’ve only spent about 10% of my time doing that.

iPhone Apps

We have two that are completed and awaiting final testing. This is usually the longest part of creating any application. We haven’t had any of our live apps crash yet, and I prefer to keep it that way. So, we do a lot of testing. And when we think we’re done, we test some more.

Lab Work

One must think I’m getting my PhD in Environmental Engineering. I do have a degree from the College of Engineering (Computer Science), but Environmental? I would never have thought. But Ana is finishing up and I’m helping out. That means preparing batch reactors, measuring gas production and writing a thesis. Luckily I’m only helping in small quantities and the lab work is completely done. Now it’s just data analysis and finishing off that thesis. I guess it’s science, and we use a computer, so it’s kind of what I went to school for.

Businesses

As I mentioned, we opened a dive center in Blacksburg. But we also created a state of the art website for it that’ll allow the company to grow into something much more than a dive center. We had the awesome team from HellowYellow design us the site, and they did an amazing job. We’re working on a ton of new features to the site like class registration, videos, etc. How hard can all that be? Well it’s part of a much larger picture, so a little harder than you think.

Part of that larger picture is this: It’s not about opening a dive center and sharing our passion for scuba. It’s about taking a business, any business, and making it the best at what it does. Most dive center websites look like theirs were created in 1996, by a dude with 10 minutes of html experience while sitting on a beach, drinking coronas.

So we started something. That something has grown to include several businesses, several partnerships, several clients and a lot of change. That change will upset a lot of people, namely those on the other side. How many, will be our measure of success.

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.

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.

Corona Game Template in Lua

June 27, 2010 · Posted in code, iphone, projects · 14 Comments 

This is a template I threw together for the Corona SDK from Ansca Mobile. Since Lua is not a language most people are familiar with, I figured I’d throw together some sample code for Corona and share what I learned so far with the rest of the Corona SDK community by including the template here.

The template includes example code for:

  • Display groups
  • Orientation and accelerometer
  • Touch with buttons
  • File reading
  • Example level file for scripting game play

The template separates functionality into modules for an object oriented approach. I’m still learning the techniques for Lua, so if you notice a better way to do it, please don’t hesitate to let me know in the comments below. Some things in the template are not the best way to accomplish some things, but should give people a good idea on best practices of software design. This will also with work Corona’s Game Edition.

If you find the template useful, take a look at some of our current applications to support us. It’d mean a lot.

Download the Template Code

Also, check out the links on the side. Thanks!

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)

Next Page »