iOS

How to work with dates and times in Swift, part one

by Joey deVilla on January 26, 2015

i just want to use dates

swift kickIf you’re just getting started with date and time programming in Swift, chances are that you probably did some Googling, found NSDate and its companion classes in Apple’s documentation and promptly got confused. Let me reassure you that it isn’t your fault. Apple’s Date and Time Programming Guide isn’t set up in the most helpful way, and its examples are in Objective-C, which can throw you off if you’re not familiar with its [instance method] calling syntax.

If you’re coming to Swift from JavaScript, which makes do with a single object type called Date, the idea of having this set of classes just to handle dates and times looks like overkill:

cocoa date time class chart

Click the chart to see it at full size.

This is the first article in a short series on programming dates and times in Swift. It’ll help you make sense of working with NSDate and its companion classes.

What is UTC? (or: “It’s 5 o’clock somewhere!”)

what time is it right now

People who like to drink are fond of saying “Well, it’s five o’clock somewhere!“, and it’s my favorite way of illustrating that what time it is depends on where you are. It’s why we have UTC — Coordinated Universal Time — the “One True Time” on which every other time zone is based. UTC replaced GMT (Greenwich Meridian Time, the time as observed at the Royal Observatory in Greenwich, London), and it doesn’t change for daylight savings. By having this standard, we eliminate the confusion that comes up when discussing times.

While most places have some names to refer to time zones in everyday conversation — such as Pacific, Mountain, Central, and Eastern in North America — the clearest way to indicate time zones is to express them as negative or positive offsets from UTC. For example, the North American time zone known as “Eastern” is 5 hours behind UTC, so it’s expressed as UTC-05:00. There are certain time zones where the offset isn’t whole hours, such as Newfoundland’s, which is UTC-03:30, and Nepal’s, which for some reason is UTC+05:45.

NSDate: Cocoa standard time

When you want to represent a date or time in Cocoa, you do so with an instance of the NSDate class. Here’s a nice, simple description of what NSDate is:

nsdate

When you’re measuring time, you need a reference point. The Gregorian calendar — the one that I’m 99.999999% sure that you’re using right now — uses what is said to be the year of the birth of Christ as its reference point. Your age uses the date of your birth as a reference point. A time trial race uses the time at the start of the race as its reference point.

NSDate‘s reference point is the start of the third millennium: January 1, 2001 at midnight UTC. It stores time as an NSTimeInterval, a 64-bit floating point value representing a number of seconds. Negative values represent a number seconds before January 1, 2001, 00:00 UTC, and positive values represent a number seconds after that time. According to Apple’s documentation, this representation of time “yields sub-millisecond precision over a range of 10,000 years”, which means that an NSDate instance can represent any point in time from about 3000 BC/BCE to 7000 AD/CE.

Here are 4 historical dates, as seen from NSDate‘s perspective:

historical dates nsdate style

There are some consequences to the fact that NSDate treats time as an offset of seconds:

  • All NSDate values refer to both a date and a time. If you want to use an NSDate to store a date only, you ignore the time portion, and vice versa.
  • NSDate has no concept of time zones or any time unit other than seconds. That means you can’t ask it what year, month, day, hour, or minute correspond to the time it’s storing. As far as it’s concerned, there are no calendars; you work with NSDate‘s representation of time, when it’s time to display a date, time, or both, you format it to use the calendar and time zone that’s appropriate for the user.

There’s a method to this madness: it allows us to use and store dates and times in a way that’s independent of calendar systems, time zones, languages, and date formats. As I write this, it’s the year 2015 in the Gregorian calendar, but the Buddhist calendar says it’s 2558, and if you go by the Hebrew Calendar, it’s 5775. I may say it’s 9:45 a.m. as I write this in Tampa, but if you’re in California, it’s 6:45, and if you’re a soldier, you might call it 14:45 Zulu Time. I call the current month January, but you might call it Enero or Janvier. It’s all the same as far as NSDate is concerned, which makes it incredibly flexible.

Creating NSDates without any helper classes: now is easy, other dates ain’t so pretty

Let’s create some NSDates right now. Fire up Xcode, open a new playground, and enter the following code so that it looks like this:

You should see results in the sidebar that look similar to this:

