Awesome Android Presentation

... by my "Android in Practice" co-author, Charlie Collins:

Unlocking Android Development on Prezi

iPhone OS/SDK 3.0: Remote Notifications

If you are an iPhone developer, you were probably excited about Apple revealing a beta of OS 3.0 and the corresponding beta of SDK 3.0. There was a lot of excitement and speculation over what new features would be available in 3.0. One of the most anticipated ones was Push Notifications. Everyone thought that Apple would release this since they had promised it in the past, and they were right. So how do you use it? That was the question I asked myself, and here is what I have been able to figure out so far from the documentation.

The first thing you need to do is have your application call the new API registerForRemoteNotifications. This a new API on UIApplication. So when you create your app's delegate (i.e. the class that conforms to the UIApplicationDelegate protocol) you will probably want to invoke registerForRemoteNotifications in your applicationDidFinishLaunching: method (or in the application:didFinishLaunchingWithOptions: method, more on that later.) This will cause the UIApplication to send a request to the Apple Push Service (APS) and it will respond with a token.

When the UIApplication receives that token, it will invoke your app delegate's application:didRegisterForRemoteNotificationsWithDeviceToken:. As the name implies, you get a token as one of the parameters to this method. Your application needs to send this token to your servers. When your server then determines that a notification needs to be sent to a particular device, it will send a request to APS using this token. That is how APS knows where to send the notification to, and also what application the notification is being sent to. It looks like you are pretty limited in what you send to APS, i.e. you do not send (much) application data to APS. You just send it a message saying "hey tell this device that I've got something waiting for it." APS will send this to the user's device.

So the notification arrives, and now there are two possibilities. First, the user is still using your application. In that case, your app delegate is once again invoked, this time it's application:didReceiveRemoteNotification: method is invoked. This lets your app know that you need to phone home to your server and go get the new yummy data.

If your application was no longer active, i.e. that pesky user quit it so they could do something else, then the user will receive a pop-up asking them if they want to launch your application because a notification has been sent to it. If they choose to do so, then when you application launches the app delegate's application:didFinishLaunchingWithOptions: method will be invoked.

In both cases, the delegate will receive an NSDictionary representing the notification as the last parameter passed in. Again, it appears that what can be in this dictionary is pretty limited as its max size is 256 bytes. You can put some custom stuff, like maybe some enum value to represent what kind of notification it is, or an ID to use as a request to get more information.

That is pretty much it! It is fairly straightforward, pretty close to how many people imagined this would work.

New Books!

Wife: "you got a real heavy book in today by fedex."
Me : "I need to leave work early"

Yep, new books arrived today. Here is the new reading list:

Java Concurrency in Practice by Brian Goetz. I know, I know, I should have already read this. The S3 bulk uploader really convinced me of this.

Refactoring by Martin Fowler. I know, I know, I should have read this many years ago...

core Python. Good to have while hacking on GAE.

Don't Make Me Think by Steve Krug. Wouldn't it be great if designers understood programmers? I can't help with that, but maybe I can understand design? Probably not, but worth a try.

Test Driven Development

Terry wrote a great post about "pragmatic" programming. It brings up the usefulness of test driven development(TDD). It is good that this is debated. It seems like it is almost accepted as fact that TDD is good. Period. Whenever people start accepting something without questioning, it leads to very bad things.

So I am glad that Terry questions TDD. Many folks I work with question it, too. Their arguments are different than Terry's. For example they point out that much what you code in a test has to be duplicated by QA. Of course that's not an issue for some folks, because they don't have QA, but it is an issue in larger organizations. Terry uses the example of Facebook as a large organization that uses no hard rules, i.e. TDD, for development. Also, folks I work with point out that TDD is a recurring tax. You not only spend time coding the test to start with, but you spend more time re-writing the tests every time you make changes to your code. The cost of TDD must be weighed against its benefits, you should not just accept it blindly.

To me, the value of tests greatly depends on the clients of your code. Let's say you have code whose only client is the end user, i.e. "application" code. Generally what matters for that code is that it is accepted by the end user. If it does what they want, that is all that matters as that is the only purpose for the code. I can definitely see how writing tests may not have as much value for this kind of code, though I think there is still some value to it.

