Head First iPhone and iPad Development is out!

Head First iPhone and iPad Development is shipping as we speak, which is very exciting! Updating Head First iPhone was a daunting task this time around, there have been lots of developments with iOS development since we printed the first time. Timing the release of the book around those updates was tricky, especially with the well-known Apple secrecy around new releases.

Going through and working on the update it was amazing to see all the changes that have taken place since the last version. The biggest changes are the introduction of the iPad, and iOS going from being the operating system for the iPhone to the OS for both. The result for developers is that the Objective-C hasn't changed, but what you're using it for is significantly different based on the device. We added two new iPad apps to the book and the last chapter has lots of good information about designing UI for the iPad instead of the iPhone.

The key difference in design for these two platforms is the time of interaction. iPhone users are almost always waiting for something. An appointment to start, somebody to meet them, the light to change. Interaction is quick and focused. iPad users are settling in for an extended interaction with the device. Sitting on the couch to shop, or read a book. The additional screen space is nice too, but just making an iPhone app bigger isn't going to cut it.

The second edition of the book uses Xcode 4, which is a vast improvement over Xcode 3. GUI layout with Interface Builder has been integrated into the main IDE, which is huge. You can graphically link outlets and actions with Xcode, code completion and documentation are vastly improved. It has an assistant editor that allows you to look at related code side by side as well. Debugging is in the main window as well. Xcode now really feels like a competitor to Eclipse or other more mature development environments. It does make development much easier.

Another big change to the iOS world is the maturity of the App store and the industry. When we published in 2009, the App store was just over a year old, and the Android Marketplace was just getting up and running, and App development was fairly immature. Since then, things have grown to the point that enterprises are getting into App development, because they need to be present on these app stores the way that they need a website. The first year the App Store made $50 - $100 million (from Business Insider). In 2010, Apps were a $5.2 billion business (from Gartner).

A quirk of this whole thing is that most enterprises, even if they have in-house developers, are PC shops. Since you can't develop for iOS on a PC, it means a fantastic opportunity for freelancers and developers who know iOS.

The book still features a cranky bartender, a bounty hunter, and a guy with relationship problems, but we fix their issues with iPhones and iPads this time. We really hope everyone enjoys the book and finishes with a good foundation to build their own apps!

Posted by Tracey Pilone on Thursday, Jun 30 Permalink | Comments (5)

No Code Is Sometimes Best

I recently set my final year software engineering undergrads a task to take a simple Google App Engine webapp and add a login/registration system to it. I made a point of advising my students to RTFM (read the *full* manual), highlighting to them that there is lots of great functionality provided with App Engine "for free" and that its all just sitting there, waiting to be exploited by savvy developers.

When my students submitted their work, half of them had done half of what I'd asked. These students created the datastore descriptions required to store user-ids and passwords, created some UI forms to solicit login/registration information from the users of their webapp, and then tied it all together with lots and lots of code to make sure the logic worked as required, providing a fully functioning authentication system for their webapp. These students were quite pleased with themselves as they'd obviously done quite a bit of work here. After all, look at all the code they'd written!

The other half of the class did everything I asked, including taking my RTFM advice to heart, and - suitably enlightened - simply added the following line to their webapp's configuration file:

    login: required

Of course you may not agree, but I'd suggest that the Google engineers have this problem pretty much solved by now and that any attempt to write a custom App Engine login/registration system is, at best, ill-advised and, at worst, unproductive. Although there's a case to be made that there's lots to learn from "rolling your own", there's also the point to be made that the savvy developer knows what to concentrate on, that is: build only the functionality that's specific to a webapp... then "beg, steal and borrow" the rest. Knowing when to and when not to write code is skill worth mastering.

Now, as readers of this blog know, I'm a big fan of the "Less Code Is Better" principle, but I'll take no code over less code any day. And I'm always amazed when a developer (not just a student) insists on writing everything from scratch. What explains this blind rush to write code? Is it inexperience? Arrogance? Madness? All of the above?

What do you think? I'd love to hear other developer's views on this.

Posted by Paul Barry on Monday, May 30 Permalink | Comments (8)

Less Code Is Better

Head First Python contains examples of Python's list comprehension technology, which is a technique that lets me take code like this:

    new_list = []
    for thing in some_list:
        new_list.append(do_something(thing))

and turn it into shorter code, like this:

    new_list = [do_something(thing) for thing in some_list]

Note that both code fragments assume the existence of a list called some_list and a function called do_something(). List comprehensions are an example of Python's functional programming facilities, whereas the three lines of "standard code" are an example of Python's imperative programming facilities. Both work, of course and - depending on your point of view, one technique may appeal to you over the other.

I'm a big fan of the "less code is better" principle, in that I firmly believe the number of bugs in my code is directly related to the number of lines of code I write. Any technique that lets me write less code always gets a big thumbs-up from me, and using list comprehensions lets me write less code. To illustrate, let's take a real-world example of where using a list comprehension can have a dramatic impact.

Imagine I've designed a web application that has a HTML form element that allows my users to select an age from a drop down list. I'm building my web application using the popular Django web framework, which has lots of built-in goodness for dynamically creating HTML. In fact, Django can dynamically generate a HTML form directly from a model definition, which is way cool. When I use code like this to define my data model, Django takes it and dynamically generates a form:

    from django.db import models 
    class StudentData(models.Model):
        name = models.CharField(max_length=50, 
                                verbose_name="Student's Name")
        age = models.IntegerField(verbose_name="Student's Age")

As well as the self-explanatory arguments to the field definitions, there's also an argument called choices which allows me to specify a list of tuples which Django will use to restrict the input values allowed. If I create a list like this:

    _ALLOWED_AGES = [(4, '4'), (5, '5'),
                     (6, '6'), (7, '7'),
                     (8, '8'), (9, '9'),
                     (10, '10'), (11, '11'),
                     (12, '12'), (13, '13'),
                     (14, '14'), (15, '13'),
                     (16, '16'), (17, '17'),
                     (18, '18')]

I can then change my model definition for age to look like this:

    age = models.IntegerField(verbose_name="Student's Age", 
                              choices=_ALLOWED_AGES)

Django will now use this list to create a HTML drop-down list within the form. The first element in each tuple is the value stored in the model, whereas the second element is displayed within the form's drop-down list. Pretty easy, eh?

Well... yes, it it easy... but, look at all that extra code. Count the lines added: 9. That's nine places where I could potentially introduce an error into my code. Remember: more code means more errors. Did you notice that I have a typo in the string-value associated with 15? It is incorrectly coded as '13', not '15'? Hard to spot, isn't it?

Let's improve things--and by improve I mean "reduce the possibility of error"--by writing some code to generate the list, instead of simply defining it. I'll start with an empty list which I then populate with the generated tuples using a standard for loop:

    _ALLOWED_AGES = []
    for each in range(4,19):
        _ALLOWED_AGES.append((each, str(each)))

Which gets me down to 3 lines of code, which isn't bad. Of course, I can rewrite this using a list comprehension:

    _ALLOWED_AGES = [(each, str(each)) for each in range(4,19)]

Which gets me down to just 1 line of code, which I think is pretty cool.

Now, ask yourself this question: which would you rather maintain? Nine lines of code, three lines of code or just one line of code?

To conclude, and to shamelessly paraphrase a famous Canadian singer/songwriter: Less code is better. Bumper stickers should be issued!

Posted by Paul Barry on Tuesday, May 10 Permalink | Comments (9)