Initial thoughts about the Apple iPad

The hype storm is over, the iPad has been introduced. In a nutshell, you can say it was underwhelming. We didn't see anything that we haven't seen before. Is the iPad as "magical" as they claim it to be? The gut reaction is no, but it may be more than you think.

We can safely say that the iPhone stole the iPad thunder. The iPhone was the introduction of a GUI that was designed for touch-screen, and the iPad merely carried this idea over to a bigger device. If the iPhone had not existed before, the iPad would have had the same revolutionary first-impressions that the iPhone had. But there is another key ingredient to the whole concept of the iPad.

For decades, desktop computers have had an interface that is designed for keyboards and mice. There are files and folders, and a pointing cursor that moves around the screen. You can have layers of windows running any number of processes. This is all fine and dandy when you have ample screen real-estate and processing power.

Netbooks and PC tablets have not changed this concept one bit. The GUI is still based on keyboard-mouse entry. There have been attempts to marry the touch-screen idea to this GUI, but with limited success.

Smartphones (before the iPhone) still tried to carry the same concept to the phones. Files, folders, windows, etc. The screen got so small they had to use a stylus to keep it functional. It was to say the least, difficult to use.

The iPhone changed all of that. The notion of files and folders was thrown out. Visible layers of windows were also thrown out. Instead, a whole new GUI was designed with the fingers in mind. A single window is presented at any one time, with instinctive visual cues as you slid between them. The iPhone made it easy for anyone to pick up and use the phone, they "just got it."

Now bring in the iPad. What the iPad accomplishes is mobile desktop power coupled with the iPhone touch-screen interface. Now that we have more screen real-estate we can do a few more things, such as split-pane views and fancier menus. But for the most part, the concepts are the same. Everything is designed with the fingers in mind. No stylus, no mouse or keyboard necessary. That makes specific tasks (email, web, video, etc.) quick and easy, on a device smaller than most netbooks.

So what does that mean? I think this ushers in a new era of how we think about computing. There will always be a place for keyboard-mouse computing for more complicated tasks (ie. design/illustration, video editing, desktop publishing.) But for the everyday use and mobility, this is a big step toward a new way of thinking. My dad for instance, has never used a computer. He is just not interested in learning it all. However, I think he could pick up an iPad and "get it" very quickly. No files/folders/styles/keyboard/mice things to deal with. Just intuitive interactive elements that do what you expect when you touch them.

You recall the funny tech-support stories about people trying to use the mouse as a foot pedal, or tapping the mouse against the screen trying to "click" on something. You laugh, but maybe this was a big clue into computing intuition, and how it should have worked in the first place. Now that we have the technology to do it, the iPad is simply leading the way.

Of course, the first version of any device is always going to have shortcomings. It just takes time for things to work themselves out. I have no clue why Apple skipped out on a camera, but you can bet that iPad 2 will have one. You can also bet that iPhone OS 4.0 will have multitasking. These things just come with time.

The importance of the iPad is an intuitive finger-controlled interface married to a mobile device with the power/size of a desktop, without the typical complexities of desktop computing as we know it.

One iPhone 4.0 wish

I've seen a lot of feature wishes, but one I have not seen that would be really useful. That would be backup over Wi-Fi. But more precisely, give me the option to backup when I plug in the charger.

My phone rarely gets backed up because I'm not in front of my Mac every day (it sits in the basement.) I typically use my iPhone or netbook upstairs for daily use. I do however, charge my iPhone every night.

Backups over Wi-Fi would be a battery drainer, so it would be preferable to happen while plugged in. Therefore when I plug in the charger, it could pop up an option to backup the phone over Wi-Fi. Then the phone gets backed up and synced every night, without the hassle of visiting the dock.

Cocoa and Delegates

Delegates are probably one of the toughest concepts for iPhone/OSX developer newcomers to grasp. I'm going to try to keep it simple, and demonstrate how to build your own delegate protocol into your classes.

A delegate is merely a design pattern in Objective-C. Simply put, it provides a way for objects to "listen" for interesting things happening in your object and act on them without your object knowing anything about the object(s) listening. Delegates are used heavily in the Cocoa environment. Most often you will see delegates used to trigger methods on a UIViewController, although they can be implemented on anything.

Let's think for a moment what type of problem this solves. Let's say we have a UIViewController which has a UITableView in its view. When a table row is tapped, we want to slide a new view onto the screen. We don't want UITableView handling this task, so how do we accomplish this?