playground 1

If you create an NSDate without any parameters, you get an instance representing the date and time at the moment it was created. That’s what we’ve done by creating the instance named now.

Note that in the sidebar beside line 5, where we created now, the result displayed in the sidebar is Jan 19, 2015, 8:52 AM. While the internal representation of the current time is a 64-bit floating point value, Xcode’s doing us a favor by representing it in a more readable format and using the local time zone. It’s doing this by making use of a date formatter, which we’ll cover later.

In line 6, we’re using the println function to display the default string representation of an NSDate, which is a completely numeric one. It’s more readable than a 64-bit floating point value, but it might not be in the format or time zone (or even the calendar system) that you want. Once again, this output comes courtesy of a date formatter.

Finally, in line 7, we use the timeIntervalSinceReferenceDate property to display now‘s internal representation of the date and time it’s storing: about 443 million seconds after January 1, 2001 at midnight UTC.

Let’s create the dates from the Historical dates, NSDate style picture above. Enter or paste the highlighted code below so that your playground looks like this:

In the sidebar, you should see nicely-formatted dates beside the NSDates you created.

NSDate has four initializers for creating specified dates and times:

Initializer Description
init(timeIntervalSinceReferenceDate:) Create an NSDate instance representing a time specified by a number of seconds before or after January 1, 2001 00:00 UTC.
init(timeIntervalSinceNow:) Create an NSDate instance representing a time specified by a number of seconds before or after the current date and time.
init(timeIntervalSince1970:) Create an NSDate instance representing a time specified by a number of seconds before or after January 1, 1970 00:00 UTC. This method exists not because Apple’s founders were California hippies nostalgic for the era of their youth, but for compatibility with Unix time.
init(timeInterval:sinceDate:) Create an NSDate instance representing a time specified by a number of seconds before or after a given NSDate.

You’ve probably noticed that none of these initializers lets you create an NSDate by giving it something convenient like a year, month, day, time zone and so on. Luckily, there are classes that will help us do this.

Creating NSDates with the help of NSCalendar and NSDateComponents

If you’re like most people, you’d probably much rather initialize a date object using a day, month, year, and time instead of some number of seconds before and after midnight on January 1, 1970, January 1, 2001, or any other arbitrary date. For this, we’ll need a couple of additional classes:

nscalendar and nsdatecomponents

First, there’s the NSCalendar class, which among other things, gives us a context for converting NSDate‘s “seconds before or after the third millennium” measurements into a familiar time system with years, months, days, hours, and minutes, and it accounts for time zones as well. Most of the time, the date and time system will be the Gregorian calendar, but iOS also lets you choose from 15 other calendar systems, including Hebrew and Buddhist.

Next, there’s the NSDateComponents class, which is an assembly of properties that make up a date, such as year, month, date, hour, minute, second, and so on. An NSDateComponents instance can be used to represent either:

  • A specific point in time, or
  • a duration of time.

To create an NSDate by specifying things like a year, month, day, and time, we’ll do the following:

  • Create an NSCalendar instance pointing to the user’s calendar
  • Specify a date using an NSDateComponents instance
  • Create the NSDate by passing the NSDateComponents instance to NSCalendar‘s dateFromComponents instance method

nsdatecomponents to nsdate

Let’s go back to our playground and create our first historical date: that of Alexander Graham Bell’s first phone call. We know it took place on March 10, 1876. While we don’t know the exact time it happened, we do know that it happened in North America’s Eastern time zone, as opposed to something like Kiritimati, a.k.a. Christmas Island. That place is 19 hours ahead and would’ve resulted in historians recording that day as March 11th rather than the 10th.

Enter or paste the highlighted code below so that your playground looks like this:

Any calendar, regardless of its time zone, to turn date components into dates using its calendar system. If you specify a time zone in the date components, it will take that time zone into account; if you don’t specify one, the date will be created using the calendar’s time zone. We created an instance of the user’s calendar, which incorporates the user’s local and time zone settings, because it’ll be useful later when we want to go in the opposite direction and convert dates into date components.