Now compare this to code whose clients are other pieces of code. To make it simple imagine application code that calls infrastructure code. In this case it's harder to argue that if the end users of the application are happy, then the infrastructure code is good. Imagine if the infrastructure code has an API that is supposed to produce a formatted date. The infrastructure code could produce the wrong formatting, but the application code could work-around this to keep the end user happy. Maybe that is ok, but things get uglier when somebody "fixes" the infrastructure code, particularly if a second application uses the same infrastructure code. Having fine-grained tests for the infrastructure code becomes more valuable.

For me personally, I like using TDD, though I am not religious about it. There are times that I write a test first, then I write the code. There are other times I write the code, then a test, run the test, tweak the test, fix the code, etc. In general, I like to write tests just because I like to test my code to be sure that it works. I figure if I am going to go through the effort of doing that anyways, I might as well do it in an organized way that could be useful to others. Also, writing test code is at least as useful as writing inline documentation in your code, maybe more useful. A unit test is sample code, or darn close to it.

ActionScript Getters and Setters

It's always nice when a programming language surprises you in a pleasant way. ActionScript 3 has get/set property syntax, very similar to C#:

 public class Person implements IPerson
 {
  private var m_name:String;
  
  public function get name():String
  {
   return m_name;
  }
  
  public function set name(value:String):void
  {
   m_name = value;
  } 
 }

What was an even nicer surprise is that you can define properties in an ActionScript interface:

 public interface IPerson
 {
  function get name():String;
  function set name(value:String):void;
 }

And then write code that makes it look like you're accessing the field of an inteface:

       var person:IPerson = new Person();
       person.name = "Michael";

Now if only we had this syntactic sugar in Java... 

New Article on IBM

I've also been busy writing articles and tutorials for IBM. One of them was published today: Get started with Jigloo, a GUI builder for Eclipse. It's an introduction to Jigloo, a nice little plugin for Eclipse for building both Swing and SWT GUIs. The tutorial obviously has a lot more about Jigloo.

XCode

I've been doing some development on the Mac lately. The tool that I've been most interested in is Dashcode, but I've also been using the seminal Mac development app, XCode. I thought it would be interesting to compare it to a couple of other multi-purpose IDEs: Visual Studio and Eclipse.

In some ways it's kind of ironic, but probably the thing that jumps out the most in such a comparison is that VS and Eclipse both have a lot more eye candy. They are more visually appealing programs, at least in my opinion. XCode is a little more stripped down, and not just in the eye candy department.

A popular feature in IDEs is code completion, popularized by VS's IntelliSense. I don't know if VS was the first IDE to have this, I just know it made it popular. I actually think Eclipse does this better than VS these days. XCode has this feature, too, but it is turned off by default. There is something appealing about that to me. Code completion can make developers lazy, and some would argue that it decreases your programming skill. It's hard to argue that it doesn't make you more productive, though. XCode should make better use of it and turn it on by default.

XCode is very good for running and debugging. I was impressed that it gave me an error code in a program that didn't clean itself up properly. Of course that error message was very cryptic, and was just a warning. Only after I fixed the problem did I realize that the weird warning was because I had left some garbage on the heap in the program.

All of this made me think, I wonder if there is an Eclipse plugin that's designed to enable Mac development? The answer is no, and for a good reason. Eclipse is a little clunky on the Mac because SWT is implemented in Carbon, not Cocoa. Most of those super-slick Mac apps out there use Cocoa. SWT binds the native UI elements on whatever system it is running on, so it could use Cocoa or Carbon on the Mac. The SWT developers chose Carbon. They had some very good reasons for doing so, but the end result is Eclipse is a little clunky. It's hard to convince somebody who wants to build a slick looking Cocoa app to use Eclipse.

Anyways, XCode holds up pretty good, though it definitely seems like a notch below VS and Eclipse. Let's face it, appealing to developers has never been Apple's strong suit. Dashcode is kind of promising, though widget development is definitely a niche at this point.