Categories
Uncategorized

“RIM Speedwagon” Tells Developers in a Music Video That They’ll “Keep On Loving You”; Maybe It’s Time to Declare a Moratorium on These Things

9to5 Mac have pointed to a “LOLWTF” video by “RIM Speedwagon”, a band consisting of some RIM VPs including Alec Saunders (VP Developer Relations and Ecosystem. When I was at Microsoft as a Windows Phone Champ, I used to say “Well, at least my job is easier than Alec’s.”

Done to the tune of REO Speedwagon’s 1981 hit, Keep On Loving You, the song in the video is a message to developers: just hang on a little longer, and we promise that you won’t be disappointed.

I don’t think it was a good idea to pick a tune that was already retro when many of today’s mobile developers had yet to be conceived, but perhaps they’re aiming at the enterprise developer demographic, who are an older crowd. The song may resonate with those of us who grew up in the ’80s, but to the millennial crowd, it may cement BlackBerry as “the old folks’ phone”. I remember growing up in the ’80s and being annoyed at all the ’60’s nostalgia that the then-guardians of pop culture were shoving down our throats; surely it must be like that for the young’uns today as we expose them to old MTV era tropes.

Still, I have to say that cheese-tastic as RIM Speedwagon’s song is, it’s still a damned sight better than the Bruce Springsteen homage in this internal “Sell more Windows Vista!” Microsoft video aimed at their sales team:

Come to think of it, I think the only techie-focused music video featuring an ’80s tune that ever made any kind of good splash was Here Comes Another Bubble:

I think it’s time to declare a moratorium on these things.

Categories
Uncategorized

Mobile Developer News Roundup: Appcelerator/IDC Survey of Mobile Devs, 5 Reasons Why Responsive Design Isn’t Worth It, and Android Can Be Beautiful

Results from Appcelerator’s and IDC’s Mobile Developer Survey

In the Seattle Times’ column Microsoft Pri0, Janet Tu points to the latest quarterly survey report of over 5,500 mobile developers conducted by Appcelerator and IDC. Among their findings:

  • The developers surveyed were disappointed with building HTML5 mobile apps, citing poor user experience, performance and monetization.
  • One third of the developers surveyed said they were “very interested” in developing for Windows 8. The interest comes from the promise of being able to write applications that would work on both the desktop and on the soon-to-come Surface tablets.
  • Fewer than 10% of the developers surveyed said they were “very interested” in developing for BlackBerry. In January 2011, this number was 40%.
  • The developers surveyed believed that by 2015, they’ll be writing apps for more than just phones and tablets, but all manner of devices: TVs, connected cars, game consoles, smartwatches, Google glasses and so on.

Links

5 Reasons Why Responsive Design Isn’t Worth It


In 5 Reasons Why Responsive Design is Not Worth It, Tom Ewer argues that in many circumstances, there’s no need for a web site to be responsive since the desktop version works just fine. The five reasons mentioned in his article’s title are:

  1. It defeats user expectation, since the site can look quite different on a mobile device, hiding UI elements that the user might expect.
  2. It costs more and takes longer. This one’s self-explanatory.
  3. Non-responsive designs usually work. In many cases, all you have to do is rotate your phone to landscape mode.
  4. There is often no load time benefit. I don’t even consider this one of the benefits of responsive design, but some people do.
  5. It’s a compromise. “It is a subjective decision by the designer that the desktop display will not be optimal on mobile devices, followed up by a subjective decision as to what will be.”

Android Niceties Shows That Android Apps Can Be Beautiful

Android Niceties is a Tumblr that showcases “screenshots encompassing some of the best, most beautiful looking Android apps”. If you’re an Android developer or designer, you’ll want to visit this site often for inspiration.

Categories
Uncategorized

What the iPhone 20 and Galaxy S 23 Might Look Like Together

First came What the iPhone 20 Might Look Like. Now, this:

Categories
Uncategorized

Objective-C’s New NSNumber, NSArray and NSDictionary Syntaxes Mean Less “Yak Shaving” for iOS and OS X Developers


Yak shaving is a term used to describe a seemingly pointless activity that you actually have to do in order to get a larger task done, or as Jeremy Brown put it:

You see, yak shaving is what you are doing when you’re doing some stupid, fiddly little task that bears no obvious relationship to what you’re supposed to be working on, but yet a chain of twelve causal relations links what you’re doing to the original meta-task.

The term “shaving a yak” was used in the 1950 film Sunset Boulevard, but it’s more likely that its use in programming comes from Ren and Stimpy:

Many programming languages, especially those that pre-date modern scripting languages, often call on the programmer to do some yak shaving, and Objective-C is no exception. With XCode 4.5 and its new Clang compiler, you get some nice bits of syntactic sugar that I’m certain will make you say “Finally!” and save you from a fair bit of yak shaving.

NSNumber Literals

If you’ve been coding in Objective-C even just a little bit, you’ve probably come across NSString, the non-mutable string type used when developing for OS X’s Foundation framework. If you have, it’s likely that you’ve seen assignments that look like this:

NSString *myString = @"Hello, world!";

The @ is a handy bit of shorthand that specifies to the compiler that Hello, world! is an NSString literal. Without this bit of syntactic sugar, we’d have to write the above line of code like so:

NSString *myString = [NSString stringWithCString:"Hello, world!"];

Until now, there’s been no such syntactic sugar for NSNumber, Foundation’s type for wrapping numerical values in an object. It’s handy for doing things like wrapping numbers so that you can store them in collection classes like NSArray and NSDictionary, which can only store objects.

Until the current version of Objective-C (which comes with XCode 4.5), here’s how you’d assign NSNumbers given some numeric literals:

NSNumber *meaningOfLife = [NSNumber numberWithInt:42];
NSNumber *ussReliantPrefixCode = [NSNumber numberWithUnsignedInt:16309];
NSNumber *floatPi = [NSNumber numberWithFloat:3.14159];
NSNumber *doublePi = [NSNumber numberWithFloat:3.14159265358979];
NSNumber *avogadrosNumber = [NSNumber numberWithDouble:6.02214129E+23];

That’s a lot of work just to simply box a simple number type into an object. Luckily for us, Objective-C now supports NSNumber literals. Just as with NSString literals, NSNumber literals are preceded with the @ sign.

The code below uses NSNumber literals and is equivalent of the code above, but requires less typing and is easier to read:

NSNumber *meaningOfLife = @42;
NSNumber *ussReliantPrefixCode = @16309U;
NSNumber *floatPi = @3.14159F;
NSNumber *doublePi = @3.14159265358979;
NSNumber *avogadrosNumber = @6.02214129E+23;

Array Literals, NSArray, and NSMutableArray

Initializing NSArray and Accessing Its Elements the Old Way

If you’re coming to Objective-C from languages like JavaScript, Python or Ruby, you’re used to doing array assignments using literals.

Suppose you wanted to create an array containing the first names of the members of the Stark family from Game of Thrones. Here’s how you’d do it in Python and Ruby (and in JavaScript, as well, although you’d probably want to place the var keyword before starkFamily):

starkFamily = [
    "Eddard",
    "Catelin",
    "Robb",
    "Sansa",
    "Arya",
    "Bran",
    "Rickon"
]

There used to be no such thing as an NSArray literal. Here’s how you’d create the array above using Objective-C and NSArray — using the arrayWithObjects: method, which expects a comma-delimited list of objects terminated with nil.

NSArray *starkFamily = [NSArray arrayWithObjects:
    @"Eddard",
    @"Catelin",
    @"Robb",
    @"Sansa",
    @"Arya",
    @"Bran",
    @"Rickon",
    nil
];

It’s not that much more typing, but you have to remember to mark the end of the list with nil.

What’s far more unwieldy is array access. In JavaScript, Python and Ruby, if you wanted to access the element of starkFamily whose index is 2, you’d do it this way:

starkFamily[2]

In earlier versions of Objective-C, here’s how you’d access that element:

[starkFamily objectAtIndex:2]

Wow, that’s clunky. Even with XCode’s autocomplete feature (the analogue of Visual Studio’s Intellisense), it’s still a lot of typing for something as simple as array element access.

Initializing NSArray and Accessing Its Elements the New Way

With the latest version of Objective-C, we have NSArray literals. Here’s how you’d initialize the starkFamily array using an NSArray literal:

NSArray *starkFamily = @[
    @"Eddard",
    @"Catelin",
    @"Robb",
    @"Sansa",
    @"Arya",
    @"Bran",
    @"Rickon"
];

NSArray literals look almost like JavaScript, Python and Ruby array literals. The big difference is NSArray literals begin with a @ character, just as NSString and NSNumber literals do.

As for accessing elements from NSArrays you can now do so using a more familiar notation:

starkFamily[2]

Finally! I much prefer myArray[index] over [myArray objectAtIndex:index].

Initializing NSMutableArrays Using Array Literals

NSArray is an immutable type; once initialized, you can’t reassign, add, or remove any of its elements. NSMutableArray, a subclass of NSArray, is mutable. Here’s how you initialize an NSMutableArray using an NSArray literal:

NSMutableArray *starkFamily = [@[
    @"Eddard",
    @"Catelin",
    @"Robb",
    @"Sansa",
    @"Arya",
    @"Bran",
    @"Rickon"
] mutableCopy];

In the code above, we create an NSArray using an array literal and invoke NSArray‘s mutableCopy: method on it. The result is an NSMutableArray containing the array literal’s values.

As with NSArray, you can now access elements of an NSMutableArray using standard array notation…

starkFamily[2]

…and, of course, since the array is mutable, you can do stuff like this:

starkFamily[2] = @"Tony";
[starkFamily removeObjectAtIndex:0];

Dictionary Literals, NSDictionary, and NSMutableDictionary

Initializing NSDictionary and Accessing Its Elements the Old Way

Different programming languages use different terms for what’s roughly the same thing: an object that stores values which you can look up using keys. JavaScript keeps it simple by using objects for this task, Ruby has hashes and Python has dictionaries.

Consider the following Python dictionary definition:

importantNumbers = { 
  "Meaning of life" : 42, 
  "USS Reliant prefix code" : 16309, 
  "Single-precision pi" : 3.14159, 
  "Double-precision pi" : 3.14159265358979, 
  "Avogadro's Number" : 6.0221415E+23
}

Ruby’s hash syntax is similar:

importantNumbers = { 
    "Meaning of life" => 42,
    "USS Reliant prefix code" => 16309,
    "Single-precision pi" => 3.14159,
    "Double-precision pi" => 3.14159265358979,
    "Avogadro's Number" => 6.0221415E+23
}

If you wanted to access the number associated with the key Meaning of life in either Ruby or Python, you’d do it this way:

importantNumbers["Meaning of life"]

In Objective-C, the equivalent structure is the NSDictionary class. Here’s the old-school Objective-C equivalent to the code above. Since NSDictionary stores only objects, we have to wrap the numbers in NSNumbers using the new literal syntax:

NSDictionary *importantNumbers = [NSDictionary dictionaryWithObjectsAndKeys:
    @42, @"Meaning of life",
    @16309U, @"USS Reliant prefix code",
    @3.14159F, @"Single-precision pi",
    @3.14159265358979, @"Double-precision pi",
    @6.0221415E+23, @"Avogadro's Number",
    nil];

Note that the list have to provide the dictionaryWithObjectsAndKeys: method lists the value first and the key second, which is the reverse of how most other programming languages do it. As with NSArray‘s arrayWithObjects: method, we have to mark the end of the list with nil.

If you thought the code above was a bit much, imagine what it would look like without NSNumber literals!

As for accessing values in the dictionary, here’s the old way of doing it:

[importantNumbers objectForKey:@"Meaning of life"]

That’s a lot of typing just to get to a value.

Initializing NSDictionary and Accessing Its Elements the New Way

Luckily, the Objective-C that you get with XCode 4.5 gives us dictionary literals. Here’s how you define importantNumbers now:

NSDictionary *importantNumbers = @{
    @"Meaning of life" : @42,
    @"USS Reliant prefix code" : @16309U,
    @"Single-precision pi" : @3.14159F,
    @"Double-precision pi" : @3.14159265358979,
    @"Avogadro's Number" : @6.0221415E+23
};

That’s much better. Languages like JavaScript, Python and Ruby have standardized curly braces ({ and }) for specifying dictionary-style collections, and it’s nice to see this syntax in Objective-C. The order is also what we expect: key first, value second. And finally, no need to use nil to terminate the list.

The syntax for accessing a value from an NSDictionary is also much simpler:

importantNumbers[@"Meaning of life"]

Much better.

Initializing NSMutableDictionary Using Dictionary Literals

Like NSArray, NSDictionary isn’t mutable, but it has a mutable subclass with a similar name. It’s NSMutableDictionary, and like NSArray, you can use a literal and the mutableCopy: method to create one:

NSMutableDictionary *importantNumbers = [@{
    @"Meaning of life" : @42,
    @"USS Reliant prefix code" : @16309U,
    @"Single-precision pi" : @3.14159F,
    @"Double-precision pi" : @3.14159265358979,
    @"Avogadro's Number" : @6.0221415E+23
} mutableCopy];

As with NSDictionary, you can access elements of an NSMutableDictionary using the new syntax:

importantNumbers[@"Meaning of life"]

And since it’s mutable, you can make changes:

importantNumbers[@"Meaning of life"] = @43;
[importantNumbers setObject:@2012 forKey:@"iOS 6 launch year"];

Available Now, and Not Just for iOS 6

The latest version of XCode, 4.5, includes the latest Clang compiler, which supports these new syntaxes. Since they’re syntactic sugar and not part of any additions or revisions to the Foundation framework, you can use them in any iOS project.

Better still, if you’ve got old projects that you’d like to update to use these new syntaxes but dread having to do so manually, XCode 4.5 has a feature you’ll like. Under the Edit menu, you can select Refactor, and inside that submenu is the Convert to Modern Objective-C… command.

Categories
Uncategorized

Meanwhile, in Japan…

Ginza District, Tokyo, Japan: I’m not sure if the guy on the right is waiting for an iPhone 5 or a katamari.

Categories
Uncategorized

The London Underground’s Advisory for iOS 6 Users

Ouch.

Categories
Uncategorized

Mobile Developer News Roundup: The Amazing iOS 6 Maps, iPhone 5 Lines, Why You Should be an iOS Developer and the iOS 6 Feast

The Amazing iOS 6 Maps

The Amazing iOS 6 Maps is a Tumblr devoted to showcasing the shortcomings of the new Maps application in iOS 6.

I’ve also enjoyed this twist on the “Condescending Wonka” meme:

iPhone 5 Lines and Samsung’s Response

Here’s a photo of an iPhone 5 line in Australia posted by @iFixit at 3:55 p.m. EDT:

Here’s the same line an hour later, with the sun having risen:

There are similar lines in the other eight countries where the iPhone 5 will be available at Apple Stores on Friday.

Anticipating this sort of response (and probably stinging from being called out as copycats and getting a one billion dollar speeding ticket for doing so), Samsung have put out this rather funny ad mocking the sort of Apple fan who lines up for the latest iDevice:

Matt Campbell on iOS Development

Matt Campbell, author of the excellent book Objective-C Recipes and the Mobile App Mastery site, mailed out this advice to subscribers to the Mobile App Mastery mailing list:

I’ve been getting all kinds of questions about being an indy app publisher and mobile apps in general. Let’s see if I can answer some of these now.

Do I Need To Quit My Job?

Not at all. Once you are comfortable with iOS development you can build an app in your spare time. Mobile app development with iOS particularly is probably much less complicated that what your are used to. This actually makes it ideal as a side project.

In fact, I had two apps developed and going strong before I quit my job. The nice thing about iOS as a side gig are that it’s like giving yourself a bonus whenever you want while keeping your secure paycheck.

It’s really up to you when it comes to this. I quit because I was determined to start my own business (with or without mobile apps).

Is iOS, Windows or Android The Best?

These are all great mobile platforms and there are more – you can even make mobile web apps. I recommend iOS for a few reasons:

iOS is the easiest system because it is closed. You don’t need to worry about the hardware and you can focus on the code. You must use things from Apple’s vertical stack and this makes it very easy to use.

Apple has the best customers. Almost everyone I know who developers for multiple platforms agree that the Apple app store customers are the best.

Apple is vertically integrated. It’s frankly a no-brainer to port your iPhone app to the iPad and Mac appstores potentially tripling your revenue. They all use the same programming language and iPad and Mac are as easy as iPhone to develop for.

How Hard Is It To Learn iOS, Really?

I won’t lie – learning iOS development at first is daunting even for experienced programmers. It’s because the patterns are so different than what most of us were used to. I went at it alone and it took me a good three months to get started. Of course you can cut down on that time these days and I’ve been able to get developers up to speed in a matter of days with iPhone Boot Camp.

All that being said – once you learn iOS it becomes almost absurdly easy to develop and publish apps. One day you will “just get it” and after that it really does become second nature. Most developers who work with iOS fall in love with the system (me included).

Ray Wenderlich’s iOS 6 Feast

Ray Wenderlich’s site on iOS development — you should have it bookmarked if you’re even thinking about writing iOS apps — has announced the iOS 6 Feast, a smorgasbord of information and tutorials for developers looking to dive into the latest version of iOS. Check it out — you don’t want to miss it!