Note that after setting the year, month, and day properties of firstLandPhoneCallComponents, we set the timeZone component using the preferred initializer, init(name:), which lets you specify a time zone by any of the standard string identifiers listed in the tz database of time zones. I could’ve used one of the city names such as America/New_York (or for those of you familiar with Canada, America/Toronto, America/MontrealAmerica/Atikokan, or America/Pangnirtung) to specify the Eastern time zone. It’s far clearer — especially to people not from the U.S. — to use the time zone names that begin with US or Canada, such as US/Eastern, US/Central, US/Mountain, and US/Pacific rather than city names.

Once we’ve set up the date components, we use the calendar’s dateFromComponents instance method to convert them into a date. I’m in the US/Eastern time zone, the same one as the one specified in the date components, so the result in the sidebar beside this line of code shows as “Mar 10, 1876, 12:00 AM” (we didn’t specify a time in the date components, so the resulting date has the default time of 00:00). The date displayed in the sidebar uses your system settings, which may be different from mine.

Let’s enter the other three historic dates. Enter or paste the highlighted code below so that your playground looks like this:

Note that we used different time zones for the “Stevenotes”. Both took place at the same time, 10:00 a.m. Pacific, but we set the time for the iPhone announcement as 1:00 p.m. US/Eastern, and the time for the iPad announcement as 10:00 a.m. US/Pacific. Both results in the sidebar appear at the same time; on my machine, they appear as Jan 27, 2010, 1:00 PM.

dateFromComponents works with what you give it

Suppose we want to create a date just by specifying that it’s 11:00 a.m. on the first Saturday of March 2015 in the US/Eastern time zone. Here’s how it’s done:

NSDateComponentsweekday property lets you specify a weekday numerically. In Cocoa’s Gregorian calendar, the first day is Sunday, and is represented by the value 1. Monday is represented by 2, Tuesday is represented by 3, all the way to Saturday, which is represented by 7.

The weekdayOrdinal property lets you specify which specified weekday of the month. By setting weekday to 7, we’re specifying a Saturday; by then setting weekdayOrdinal to 1, we’re specifying the first Saturday of the month.

Here’s another example, where we get the date for the Thursday on the 18th week of 2015:

The other way around: getting NSDateComponents from NSDates

Right now, your playground should look like this, with a number of dates being created from date components:

Now it’s time to go the other way around, and extract date components from those dates. Once again, it’s the calendar that provides the method for making the conversion.

To extract NSDateComponents from an NSDate, we’ll do the following:

  • Create NSCalendar instances, if needed
  • Specify a set of date components using NSCalendarUnit bitmasks
  • Create the NSDateComponents by passing the NSDate instance to NSCalendar‘s components instance method

nsdate to nsdatecomponents

We already have a calendar instance: userCalendar, which is associated with the user’s time zone. If we use it to extract date components from a given date, the dates and times will be interpreted in the context of its time zone.

Let’s create two more calendars with two different time zones:

  • The US/Pacific time zone (UTC-08:00)
  • The Japan time zone (UTC+09:00)

Here’s what the code looks like:

Extracting all the possible date components from a date can be computationally costly, so NSCalendar‘s components instance method requires you to build a bitmask specifying the components you want to extract by ORing together NSCalendarUnit values. We want to extract these components from our dates:

  • year
  • month
  • day
  • hour
  • minute
  • weekday
  • weekdayOrdinal

Here’s the code:

Now that we’ve done that, we can start extracting date components:

In your playground’s sidebar, you should see results similar to those listed in the table below:

Component My user calendar Pacific calendar Japan calendar
year 2007 2007 2007
month 1 1 1
day 9 9 10
hour 13 10 3
minute 0 0 0
weekday 3 3 4
weekdayOrdinal 2 2 2

As you can see, January 9, 2007 at 10:00 a.m. in the US/Pacific time zone is January 9, 2007 at 1:00 p.m. in my time zone (US/Eastern) and January 10, 2007 at 3:00 a.m. in Japan. In the US, that date was the second Tuesday in January 2007; in Japan, it was the second Wednesday.

Turning dates into strings (and vice versa) with NSDateFormatter

nsdate - nsdateformatter - stringJust as you use an calendar to convert date components into dates and vice versa, you use a date formatter — an instance of the NSDateFormatter — to do the conversions.

Formatting date strings for the user