The UIViewController needs to handle the new view (thus it's name.) So the UITableView needs to somehow inform the UIViewController that a row was tapped so it can take action. Therefore, the UIViewController needs to be the delegate of the UITableView. So we need to setup two things: We need to inform the UITableView what it's delegate object is, and we need to inform the delegate object what delegate protocol(s) it conforms to.

We begin by setting the delegate property of the UITableView to the UIViewController object. If you are using Interface Builder, you can simply connect the delegate property of the UITableView to the UIViewController (typically the File's Owner.) Otherwise you might handle this in the viewDidLoad{} of the UIViewController, something like:

self.tableView.delegate = self;

You will also want to tell the view controller that it understands the UITableViewDelegate protocol, so you would put this in the UIViewController .h interface declaration:

@interface MyViewController : UIViewController
<UITableViewDelegate> {}

(Note: if your view controller is an extension of UITableViewController, you will not need to declare the UITableViewDelegate protocol.)

And you are set! Now when you implement a method of the UITableViewDelegate in the UIViewController, this method will trigger when something happens in the table view for that delegate method. So for instance, you put this in your UIViewController .m file:

- (void)tableView:(UITableView *)tableView
didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
// push the new view onto the stack here
}

When a row is selected in the table, this method will get triggered.

So now begs the question, how do you add your own delegate protocol to your custom classes? Here is an example. Let's say you want to be able to trigger methods of other classes when interesting things happen in your class. The first thing you need to do is define what delegate methods are available to the delegate object. You would first put something like this at the top of your class .h file, above the implementation declaration:

@protocol MyCustomClassDelegate <NSObject>;
- (void)didClickDone:(UIButton *)button;
@optional
-(void)didClickCancel:(UIButton *)button;
@end

Where MyCustomClassDelegate is the name of your class delegate protocol (your class name appended with "Delegate"), and didClickDone and didClickCancel are the names of your two delegate methods. You can add as many methods as you wish. You not need to implement these methods in your class, that is up to the delegate to do. Notice the line with @optional. This means that the following methods are optional for the delegate to implement.

Now we need to setup the delegate property:

@interface MyCustomClass : NSObject {
id <MyCustomClassDelegate> delegate;
}

@property (nonatomic, assign)
id <MyCustomClassDelegate> delegate;

And finally in the .m file, synthesize the delegate:

@synthesize delegate;

Note we do not need to release the delegate in the dealloc method, as this is not a retained object, it is just an assigned id.

Ok, for the final part of your class, you need to fire off the delegate method when something interesting happens. For instance, someone clicks the done button. In your IBAction for the done button, you do just that:

-(IBAction)done:(UIButton *)button {
[self.delegate didClickDone:button];
}

And so on, for each delegate method. Ok, that is it for the class. Now, for the delegate class. To be the delegate of MyCustomClass, you need to declare that you implement the MyCustomClassDelegate protocol (.h file):

@interface MyViewController:
UIViewController <MyCustomClassDelegate> { }

And then, we implement the delegate methods (.m file):

-(void)didClickDone:(UIButton *)button {
// do something here!
}

One last thing to note, a class can be the delegate for several objects, just comma-separate the delegates:

@interface MyViewController:
UIViewController <MyCustomClassDelegate,SomeOtherDelegate> { }

I hope that helps clear up delegates a bit! Please leave your comments below.

Winning one million from the casino, guaranteed (nearly)

So you want to beat the casino for a cool million. Ok, here is a system on the roulette table. It's theoretical, it will take awhile, and you had better have some deep pockets. Here is how it works.

1) bet $1 on red (or black, whatever you prefer)
2) if you lose, bet $2 on red/black
3) if you lose, bet $4 on red/black
... continue this pattern until you win...
4) you win $1. Start over on step 1.

Continue the above step system 1,000,000 times. At the end, you should end up $1,000,000 ahead. Now there is a couple of things to consider. Although it is highly unlikely you will win/lose more than, say, 20 times in a row, it is quite possible to happen in 1,000,000 runs of the above system. In that case, you could be wagering a lot once in a while. In a computer simulation of running the system 1000 times, There was a bet of 134 million touched. That's quite a bit to hope for a dollar.

So to be able to run this system, you have to have DEEP pockets. That, and find a casino that will let you play this way. Good luck with that :)

From the simulation, here is the breakdown of wagers, # of times encountered, and % chances of happening:

wager: $1 # of times: 47363291 (47.363291000%)
wager: $2 # of times: 24927507 (24.927507000%)
wager: $4 # of times: 13121947 (13.121947000%)
wager: $8 # of times: 6908653 (6.908653000%)
wager: $16 # of times: 3637176 (3.637176000%)
wager: $32 # of times: 1915725 (1.915725000%)
wager: $64 # of times: 1007786 (1.007786000%)
wager: $128 # of times: 528916 (0.528916000%)
wager: $256 # of times: 278835 (0.278835000%)
wager: $512 # of times: 147026 (0.147026000%)
wager: $1024 # of times: 77406 (0.077406000%)
wager: $2048 # of times: 40696 (0.040696000%)
wager: $4096 # of times: 21300 (0.021300000%)
wager: $8192 # of times: 11167 (0.011167000%)
wager: $16384 # of times: 5988 (0.005988000%)
wager: $32768 # of times: 3215 (0.003215000%)
wager: $65536 # of times: 1609 (0.001609000%)
wager: $131072 # of times: 840 (0.000840000%)
wager: $262144 # of times: 417 (0.000417000%)
wager: $524288 # of times: 246 (0.000246000%)
wager: $1048576 # of times: 126 (0.000126000%)
wager: $2097152 # of times: 67 (0.000067000%)
wager: $4194304 # of times: 35 (0.000035000%)
wager: $8388608 # of times: 13 (0.000013000%)
wager: $16777216 # of times: 7 (0.000007000%)
wager: $33554432 # of times: 6 (0.000006000%)
wager: $67108864 # of times: 4 (0.000004000%)
wager: $134217728 # of times: 1 (0.000001000%)