Nowadays, the preferred way to expose class attributes in a number of languages is through public properties. With them, we’re back to accessing object attributes through this simple syntax:
previousSpeed = myCar.speed;
myCar.speed = 50;
What @synthesize Was For
Creating properties in Objective-C classes used to require statements in a couple of places. For a public property, you had to declare it in the interface (.h) file:
@interface Car : NSObject
@property int speed;
The @property statement tells the compiler that you want to expose a property; in the case of the code above, the name of the property is speed. Properties are by default both readable and writeable. If you like to spell everything out very explicitly, you can by declaring the property this way:
@property (readwrite) int speed;
If for some reason you wanted speed to be read-only, you can declare the property this way:
@property (readonly) int speed;
With every property declaration comes the need for the underlying instance variables — ivars in Objective-C parlance — and the requisite getter and setter methods, which go in the implementation (.m) file. All this setup for each property can get a little tedious, and the @synthesize statement saves you from that tedium. Instead of having to declare the corresponding ivar and write those methods, @synthesize lets you do all that in a single line of code:
By default, the name of the ivar created by @synthesize was the name of the corresponding property preceded by an underscore character. For example, the default name of the ivar behind a property named speed would be _speed. If you preferred, you could specify a different ivar name this way:
The general rule was that if you only needed a simple getter and/or setter for a @property, use @synthesize.
The version of CLang (the Objective-C compiler) that comes with XCode versions 4.3 and later (the latest version is 4.5), supports autosynthesis, which automatically does the synthesizing for any class properties you declare in the header. If your @property needs only a simple getter and/or setter, you don’t need to have a corresponding @synthesize anymore. The compiler takes care of that for you.
Properties with autosynthesis work like they did with manual synthesis. You access them using the self.propertyName syntax, and the name of the ivar that gets generated is still the name of the property preceded by an underscore character.
3rd Place is a disturbing yet amusing coloring book really meant for adults.
Click the photo to find out more.
A conversation I had with a friend circa April 2011, shortly after I posted this article:
Friend: So why’d you leave? Was it the money?
Me: Are you kidding? The money’s awesome. In fact, the money’s making it hard to leave.
Friend: It was the incident*, was it?
Me: Actually, no. Even right after “the incident” [I made "air quotes" with my fingers while saying this], I was quite sure I was going to stick around for a while.
Friend: So what was it, then?
Me: A bunch of things. After everythingthat’s happened, I figured I was due for a change. Plus, there’s the whole being-the-Windows-Phone-guy thing. I’ve done too many 14-hour days and a lot of slogging around for what? A distant third place…if we’re lucky.
* The incident is a good story, best told in person over drinks.
Just like as the white zone at the airport is for loading and unloading only, my left pocket is strictly just for my iPhone (still a 4S — I got it in November, and I’ve no compelling reason to upgrade yet). That way, there’s considerably less chance for it to get scratched. Even so, I keep my iPhone in a case, even if Darth Gruber disapproves.
Click the photo to see the source.
With the iPhone 5, Apple ditched the “glass sandwich” design in favour of aluminum. The problem is that customers have noticed — and remember, it been available for less than a week – is that it scuffs, scratches and even chips a little too easily.
…I have a US$20 cast iron skillet that I bought several years ago from a restaurant supply shop in downtown Manhattan. I’ve cooked hundreds of meals with it, and over time it has developed a coating from oil and food — the manufacturers call it ‘seasoning.’ It’s a little unbecoming when you think about it; in fact, though I clean it, it’s a dirty piece of cookware, and it resembles its original, store-bought state not at all.
…After cooking in it and cleaning it up, I’ve spent a lot of time just looking it over, marveling at how its very deterioration has been incorporated into the design of the object, at how it’s gotten more attractive — less ignorant — the more I use it. I’m not particularly sentimental about much in my kitchen, but I would be heartbroken if you took away this iron skillet…
He compares it to his technological goodies, for which the opposite is true:
I mention these things because I’ve noticed recently that the concept of what we might call designed deterioration is fairly anathema to digital hardware. The objects we purchase from purveyors of digital technology are conceived only up to the point of sale; the inevitable nicks, scratches, weathering, and fading they will encounter is not factored in at all. The result is that as they see more use, their ignorance may recede, but they wear it poorly. They don’t age gracefully.
Looking at the digital technology I own, what moderate deterioration to be found — dents in my laptop, a gash in the side of a laser printer I own, the accumulated grime on my computer keyboard — doesn’t make these items more desirable at all. In fact, when I see the way the corner on my aluminum PowerBook has been warped due to a nasty fall from a chair, I cringe. Through this obvious, glaring example of use, of accumulated knowledge, the object itself hasn’t attained an additional whit of beauty.
In fact, the damage is actually quite repulsive. This is because the laptop was conceived by Jonathan Ive based on an assumption that it would remain perfect forever. There was no designed deterioration factored in whatsoever, and so no real thought was given to how the laptop might change with use. Marks of knowledge, like the warped corner, aren’t meant to be embraced, but rather denied.
He also astutely observes that if you designed things like iPhones to look better with age and use, you’re discouraging people from upgrading to a newer model.
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.
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.
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:
It defeats user expectation, since the site can look quite different on a mobile device, hiding UI elements that the user might expect.
It costs more and takes longer. This one’s self-explanatory.
Non-responsive designs usually work. In many cases, all you have to do is rotate your phone to landscape mode.
There is often no load time benefit. I don’t even consider this one of the benefits of responsive design, but some people do.
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.
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.
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:
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:
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:
Initializing NSArray and Accessing Its Elements the Old Way
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.
As for accessing elements from NSArrays you can now do so using a more familiar notation:
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:
Dictionary Literals, NSDictionary, and NSMutableDictionary
Initializing NSDictionary and Accessing Its Elements the Old Way
Consider the following Python dictionary definition:
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:
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:
The syntax for accessing a value from an NSDictionary is also much simpler:
importantNumbers[@"Meaning of life"]
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:
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.