If you need to display a date as text for the user, it’s best if you use Cocoa’s built-in date styles. These are a set of predefined styles for formatting dates and times based on the user’s preferred settings. These styles, which are all values of the NSDateFormatterStyle enumeration, come in a selection of lengths — short, medium, long, and full — and using them is the preferred way to create date strings for the user to read.

Add the following code to your playground:

Here’s how the various date and time formatter styles get rendered:

If dateStyle and timeStyle are both set to… the date formatter’s output looks like…
NoStyle
ShortStyle 1/27/10, 1:00 PM
MediumStyle Jan 27, 2010, 1:00:00 PM
LongStyle January 27, 2010 at 1:00:00 PM EST
FullStyle Wednesday, January 27, 2010 at 1:00:00 PM Eastern Standard Time

What’s up with NoStyle? It’s there so you can limit the resulting string so that it shows only the date or only the time.

NSDateFormatter has a timeZone property so that you can ensure that the date string reflects a specific time zone:

Formatting date strings for other computers

As I wrote earlier, if you’re formatting dates for the user, it’s strongly recommended that you use NSDateFormatter‘s dateStyle and timeStyle properties, which will format dates and times according to the user’s settings. However, if you need to need your date strings to be in a specific format (for an API, for example), you can provide NSDateFormatter with a format string:

While you can browse through Appendix F of the Unicode Technical Standard #35 to look at all the date format specifiers supported by NSDateFormatter, you might find it easier to use the table below. It shows a number of format strings applied to the iPhone announcement date (January 9, 2007 at 10:00 a.m. Pacific):

Format string Result
'Year: 'y' Month: 'M' Day: 'd Year: 2007 Month: 1 Day: 9
MM/dd/yy 01/09/07
MMM dd, yyyy Jan 09, 2007
E MMM dd, yyyy Tue Jan 09, 2007
EEEE, MMMM dd, yyyy' at 'h:mm a. Tuesday, January 09, 2007 at 10:00 AM.
EEEE, MMMM dd, yyyy' at 'h:mm a zzzz. Tuesday, January 09, 2007 at 10:00 AM Pacific Standard Time.

Turning strings into dates

If you specify a date format string, you can use NSDateFormatter to take a string following that format to turn it into an NSDate. For example:

Tying it all together

If you’ve made it to this point in the article, this chart should now make sense:

cocoa date time class chart

Once again, click the chart to see it at full size.

You should now be able to:

  • Create dates “from scratch” (that is, create them using an offset of a number of  seconds from the start of the third millennium)
  • Create dates from date components (that is, from numbers representing a day, month, and year)
  • Convert between dates and date components
  • Convert dates into string representations and string representations of dates into dates

In the next article in this series, we’ll look at date calculations and some handy functions that let you harness Swift’s expressive power and make working with dates easier.

{ 1 comment }

Photoillustration of a woman photocopying an iPhone.

Relax, Fandroids. I kid because I care.

Cover of 'Dogfight' by Fred Vogelstein.“As a consumer, I was blown away,” says Googler Chris DeSalvo in a quote from Fred Vogelstein’s book, Dogfight, upon seeing the now-legendary January 9, 2007 Stevenote when he unveiled the first iPhone.

“I wanted one immediately,” DeSalvo continues. “But as a Google engineer, I thought ‘We’re going to have to start over.’

According to the Atlantic article The Day Google Had to ‘Start Over’ on Android, an excerpt from Dogfight, Google’s big concern at the time was Microsoft. It made sense at the time: They seemed to be making the right moves. If you remember those days, Windows Mobile 5.0 was the third revision of their mobile operating system, and true to the general rule about Microsoft revs, it was finally good enough. They’d lined up an impressive array of nearly 50 hardware partners, including HTC, who’d end up shipping the most WinMo phones, and the big coup: Palm, whom they’d convinced to build phones that ran WinMo. Their OS featured mobile versions of Office. The industry rumblings were that Microsoft would end up eating away at the dominant phone OS player at the time, Symbian. “Microsoft comes out fighting when threatened,” the conventional wisdom said. “Remember what happened in the browser wars?”

Here’s what was considered to be the game-changer that would make Microsoft a serious mobile threat: the Palm Treo 700w

Palm Treo 700w phone

The Palm Treo 700w.

The best smartphones of the era followed a design template that had been defined years earlier by the Blackberry: screen at the top, physical keyboard at the bottom, augmented by some kind of device to move the cursor (first a scroll wheel, then a D-pad, and optionally, a stylus).

Then this happened:

(If you haven’t seen it before or in a while, watch it again. You can almost feel the audience’s excitement in the opening moments, as Steve teases them with hints of what he’s about to announce. You can also feel the envy when Google’s Eric Schmidt comes onstage at the 51-minute mark — remember that he was on Apple’s board then.)

From the article:

On the day Jobs announced the iPhone, the director of the Android team, Andy Rubin, was six hundred miles away in Las Vegas, on his way to a meeting with one of the myriad handset makers and carriers that descend on the city for the Consumer Electronics Show. He reacted exactly as DeSalvo predicted. Rubin was so astonished by what Jobs was unveiling that, on his way to a meeting, he had his driver pull over so that he could finish watching the webcast.

“Holy crap,” he said to one of his colleagues in the car. “I guess we’re not going to ship that phone.”

Another key quote, this time from Ethan Beard, one of Android’s early biz dev people:

“We knew that Apple was going to announce a phone. Everyone knew that. We just didn’t think it would be that good.

With the announcement of the iPhone, the Android project, whose members had been working “sixty-tp-eighty-hour weeks for fifteen months — some for more than two years” made a pivot whose effects we’re still feeling today. The BlackBerry-like phone that they’d been working on — codename “Sooner”, with a physical keyboard, no touchscreen, and a general “me-too” design — was pushed aside. They filed mobile phone-related patents galore in September 2007. The iPhone forced them to rethink the OS and phone design, and from that came a new design, codenamed “Dream”. This pivot would require them to delay their first release by a year, and the end result was the HTC Dream, released in October 2008.

HTC Dream phone, shown in landscape mode with the sliding keyboard extended.

The HTC Dream.

As you can see, the Android weren’t so sure about all of Apple’s design decisions, hence the physical keyboard and trackball. Today’s phone designs tell you how those choices by the Android team worked out.

I’ll close with an observation based on the article by John “Daring Fireball” Gruber. He may be Apple’s freelance PR guy, but he’s often right, including in this case:

Remember a few years ago, at the height of the “Android is a ripoff of the iPhone” controversy, when Android supporters claimed that the similarities were just some sort of amazing coincidence, like Newton and Leibniz discovering calculus concurrently, because Android had started life a few years before the iPhone was introduced? Good times.

I’m going to get my paws on a copy of Dogfight and read it over the holidays. Expect a review of it in the coming weeks.

 

{ 0 comments }

weather app

Whether you’re new to iOS programming or a long-timer, RayWenderlich.com is a valuable resource for the iOS developer. They regularly publish tutorials, tips, tricks and other goodies that you’d be crazy to do without if you’re serious about writing apps for iDevices. In addition to articles on the site, they go deeper with their books, which are excellent.

RayWenderlich.com recently published an article titled AFNetworking Crash Course, which covers how to write networking apps using AFNetworking, a library created by the folks at Gowalla that simplifies iOS network programming. In this tutorial, you build a weather app that uses AFNetworking to get its data from the World Weather Online service. Check it out; AFNetworking’s useful, and the tutorial’s pretty nice.

In order to reach the widest possible audience, the tutorial was written for iOS 5 and earlier versions of Xcode. If you’re developing with the current version of Xcode and for iOS 6 (which accounted for 83% of all iOS traffic in North America in February), you might want to make a few changes to the code in the tutorial. I’ve listed the changes below:

Use Modern Array Notation

Here’s the old way to get at the element of an array whose index is theIndex in Objective-C:

It’s a little clunky, and as I wrote in an earlier article, Objective-C’s New NSNumber, NSArray and NSDictionary Syntaxes Mean Less “Yak Shaving” for iOS and OS X Developers, there’s a much nicer way to do it:

In AFNetworking Crash Course, where you see code like this:

change it to this:

Use Modern Dictionary Notation

Here’s the old way to get at the item in a dictionary whose key is theKey:

Again: it’s clunky. Also again, in my earlier article, I showed the modern way to access dictionary items:

Setting items for a dictionary used to be like this:

Now, it’s like this:

So, in the places where you see code like:

change it to:

…and where you see code like:

change it to:

Update the Deprecated Location Manager Delegate Method

If you use the code as-is with iOS 6, you’ll get an error message that looks like this:

Deprecated in iOS 6.0
locationManager:didUpdateToLocation:fromLocation:
Tells the delegate that a new location value is available. (Deprecated in iOS 6.0. Use locationManager:didUpdateLocations: instead.)

Instead of using the deprecated locationManager:didUpdateToLocation:fromLocation: method, use the current locationManager:didUpdateLocations: method instead:

{ 0 comments }

RubyMotion Tutorial

Clay Allsop’s RubyMotion Tutorial appears to be the most complete tutorial on the topic online. If you don’t relish the idea of programming in Objective-C but want to write native iPhone apps, you should check out this tutorial and see if coding apps in Ruby with RubyMotion is for you.

If you’re feeling really ambitious, you can fork the tutorial on GitHub and rewrite or expand upon your own version.

Links

AIDE: Android Java IDE

AIDE, the Android Java IDE, lets you code apps for Android devices on an Android device. It’s fully compatible with Eclipse projects, supports the full edit-compile-run cycle and has an editor with desktop IDE features like code completion, real-time error checking, refactoring and smart code navigation. According to the description, AIDE will “turn your Android tablet with keyboard into a real development box” and will “turn your Android Phone into a small development computer to browse and touch your code on the go.”

Links

iOS Image Tricks

Adam from Dwellable, the app for finding and reviewing vacation rental homes, shares some iOS image tricks that he used while taking the iPad version of the app and converting it into an iPhone app. These tricks we necessary the app, while it ran acceptably on the iPhone 4, was unacceptable slow on older units like the iPhone 3. The tricks he discusses are:

  • Using an image pipeline to serve the right image for older iPhones, retina iPhones and iPads
  • Using spriting — instead of sending a number of images, send a single large image made up of a bunch of images
  • Using 16-bit images with older devices to conserve memory

Links

Designing for Android: Tips and Techniques

Here’s a guide for designers to help them design for Android, whose ecosystem has many combinations of OS, screen size, aspect ratio and pixel density. In combination with the design guidelines on the Android Design site, this guide will help you make beautiful, usable Android apps.

Links

{ 0 comments }

A Mobile Privacy Policy You Can Use and Customize

Here’s a set of open source mobile privacy policies that you can copy, modify and use for your own mobile apps. Created by Docracy, an online store of open legal documents, you can use them as-is, or use them as a starting point for your app’s privacy policy. Most users consider the mobile device to be more personal than their desktops or laptops (even though they’re called personal computers), and it’s expected that privacy policies will eventually be required for apps; grab these and get a head start! Best of all, Docracy lets you fork their documents GitHub-style.

Links

ManiacDev’s Catalog of Open Source iPhone and iPad Apps

ManiacDev has updated their list of iOS apps for which the source code is available — there are now 85! 67 are currently available in the App Store, and while the remainder aren’t, they were at one time and you can still get the source for all of them. There’s nothing like learning from source code for complete, released applications, and I haven’t seen a bigger collection of such for iOS. If you’re interested in the source for games only, ManiacDev has a “just the games” list.

Links

TheNewBoston.com’s 200-Episode Android Tutorial Video Series

TheNewBoston.com has a video series made up of 200 videos covering Android development. The series starts with downloading and installing the JDK, Eclipse and the Android SDK, covers a lot of ground on writing Android apps, and ends with putting an app on the market and updating it. The presentation style is extremely casual and even made me chuckle a couple of times. I think it’s a pretty good launching point: use these videos as your launching point, back them up with the Android docs, and you’ll be on your way.

Links

Making Money in the App Store in “The Next 19%”

Dave Addey does some back-of-the-envelope calculations and says that while it’s increasingly unlikely for you to get your app in the top 1% of Apple’s App Store, you’ve got decent odds for getting your app into the sweet spot of what he calls “The Next 19%”.  He says that if the numbers he’s using are representative, the iOS App Store breaks down this way:

Tier How many apps? %age of Revenue Average income per app
Top 1% 6,500 36%, or $1.75 billion $269,230
The “Next 19%” 123,500 61%, or $3.05 billion $24,696
Bottom 80% 520,000 3%, or $150 million $288

 

He writes:

With the App Store maturing, hitting that top 1% increasingly requires sizeable investment and marketing in addition to app development skills. Successfully launching a 1% app (even with sizeable investment) isn’t something you’d bet your mortgage on, and I’d go as far as to say that this top end of the store is no longer a market that’s available to small independent developers.

The next 19%, however, is definitely a viable aspiration. Most of the paid apps we’ve released have fitted comfortably within the upper bounds of this part of the graph (beating the 19% average mentioned above), and these kinds of apps are definitely within reach of small development teams or sole developers.

Links

{ 1 comment }

Some Personal Notes

As I wrote earlier, I’ve declared a bit of a summer vacation for myself, but that doesn’t mean it’s been all fun and games and loafing about. I mean there’s been some fun and games and loafing about, but there’s also been a little work as well, what with lining up some conversations about work opportunities, updating the LinkedIn profile and old-school resume and of course, learning iOS development, which is what the Vaya con iOS series of articles is all about.

So, with my trusty MacBook Pro, iPad 2 and iPhone 4S, I got to work…

Just kidding — that’s not me.

As I said, with my trusty Mac and iTools, I got to work…

Okay, enough fooling around.

This is really me. I’m at the girlfriend’s place in Tampa. She goes off to work, while I start the day with an energizing swim at the central pool that almost no one in this townhouse complex seems to use:

Sixty to eighty lengths of the pool later, I emerge, shower, get dressed and then it’s time to get cracking:

She has a desk set up in her living room, which I’ve commandeered for my studies and other work. The laptop, mouse, iPad and phone are mine; Tux, the SUSE gecko, IBM bee and Sun dolphin (alas, it’s not in the shot) are hers.

A few people asked about the Nyan Cat sticker. I bought it at — I almost hate to admit this — Hot Topic (they have good pop culture stickers), cut it into two sections and laid it carefully around the trackpad.

iTunes U’s iPad and iPhone Application Development Course

There’s a pretty interesting iPad and iPhone programming course on iTunes U taught by Stanford’s Paul Hegarty. I enjoy his lectured and have watched the first three without zoning out or dozing off, which I must say is a damned sight better than some moments in my colourful academic career. I suppose not being hung over helps.

Over the course, which was recorded as it took place in the fall term of 2011, students were expected to build two complete iOS applications, with each lecture providing more material. There are 19 lectures in the series, which also includes some supplementary sessions as well as the slides for each lecture. It’s a Stanford computer science course without the Stanford tuition — it’s free! All you need is iTunes. If you decide to subscribe, be sure to get the 2011 course, as it covers iOS 5.

Ray Wenderlich and the iOS Apprentice

While researching blogs and other sites with useful information for developers with programming experience but little or no iOS development practice, I stumbled across Ray Wenderlich’s site. It’s updated regularly with new articles about various aspects of iOS development, and there’s also a regular email newsletter. One of the enticements for subscribing is that subscribers get a free tutorial — the first part of a tutorial series called The iOS Apprentice, written by Matthijs Hollemans.

I used to do Windows Phone tutorials back when I was a developer evangelist at Microsoft, and I was curious to see how someone else did it. So I signed up and soon afterwards, I got an email with the download link for the tutorial, a zip file with the tutorial in HTML form, plus XCode project files for the completed application and all the graphics and other resources needed.

I was impressed, especially because this was free. It’s on par with the NerdDinner tutorial for ASP.NET MVC, which I called the best “chapter one” I’ve ever read.

The tutorial is huge and it’s beautiful; it looks as if it was made by Apple. If you turn it into a PDF, it becomes a 117-page book, and it covers the development of a “Bull’s Eye” game, in which you try to position a slider as close as possible to a specified target value. In the process, you learn a lot: you get an intro to programming in general and XCode in particular, setting up UI controls and responding to events, dealing with different device orientations, adding a modal screen, customizing controls with your own graphics, giving your app an icon, dealing with regular and Retina displays, deploying your app to a device and more.

The tutorial was written for people who’ve never programmed before, but it does move pretty quickly. I wonder if complete novices get stuck in the process. However, I found it easy and skipped the parts in which programming concepts were explained, focusing more on the iOS-specific parts. I didn’t find the fact that it was written for beginners a bother, and I had a lot of fun in the process of following along. I even opened another project to noodle with the concepts I was learning from the tutorial.

In fact, I had so much fun with the Bull’s Eye tutorial that I decided to spend the $54 and purchase the rest. I’m currently on part 1 of the second tutorial, in which you build a reminder list app, which covers TableView-based applications. I found The iOS Apprentice more appealing and more packed with useful information than a number of iOS development books that I’d had the chance to read over and that it’s money well-spent.

If you’ve been putting off learning iOS development for whatever reason, go sign up for the newsletter at Ray Wenderlich’s site, get the first tutorial for free and give it a try. You might be pleasantly surprised.

{ 1 comment }

AppCode’s splash screen.

In my “summer vacation” post, I talked about the tools I’d be using to learn iOS development. One of them is the obvious choice: XCode, the Apple IDE, and the standard tool for developing iPhone and iPad apps. The other is a new tool, RubyMotion, which attempts to simplify iOS development with Ruby as the programming language and Rake as the primary build tool. Each has its pros and cons, and I thought that it would be interesting to learn iOS development through these two different tools and their different approaches.

James Kovacs, Tech Evangelist for the development tool company JetBrains — the people behind IntelliJ IDEA, RubyMine and ReSharper (quite possibly the most-loved Visual Studio add-on) — read my post and kindly offered me a free licence for AppCode, their IDE for MacOS and iOS development with Objective-C. In his email, he wrote:

No strings attached. Develop the next Angry Birds with it and make your millions. Wax poetic about it on your blog. Or bitch and complain about a missing killer feature. Or ignore it entirely and use Xcode exclusively. It’s really up to you.

Thank you, James! Consider AppCode added to my set of tools that I’ll be using while learning iOS development.

AppCode’s “Quick Start” screen. Click to see it at full size.

Having spent three years in the .NET world, I’ve become acquainted with Visual Studio. It’s one of the few Microsoft products that even the most ardent Microsoft-basher will say, often through gritted teeth, beats out all the others in its field. I agree; it’s an excellent IDE, and along with the underappreciated Windows Live Writer blog editing tool, is one of those precious few Microsoft tools that is consistently a pleasure to use.

Nice as Visual Studio is, it’s made even nicer by ReSharper, which adds a whole raft of utility features to Visual Studio. It takes so much drudgery out of coding that I know a number of developers who refuse to use Visual Studio without it (and a handful of purists who disdain those who use it, saying that they’re not really coding anymore). I’ve noodled a little bit with ReSharper, and liked what I saw. At the very least, it gives me some confidence that AppCode, coming from the same vendor, might have something going for it.

AppCode’s “Create Project” window.

XCode doesn’t get the same love that Visual Studio does. You’ll find many MacOS and iOS developers who like it enough and who’ll point out that it’s improved greatly over the past little while, but even the die-hard fans will say that it’s pretty clunky in places. That’s part of the appeal of alternative tools like RubyMotion, and I was curious to see how AppCode stacks up.

AppCode’s editor window. Click to see it at full size.

A little searching took me to The Code Sheriff, Yoni Tsafir’s blog, and an article in which he compared XCode to AppCode in a number of categories. AppCode wins in a number of categories, especially in those where you are doing a lot of straight-up coding: making quick fixes, refactoring, code completion and generation, keyboard shortcuts and code inspection. In other words, the sort of stuff with which ReSharper juices up Visual Studio.

AppCode doesn’t have an interface-building tool like Interface Builder, which is no longer its own app; it’s now part of XCode. I’m going to experiment with building apps with XCode alone along with taking a hybrid approach and bouncing between XCode and AppCode. That’s not all that different from bouncing between Visual Studio for coding and Expression Blend for UI, something which I did regularly when I was the Windows Phone evangelist.

So now it’s XCode, AppCode and RubyMotion. Thanks, James and JetBrains!

{ 1 comment }