Matthew Tonkin - Cocoa Engineer

Mobile Engineering Quality

noreply@blogger.com (Matthew Tonkin) — Tue, 12 Jul 2011 12:57:00 +0000

Android vs iOS. Plenty of debates about this topic and plenty of opinions. So here's mine...

I can't help but consider which platform has the most solid engineering. Which platform is more refined for its purpose. Good engineering is evident in attention to detail. The virtues of consistently exceptional engineering are very difficult to instill and maintain in an organisation.

I've been to WWDC (many times) and to Google I/O (even spoke there) and my firm impression is that from an engineering perspective iOS is far more refined. I've had conversations with very smart engineers in both camps. I've attended and watched more WWDC and Google I/O video sessions than anyone should. There are loads of small points I've picked up from these discussions and sessions that make iOS the platform I have the most faith in - the one I believe is better engineered. I'm going to call out 2 of them...

1 - Battery life: It's like everyone at Apple who has ever written code for iOS has been brutally beaten with a "must preserve battery life" stick several times a day until they understood. It's almost impossible to have a conversation with an Apple engineer without them bringing up battery performance as a reason for some design decision or coding practice in iOS. It's like a nervous tick, but executed with confidence.

I recall speaking to Apple engineers at WWDC in 2008 who went into some considerable detail on how managing retain / release / autorelease for objects could have a positive effect on battery life. I recall the first WWDC session on how to use the accelerometer and the comparison of starting / stopping the accelerometer hardware compared to short and long term use. I recall sessions on why you shouldn't override drawRect: in a UIView subclass because it had some nominal yet demonstrable drain on battery.

It's really hard to instill this kind of attention to detail across an organisation - to get everyone thinking about the stuff that matters. Battery life matters. Android battery life sucks. Apple engineering has an incredible attention to detail that makes things like battery life not suck. Battery life is just an example of one area where Apple's superior engineering practices are evident to everyday users. It's really easy to screw up, it's really easy to cut corners and make devices that only last 19 hours on the best day you've ever had. Apple engineers don't screw up battery life and they work hard to make sure 3rd party engineers don't either.

2 - IDE: Xcode wins.

It's rare to be able to make such a forthright statement without need for justification, but I doubt anyone's going to argue. Xcode wins. From a third party developer perspective the richness of the system API's are pretty important, but it's not just what's in the technology stack and what API's one has available to them - it's how easily one can makes software that utilize them. Xcode makes it easy to create software for iOS. Documentation, static analysis, provisioning, instruments, etc. Xcode wins. It takes engineering discipline to make a product that rocks as well as Xcode.

Android and iOS both appear to be in "adding features mode". There's a big difference between adding features and adding features well. Adding features well requires an attention to detail for things like error handling, network latency and dealing with corner cases that few people ever considered.

In my experience engineering quality is consistent across an organization (at least at the macro level). It's rare to have a group of engineers turning out exceptional quality in the same organization as a group of engineers turning out crap. They are mutually opposing forces and one will destroy the other. So when I find a couple of areas where iOS has been engineered so well, I have considerable faith that all areas are developed almost as well or even better.

Tablet Bloodbath

noreply@blogger.com (Matthew Tonkin) — Sun, 27 Feb 2011 22:49:00 +0000

I bought an Android Tablet (the Motorola XOOM) on Friday.

During the process at Best Buy it struck me the upcoming 'Tablet War' will bear an uncanny resemblance to the PC market. Motorola won't compete with Apple in the Tablet market any more than Acer competes with Apple in the PC market.

When consumers go to Best Buy to get a Tablet they'll ask themselves 2 questions:

Q1: "Do I want an iPad or an Android?"

Q2: "If I want an Android then which one do I want? Motorola, Samsung, Asus, Dell...."

Motorola's biggest competition will be Samsung, Acer, Dell and anyone else who releases an Android tablet (and boy there's a lot of them). Competition with Apple is a secondary problem for these guys at best.

In theory, it's Google vs Apple. The tech tabloids and industry boffins are eating that stuff up because it's interesting for industry people to analyze, debate and pontificate over.

In practice, it's comes down to manufacturing, distribution and the showroom - where Google is a logo on a box at best. You'll soon be able to see Apple standing tall in one corner of Best Buy and every other tablet manufacturer fighting a brutal battle against each other in another corner. When it comes down to it - Motorola and Samsung will soon be busy one upping each other on hardware features and under cutting each other on price. Apple will have the best seat in the house during the upcoming tablet bloodbath.

Sure, there might be cheeky ad campaigns that try to pitch Apple against Manufacturer X and plenty of industry analysts comparing Google vs Apple, but when it comes to the showroom floor it will be Motorola, Samsung, Acer and Dell sucker punching each other until the weak ones get out of the ring.

I don't see Apple doing much other than continuing on their own merry way while the bevy of Android Tablet manufacturers beat each other up. An uncanny resemblance to the PC market where Apple is extremely profitable and the 'competition' has either been eaten up (Compaq, DEC, IBM) or is surviving on ridiculously thin margins (Dell, HP, Acer).

The technology might be new, but the story of Apple vs Android is neither new or even very interesting. Apple vs HP on the other hand is behemoth vs underdog and one should never ignore an underdog.

Yours truly speaking at Google I/O 2010

noreply@blogger.com (Matthew Tonkin) — Thu, 03 Jun 2010 23:05:00 +0000

Skip ahead to 19:00 for the good bits (me)...

http://code.google.com/events/io/2010/sessions/connecting-enterprise-apps-docs-sites.html

De-emphasizing Mac OS at WWDC?

noreply@blogger.com (Matthew Tonkin) — Fri, 30 Apr 2010 17:40:00 +0000

WWDC 2008: Offered sessions on transitioning Mac developers to iPhone. Makes sense. iPhone OS was a new platform with few developers at the time - why not throw the Mac developer community at the iPhone.

WWDC 2009: Offered sessions on transitioning iPhone developers to Mac. That was a surprise to most, but again makes sense because during the previous year the Cocoa Touch developer community exploded and why not throw a few of them back to the Mac.

WWDC 2010: Evidently it's about iPhone OS.

But is it? Clearly not everyone is happy about Apple's strong iPhone OS emphasis at WWDC this year. But maybe it isn't about iPhone OS maybe it's about Cocoa Touch?

Cocoa is the development frameworks for Mac OS.
Cocoa Touch is the development frameworks for iPhone OS.

Is there a difference between iPhone OS and Cocoa Touch? Hell yeah there is. There's no reason Cocoa Touch can't be part of Mac OS. Cocoa Touch is a damn fine environment to develop software for devices with a multi-touch screen interface (by 'damn fine' I mean nothing else comes even close).

Let's not assume that multi-touch screens are exclusively for this new 'mobile era'. Sure that might be the driver of multi-touch screens, but I can't see them staying there. If we get a multitouch screen on a Mac, then we should get Cocoa Touch too - and all those wonderful iPhone developers have a place on the Mac.

Don't think a multi-touch screen has any business on a Mac? Matt Gemmell's dad seems to think it does

Apple throwing the developer community behind iPhone OS might just be a front to transitioning us to developing in Cocoa Touch - for iPhone, iPad and Mac. Glory glory hallelujah.

For a more in-depth analysis see my previous post on UIKit in 10.7

UIKit in 10.7?

noreply@blogger.com (Matthew Tonkin) — Sun, 18 Apr 2010 00:11:00 +0000

Disclaimer: The following is nothing but pure speculation...

UIKit in 10.7 would mean an iPhone like environment on a touch screen Mac - even iPhone apps themselves. Seems nuts, but reserve judgement until the end.

First, a little background in Mac OS X / iPhone architecture...

Mac OS X and iPhone apps share a common underlying framework - Foundation. However, each platform has it's own application layer.

iPhone OS has UIKit = CocoaTouch

The UIKit framework contains the Application layer for iPhone apps. This includes the visual interface and user interactivity bits that makes the iPhone the iPhone. This is where touches, views, images, gestures, tables, controls and that other fun iPhone stuff lives.

Mac OS 10.0 - 10.6 has AppKit = Cocoa

Mac OS X's equivalent is AppKit and has views, windows, images, open panels, tables, controls, mouse pointers, printing etc.

The key architectural difference between Mac OS and iPhone OS is that neither has the other's application layer framework. There's no AppKit in iPhone and there's no UIKit in Mac OS X. Seems logical - what would the iPhone OS need with a save panel - after all the user interactivity is entirely different between the 2 platforms.

Good logic - Until you put a touch screen on a Mac in which case things change.

Could Mac OS 10.7 have both?

Some may argue that a Touch Screen Mac doesn't make any sense ergonomically - but what's the difference between that and an iPad with a keyboard dock?

The grab...

UIKit on Mac OS X is a very good choice if there ever is a touch screen Mac - and maybe even if there isn't. Here's why:

1. It's built for finger input

If the iPad is just a big iPod Touch, then an iMac with a touchscreen is just a big iPad. If you had told me a few months ago that UIKit was a possibility in Mac OS - I'd have laughed at you (perhaps the way some of you are laughing at me now). All of this changed with the iPad though - which has proven that UIKit (primarily the user interface) can scale up to much larger devices. It's a much smaller step to take UIKit to the Mac than it was to take it to the iPad. UIKit is the thing that makes touch input really really rock. Why wouldn't you use UIKit on a touchscreen Mac - I simply don't see what other choice there is. Sure you could bring touch stuff to AppKit (and it already exists in a sense) but why bother?

2. UIKit is more modern than AppKit

There's some brilliant design in UIKit (it's an evolution of AppKit after all) for example UIViewController, everything visible being subclasses of UIView and lots and lots of small decisions that make UIKit a pleasure to code for. More app for less code is always a good thing.

3. Third party developers

There's over 180,000 apps for the iPhone. I'm not sure how many apps are available on Mac OS, but I'm sure it's a LOT less than that. There's a huge amount of code and big investment being made in iPhone code - investment that most often can be leveraged on the Mac too. The availability of more apps on the Mac is a good thing - no matter what way you slice it. Everyone wins - users, developers, Apple.

4. The AppStore

Whatever you want to take away from the AppStore is irrelevant in the light of it working so damn well. Users get apps, developers sell apps and it's all so darn easy. Argument over. Bringing the AppStore to the Mac would be very welcome. Anything you throw at the AppStore is easily deflected by how well the model of having an AppStore on the platform works. Would the iPhone or iPhone app developers be as successful without the AppStore? I doubt it would come even close. Would the iPhone be as compelling without the AppStore? I doubt that too. Will and AppStore with 200,000 apps be awesome on the Mac platform? No doubts there.

5. A lot of iPhone apps are already usable on standard Mac hardware today

How do I know that? The simulator. Apple launched the iPad with thousands of applications, most of which had never been used on the actual device. Even using a mouse input instead of a touchscreen, the UIKit app environment is damn usable. There are so many iPhone apps that I wish I could have in my iPhone simulator and just use as apps on an everyday basis.

They'd be even better with a touchscreen, but they already work well enough to be useful.

Let's be clear that I'm not suggesting UIKit will replace AppKit anytime soon (or ever) - that simply doesn't make sense. I'm making the argument that having UIKit as an option on Mac OS makes an insane amount of sense - if you have a touch screen (and only slightly less sense if you don't).

Some Q&A….

Q. Would developers need to invest much time to bring their iPhone app across?

A. Probably just recompile. Unless they did something stupid - like violated iPhone SDK 4 term 3.3.1 and used an intermediate library like Flash to iPhone.

Q. Well what would happen to my other applications in Mac OS X - can I print and use my mouse and stuff?

A. Of course. AppKit and the traditional application environment can still exist quite happily. Maybe launching a UIKit app just goes modal - like FrontRow, which notably doesn't have a mouse either.

Q. Wouldn't that take a lot of work?

A. No. That's what the simulator does now. It runs UIKit on the Mac. Job done.

Q. But the iPhone / iPad runs on ARM and the Mac uses an x86 processor. Doesn't that pose a problem?

A. Evidently not for Apple and their Universal Binaries. These were introduced back in the PPC to x86 switch, but are still very much in use today. Todays apps that are compiled for 32 and 64 bit x86 processors are using a universal binary. You can even do PPC / x86 and 32 / 64 bit apps - all 4 permutations of which exist in the same universal binary. Right now apps that run in the simulator run as x86 apps whereas apps that run on the device rum as ARM apps - so the hard work is already done. Creating a Universal Binary containing both x86 and ARM code would be a walk in the park for Apple's engineers.

Q. Wouldn't you need an accelerometer or rotation or something?

A. Not necessarily. Sure some apps need it, but many many don't. Some apps need a camera, some need a GPS, some need a magnetic compass. It won't mean all iPhone apps will be available for the Mac - the same way not all iPhone apps are available for the iPod Touch.

Q. What about the extra screen real estate?

A. That became a non-issue with the iPad. Building apps for dynamic screen sizes is now a given when creating apps for the iPhone OS. Did you really think Apple were going to use 320x480 screens forever?

Xcode + iPhone SDK: The unsung hero of 100,000 apps

noreply@blogger.com (Matthew Tonkin) — Sat, 07 Nov 2009 21:47:00 +0000

March 6 2008, Apple covered their roadmap for the iPhone SDK: http://www.apple.com/quicktime/qtv/iphoneroadmap/

That was JUST 20 months ago. Unbelievable.

Since then we've all gotten caught up in the AppStore hysteria, overnight millionaires (maybe), 100,000 apps and average Joes (or Janes) developing apps for the iPhone. This is a positively enormous change for mobile application developers, traditional Mac developers and mobile entrepreneurs.

Xcode and the iPhone SDK make all this possible. It's not just a toolkit to allow you to build apps for the iPhone, but an incredibly well crafted suite (lets not forget Instruments) that is designed to allow developers to do what they do best: develop something to meet their business problem.

Everything about Apples developer tools and Frameworks scream "focus on what you're trying to achieve with your software, we'll take care of all the mundane stuff". 1 button is all it takes to get your software compiled, installed on a device and running in debug. This doesn't come as a surprise to any of the 'old school' OS X developers, but sometimes we need to be reminded about how awesome this toolkit is and how much we take it for granted.

The economist in me continually nags that any time I waste messing around with development tools is time I'm not spending on making my software better. If Xcode and the iPhone SDK were pigs to work with, then we'd still have software, there just wouldn't be as much and it wouldn't be as good.

You could even go so far as to suggest that the iPhone SDK has created a significant competitive advantage and barrier to entry in the now hotly contested market of third party application development for mobiles. The iPhone SDK has a long and rich heritage rooted deeply in the NeXT era, it's not something you can just knock out in a few months.

Sure, there will be SDK's for those other devices, but will they be as good? I guess time will tell, but I wouldn't bet on it.

OmniStats, Gruber and 10.4 Support

noreply@blogger.com (Matthew Tonkin) — Wed, 23 Sep 2009 05:14:00 +0000

John Gruber of Daring Fireball has a great discussion (as always) on Mac OS X major version use:

DF Stats

Omni

Adium

The 10.4 usage (36.4%) for Omni seems very high and developers might factor this into their decision to continue supporting 10.4. However it can be argued that Omni stats are skewed due to the Apple bundling agreements that existed while 10.4 was being shipped (these agreements ended before or early in the 10.5 era). All Mac hardware shipped with OmniGraffle during 10.4 (but not during 10.5) so the overall market share of 10.4 is probably lower.

If you're a developer (and according to Gruber 11.2% of his readers are) you might not be fortunate enough to be calling your own shots and have some 'platform agnostic' marketing guy or product manager telling you that you must support 10.4 because it's a significant portion of the market or your partners need it.

Supporting 10.4 is probably a bad move for most developers at this point (unless developing for education - maybe). Here's how to argue the case for 10.5+ against someone not fluent in the Mac platform.

1. Your software won't be as good if you're developing for 10.4

The economic problem is always the same - limited resources and unlimited needs. Whilst you can work around 10.4 limitations, doing so means you've got less resources allocated to other things - like solving your business problem better. There's some really cool tech in 10.5 - from the big stuff like Core Animation and NSOperation to the small stuff like gradients and bezier paths with rounded corners. Your software will almost always be better from using these newer technologies.

It's not just the development effort either, you need to QA and support 10.4 too. That really sucks for the poor schmucks who have that job (probably one of whom is you).

Make the choice: Do you want to make good software for 10.4+ users or great software for 10.5+ users? If you're still thinking you can do both, then re-read the above until you realise by definition you can't. Your software will always be better if you develop for 10.5+ because you'll have more resources to spend on solving your business problem better or making your software easier to use.

For many products, you'd get more users from better software than you would from legacy OS support, but that argument really hinges on how many users (particularly paid ones) you're likely to get from supporting an older OS, so market share stats might be important.

2. Current market share

There's no definitive source of how much of the overall market is 10.4 or 10.5+. Omni's stat (36.4%) are probably skewed towards 10.4 due to the old Apple OEM deal and Adium's stats (15.3%) are probably skewed towards an 'early adopter' crowd who stick with the latest OS. So let's assume the overall 10.4 market share is between 20% and 30%.

3. Future market share

By the generous Omni stats, 10.4 is showing a roughly linear decline from 50% on 1 Jan 2009, translating to a decline of 18% per annum. In a year from now, 10.4 will be really inconsequential. You'll need to make back all of your extra costs from these users the next year*, or you're at a loss. This isn't just the explicit costs like development, QA & support, it's the implicit costs too - like your software not being as good. Add to that the future costs of updating to newer technologies in 10.6 like Grand Central that are automatic if you use NSOperation (which is included in 10.5).

*If you're at the stage of deciding whether to support 10.4 or not, then it's probably a few months before your software ships anyway so you need to take into account what the market will be when you launch the software.

4. The OS market share argument is rubbish

Just like the Windows vs Mac market share rhetoric, the total market % isn't important anyway. What's important is the market share of users in your target / addressable market.

Think about it… Any consumer** using 10.4 is probably too frugal to buy Apple's software, a late adopter or using an old system. Do you really think they are going to install and (more importantly) buy your software?

**You'll notice the emphasis is on consumers. There are still some big educational customers with 10.4. If this is the case for you, then you should probably take the decline in market share into account and make an assessment based on that. You might still be stuck with 10.4 for a while longer, but make an informed choice.

But what if I already support 10.4?

This stuff is all still relevant. If you're keeping your software up to date, then you'll probably realise a lot of this already.

As Wayne Gretzky said "skate to where the puck is going to be", this is still relevant to all of your current and future development efforts.

Conclusion

There are some 10.4 users and some of them might buy your software, but are there enough to regain the costs, time and headaches of developing for 10.4 worthwhile?

Coolest thing I learnt at WWDC 2009

noreply@blogger.com (Matthew Tonkin) — Mon, 24 Aug 2009 03:55:00 +0000

Cocoa's support for KVO and Properties is awesome, but every now and then I find something I can't do. I frequently use 'derived' properties, where a read only property is derived from a combination of instance variables. For example, we might have an object with firstName and lastName, then want a KVO compliant fullName.

Cocoa did offer some support for this in your own classes by doing a willChangeValueForKey: and didChangeValueForKey:. The real challenge comes when you want to have the derived accessor in a class category in the app layer where the base class is in a framework. The framework base class has no knowledge of class extension in the app layer, so can't post the willChange/didChange, so your derived accessor is not KVO compliant.

Let's look at how things used to work with a basic example using firstName, lastName, fullName in our own object.

Header...

#import

@interface Person : NSObject {

NSString *firstName;

NSString *lastName;

}

- (void)setFirstName:(NSString *)value;

- (NSString *)firstName;

- (void)setLastName:(NSString *)value;

- (NSString *)lastName;

- (NSString *)fullName;

@end

Implementation....

#import "Person.h"

@implementation Person

- (void)dealloc{

[firstName release], firstName = nil;

[lastName release], lastName = nil;

[super dealloc];

}

- (void)setFirstName:(NSString *)value{

if ([firstName isEqualToString:value]) return;

[self willChangeValueForKey:@"fullName"];

[firstName release];

firstName = [value retain];

[self didChangeValueForKey:@"fullName"];

}

- (NSString *)firstName{

return [[firstName retain] autorelease];

}

- (void)setLastName:(NSString *)value{

if ([lastName isEqualToString:value]) return;

[self willChangeValueForKey:@"fullName"];

[lastName release];

lastName = [value retain];

[self didChangeValueForKey:@"fullName"];

}

- (NSString *)lastName{

return [[lastName retain] autorelease];

}

- (NSString *)fullName{

return [NSString stringWithFormat:@"%@ %@",self.firstName,self.lastName];

}

@end

I presented this quandary to an Apple engineer at WWDC 09 and after a few minutes he found this in NSKeyValueObserving.h and became my new hero. (I love WWDC for just this reason... the guy saved me an unbelievable amount of work).

/* Return a set of key paths for properties whose values affect the value of the keyed property. When an observer for the key is registered with an instance of the receiving class, KVO itself automatically observes all of the key paths for the same instance, and sends change notifications for the key to the observer when the value for any of those key paths changes. The default implementation of this method searches the receiving class for a method whose name matches the pattern +keyPathsForValuesAffecting, and returns the result of invoking that method if it is found. So, any such method must return an NSSet too. If no such method is found, an NSSet that is computed from information provided by previous invocations of the now-deprecated +setKeys:triggerChangeNotificationsForDependentKey: method is returned, for backward binary compatibility.

This method and KVO's automatic use of it comprise a dependency mechanism that you can use instead of sending -willChangeValueForKey:/-didChangeValueForKey: messages for dependent, computed, properties.

You can override this method when the getter method of one of your properties computes a value to return using the values of other properties, including those that are located by key paths. Your override should typically invoke super and return a set that includes any members in the set that result from doing that (so as not to interfere with overrides of this method in superclasses).

You can't really override this method when you add a computed property to an existing class using a category, because you're not supposed to override methods in categories. In that case, implement a matching +keyPathsForValuesAffecting to take advantage of this mechanism.

In a nut shell, all you have to do is add a class method and return the key paths for the value that affect your derived accessor....

+ (NSSet *)keyPathsForValuesAffectingFullName{

return [NSSet setWithObjects:@"firstName",@"lastName"];

}

So the implementation can be simplified to this...

#import "Person.h"

@implementation Person

@synthesize firstName, lastName;

- (void)dealloc{

[firstName release], firstName = nil;

[lastName release], lastName = nil;

[super dealloc];

}

- (NSString *)fullName{

return [NSString stringWithFormat:@"%@ %@",self.firstName,self.lastName];

}

+ (NSSet *)keyPathsForValuesAffectingFullName{

return [NSSet setWithObjects:@"firstName",@"lastName"];

}

@end

And the header this....

#import

@interface Person : NSObject {

NSString *firstName;

NSString *lastName;

}

@property (retain) NSString *firstName;

@property (retain) NSString *lastName;

@property (readonly) NSString *fullName;

@end

The moral:

- Much less code

- Can do it in a class category

Only downside is 10.5+ only, but you shouldn't be worried about 10.4 by now right :-)

Wheels for the Mind

noreply@blogger.com (Matthew Tonkin) — Sat, 14 Mar 2009 04:44:00 +0000

Mathieu Tozer (from Plasq) and I were interviewed for Wheels for the Mind magazine about being Australian Mac developers. Both of us received Scholarships from the AUC to attend WWDC in 2006.

Check it out here: http://www.auc.edu.au/tiki-download_file.php?fileId=144

Cheeky Cocoa

noreply@blogger.com (Matthew Tonkin) — Tue, 03 Mar 2009 06:22:00 +0000

Pushed a nil error to [NSApp presentError:] and it resulted in this console fart:

"-[NSAlert alertWithError:] called with nil NSError. A generic error message will be displayed, but the user deserves better."

Translation: "Don't be such a lazy prick. I'll deal with it, but I'm not happy about it."

Macworld Memeo Share Review

noreply@blogger.com (Matthew Tonkin) — Tue, 13 Jan 2009 20:00:00 +0000

Rob Griffiths stopped by the Memeo Share booth at Macworld last week and very promptly posted a couple of reviews...

- Macworld (text)

- Macworld (podcast - iTunes) skip through to 12:10 if you're interested

- PCWorld

We did a number of interviews, but no one is quite as quick as Macworld!

NovaMind Review

noreply@blogger.com (Matthew Tonkin) — Sun, 21 Dec 2008 20:00:00 +0000

Macworld gave a great review of NovaMind (particularly the UI) last week.

The part that I found particularly interesting was this....

"Tools for customizing your mind map are abundant and deep, yet they don’t overwhelm. The many palettes can be docked to the working window or dragged out to float independently. Individual palettes can be collapsed to just a title bar, or removed all together. Click a small button to see a palette’s advanced options and it flips over in a cool Quartz animation. The net result is an interface that is remarkably clean and easy to use despite the large feature set."

We had a continuous problem at NovaMind - how do you add more features without increasing product complexity. I don't think this is specific to NovaMind, in fact it's a common software engineering problem.

The big surprise is that (according to the article) we actually achieved what we set out to achieve. Excuse my skepticism, but it's very rare in software engineering that you get to do this. Usually you come out with something that's either almost there, or not even close but a way awesome bi-product.

Anyway, we did this with NovaMind by:

- Group like controls into separate groups in a separate space (a palette)

- Group those groups by changing the background color of the palette

- Only show palettes that are relevant to the selected item on screen

- Allow the user to customise it...

- User can collapse palettes to hide stuff they don't use

- User can reorder the palettes into the order they like

- User can have the palettes 'docked' in their document window or floating like an inspector

- Making the interface reveal advanced or low used features show up only when you need them. (We did this by 'flipping' the palette to show advanced features).

The resulting interface was this...

BIIIIG thanks to Keith Lang for his help (or rather complete and total input) in creating the quartz composition for the flip.

Business Graduation (after 6 years of pain)

noreply@blogger.com (Matthew Tonkin) — Mon, 15 Dec 2008 20:00:00 +0000

In 2003 I started studying for a Bachelor of Business in Management of Information Systems part time at the University of South Australia.

6 years later (yesterday) I finally finished it.... phew.

Why did I do it?

I've worked for some really good people and I've worked for some really average ones too.

The Peter Principal is that people are good at there job and get promoted until they are out of their depth and bad at their jobs. Therefore if the system were left to stabilise, everyone would be bad at their jobs (theoretically).

I've worked for Engineers who made bad Business decisions.

I've worked for Businessmen who made bad Engineering decisions.

So rather than being the former, I decided a Business degree would be a good addition.

What did I learn?

Well it's hard to put my finger on because I've used so much of it. No, really. I actually used that stuff.

What made it effective was that I learnt whilst I working, so I actually got to implement a lot of it soon after the learning process, which makes it far more relevant and it actually sticks in your head. Rather than studying accounting one year and needing it 5 years later, I studied it a few months before I applied it.

So when I look back at the course list I see stuff I now use everyday and couldn't imagine being able to do my job correctly without that background.

- Contract Law

- Communication and Media

- Business Information Systems

- Work and Organisation

- Statistical Analysis in Business

- Business Application Programming (OK - I didn't learn much in that one)

- Database Design

- Accounting, Decisions and Accountability

- Marketing Principles: Trading and Exchange

- Economic Principles

- Systems Development Methods

- Fundamentals of Information Technology (Helped raise my GPA)

- World Wide Web Development

- Introduction to e-Business

- Information Systems Project Management

- Contemporary Issues in Information Systems

- Enterprise Resource Planning (ERP) using SAP

- Mobile Enterprise

- Information Technology Strategy and Management

What's really cool is that I didn't have to wait until I graduated for my employers to appreciate the extra layer of skills.

Beyond the Backyard - Radio Interview

noreply@blogger.com (Matthew Tonkin) — Wed, 05 Nov 2008 20:00:00 +0000

Beyond the Backyard is ABC Adelaide's regular Tuesday Morning slot where they interview South Australian expats, working overseas.

This week it was yours truly.

Listen to it here: http://blogs.abc.net.au/sa/2008/11/beyond-the-back.html

Another UniSA chat about Mac development (7th August 08)

noreply@blogger.com (Matthew Tonkin) — Wed, 23 Jul 2008 19:00:00 +0000

Fresh from my latest junket to WWDC (Apple's World Wide Developers Conference) in San Francisco (thanks to the Apple University Consortium), I'll be talking up the wondrous world of Mac Development at the University of South Australia, but this time at the Mawson Lakes campus.

It's open to all University of South Australia students and I'll be covering both development of Mac OS X and iPhone applications (truth be known they're extremely similar to develop for, but splitting them makes me sound multi-talented).

It'll be held at....

University of South Australia

Thursday 7th August - 12:00pm to 1:00pm

GP Building, Room 12 (Mawson Lakes Campus)

Measuring a Software Engineer

noreply@blogger.com (Matthew Tonkin) — Fri, 18 Jul 2008 19:00:00 +0000

Can you measure an software engineer by a code sample?

A crazy old chinese electrical engineer (picture Gizmo's original owner in Gremlins) told me once that:

"An Engineer is a man who can do for 20 cents what other men can do for $20".

(You'll have to excuse the dominant male political incorrectness - it was the 80's).

Much of Software Engineering is the careful balance of resources (input) and code (output).

So you might have written the perfect class, but if you took a week to do it, then you've probably failed regardless.

So how do you measure a Software Engineer - in my opinion you weigh up a few variables...

- Code

- Time

- Additional resources consumed

- Stability

- Performance

- Abstraction, Modularity and Re-deployability

Revelation in Open Source contributions

noreply@blogger.com (Matthew Tonkin) — Mon, 12 May 2008 19:00:00 +0000

I have drawn on open source software a LOT, not just to avoid coding, but to learn about how other developers write their code, best practices and tricks other developers use. In many respects code samples and open source classes are my mentors, because it's kinda tough to find a good Cocoa teacher (I asked Aaron Hillegass to move into the garage space below my house, but he said no - actually he said "Stop doing that to my hat and get out of my apartment or I'm calling the police", which was a wake-up call that I may have overstepped a boundary).

Getting back to the point, I've drawn on Matt Gemmell's http://mattgemmell.com code on more than one occasion. He has some really great stuff on his site that you can borrow, modify, worship....whatever.

When you find a decent modification and add an enhancement to someone's existing open source code, then it's your responsibility to share so that others can learn (or pilfer) from your stuff - just as you have done. If you don't then you've failed all the other code kiddies that follow you and you can potentially cause irreparable damage to the space time continuum (OK, maybe I'm overstating it somewhat).

The Point...

How do you do this though? How do you contribute your mediocre code to that awesome class some guy posted on his blog?

Well there's a simple solution that might seem antiquated in a time of Web 2.0 and SVN, but it actually works. You place a light bulb above your head and email the guy your code. If they like it enough they might even update their code accordingly. Crazy.

How did I discover this incredible revelation - I emailed Matt Gemmell with my code modifications to one of his classes and he updated his and reposted it. Awesome. See here: http://mattgemmell.com/2008/05/12/imagecrop-updated

for results.

Mac Development "Chat" at Adelaide University

noreply@blogger.com (Matthew Tonkin) — Fri, 04 Apr 2008 19:00:00 +0000

I've been invited to speak words of wisdom about what it's like to develop software for the Mac at Adelaide University. So as not to mislead anyone about what I'll be doing, please replace the words "speak words of wisdom" with "rant and rave".

I'll cover the good, bad and ugly sides of Mac development from both a technical and business perspective. Naturally the good bit will take up about 90% of the time (otherwise I would have sought an alternative career as a fish monger, moved to Russia and changed my name to Mattski Tonkowski).

Apple's shiny new Systems Engineer, Patrick Tehvand will be in attendance, so you can ask him how your Leopard Server Xgrid Cluster can be better load balanced (or whatever other geeked out IT Systems questions float your boat).

As always Apple's not so new (but still shiny) BDM, Greg Egan will also be attending.

Both Adelaide University and University of South Australia students are invited to attend.

If you fall into one of those categories and are interested in attending here are the details...

University of Adelaide

Friday 11th April 2008 - 12:10pm to 1:10pm

Room 2060 - Computer Science Building (North Terrace Adelaide)

MEGA

noreply@blogger.com (Matthew Tonkin) — Tue, 12 Feb 2008 20:00:00 +0000

Mobile Enterprise Growth Alliance - http://www.mega.org.au

I'm lucky enough to be participating in the MEGA program this year. The opportunity came up through the course I'm studying externally at UniSA (Bachelor of Business, Management of Information Systems). It only counts for 1 subject, and I'm fairly sure it'll be a lot more work than if I took the easy road and signed up for an elective in lawn mowing or something, but there are a few things about this course that grabbed my attention....

Firstly, I'll get to learn about an emerging / growing industry (Mobile apps)...

I'm sure I can knock out a mobile app (I've cranked out a few iPhone / iPod touch apps already using the iPhone SDK).... but I think there's more to it than that - like the business and feasibility aspects of mobile applications. It's not the desktop (an established industry), it's very new. As per normal, I'm sure Apple will throw a spanner into the works of the incumbent mobile applications market, but it doesn't help to know from the experts what the existing challenges were before Apple stepped into the arena.

Secondly, the program is taught by industry guru's not people who are haven't left university. Not surprising I suppose - UniSA support it and often use industry types rather than career academics (that's why I like them).

Course Format - Incase you're interested in doing it too....

Team Building and Orientation 1 (Feb 19th)
Team Building and Orientation 2 (Feb 26th)
Workshop 1: Market Analysis 1 (March 5th)
Workshop 2: Market Analysis 2 (March 12th)
Workshop 3: Idea Generation 1 (March 18th)
Workshop 4: Idea Generation 2 (March 19th)
Workshop 5: Tech Test 1 (April 8th)
Workshop 6: Tech Test 2 (April 9th)
Workshop 7: Feasibility 1 (April 22nd)
Workshop 8: Feasibility 2 (April 23rd)
Workshop 9: Feasibility Panel (April 30th)

Categories are cool

noreply@blogger.com (Matthew Tonkin) — Sun, 02 Sep 2007 19:00:00 +0000

Perhaps not cool in the Samuel L Jackson sense, but categories are damn cool in the ‘holy cow I can extend something without replacing the class’ sense....if that is indeed a sense.

Class categories are a way of adding functionality to a an existing class where you don’t need additional instance variables.

If your new functionality needs instance variables, then subclassing is the go, but there is no need to subclass unless you're adding instance variables or override existing methods. Instead adding a class category will mean that you don’t have to worry about refactoring your existing code to use the new functionality. This is really handy where the original class is not your own.

Let’s have a look at a Cocoa Objective C example. NSXMLElement represents and XML Node and currently has a the following method.

The problem with this is that we have a lot of circumstances where we don’t want an array, just the first element with that name (if there is one). NSXMLElement doesn’t currently provide this functionality, so instead, each time we wanted the first element with that name we’d need to get an array using ‘elementsForName:’ then check to see that it has some elements, then get the first one. Rather than do all that, let’s just add a new method to NSXMLElement to give us this functionality without needing to do all this extra work each time we need it.

First, we start with a header:

Notice that there is no variables section. If you add the {} then it won’t compile.

Then we add the source:

Maybe not groundbreaking stuff, but handy none the less.

Cocoa Talk UniSA / Adelaide Uni 24th August 2007

noreply@blogger.com (Matthew Tonkin) — Tue, 14 Aug 2007 19:00:00 +0000

I’ll be giving a presentation to UniSA & Adelaide Uni staff and students on Cocoa Development. Hopefully I can share some words of wisdom (by wisdom I mean talk about some things I did wrong) to help you get started with Cocoa / Objective-C and all its goodness.

It’s open to all UniSA and Adelaide University staff and students (and includes lunch thanks to the Apple University Consortium). If you’re thinking about Cocoa development (or sandwiches) then feel free to join us.

Date: Friday 24th August
Time: 12.30 to 1.30
Location: BJ1-13 [Bonython Jubilee Building] City East Campus, University of South Australia
RSVP: Please email Tim Sawyer if attending for catering purposes

Agenda:
Mac OS X development overview
What is Cocoa / Objective-C
Why Cocoa / Objective-C
The Frameworks
Anatomy of an Objective-C class
How to get started
Tips and Tricks (AKA: Mistakes I made)
Good Resources (Online / Print / Open Source)
The Apple University Consortium
Mac developers in Australia

Open Source Cocoa Frameworks and Classes

noreply@blogger.com (Matthew Tonkin) — Sat, 04 Aug 2007 19:00:00 +0000

Apple has a LOT of stuff in their frameworks, but there’s always something else you need. You always want more. It’s never enough that those boys and girls in Cupertino are working their fingers to the bone to provide you with development tools. FINE.

If you need to go out for burgers when you’re not getting steak at home, here are some of my favorite burger joints....

OmniGroup: Subclasses and Categories for all your favorite Cocoa objects. There’s more stuff there than I care to discuss. Seriously, loads and loads of it. Well tested and rock solid.
http://www.omnigroup.com/developer/

iMediaBrowser: Need a media browser for integrating with those pesky iLife apps. This one is just like the one used in the Apple apps (which they refuse to share - tsk tsk).
http://imedia.karelia.com

Karelia: Useful bits and bobs. I liken this site to that drawer below the sharp knifes but above the tea towels and glad wrap. The one with the string, glue, strips of velcro, a D-cell battery and other crap that you can never find when you are looking for it, but can always find when you’re not. BIG kudos to these guys on all their iMediaBrowser work.
http://cocoa.karelia.com/

Aquatic Prime: Some kind of registration framework. I haven’t actually used it, but I have drawn on some of their classes for simple tools. There’s a really cool NSData Encryption category. Niiiiiice...... (insert Borat accent here).
http://aquaticmac.com/

Infinite Loop: Crash Reporter that can send your crash reports to a designated email address. You get the stack trace and console log and everything (actually just the stack trace and console log).
http://www.infinite-loop.dk/developer/

Rainer Brockerhoff: RBSplitView is a great alternative to NSSplitView (you know, the thing that separates your inbox list from the mail preview). It’s like Apple’s own but on serious roids.
http://www.brockerhoff.net/

Matt ‘Legend’ Gemmell: A few cool bits and pieces including a HUD window and a much prettier NSBox.
http://mattgemmell.com/source/

PSM Tab Bar Control: Safari style tabs (with more features). Used in Adium.
http://www.positivespinmedia.com/dev/PSMTabBarControl.html

MUPhotoView (Blake Seely): iPhoto style photo grid (used in iMediaBrowser)
http://blakeseely.com/subversion.html

Why Cocoa

noreply@blogger.com (Matthew Tonkin) — Sun, 15 Jul 2007 19:00:00 +0000

In Mac OS X you can use any number of development languages including C, C++, Open GL, Ruby and probably some others I forget about. These options are handy to have, but it’s not really any different to developing using these same languages on another platform (one that could target a lot more users).

The Business Advantage of developing in Mac OS X is Cocoa and Objective C, mostly because you get a whole lot of stuff for free. Low level things you don’t need to care about any more. Things that are a headache on other platforms.

There is an infinite number of possibilities for software development and they fall into a few categories:
Stupid Software... Shouldn’t be developed no matter how cheap it is
Brilliant Software... Should be developed no matter what the cost
Infeasible* Software... Perhaps a good idea, but a (cost-benefit)*risk analysis indicates that it’s not feasible

Infeasible software is the most interesting. What wasn’t feasible last year might just be feasible today, and that’s because companies like Apple invest a lot of time in taking away the headaches of development, so we can focus on our business problem and develop great software on the cheap.

What’s feasible on the Mac isn’t necessarily feasible on other platforms, which makes it exciting. It’s particularly exciting when you consider Agile development practices and exploring ideas. If you can explore an idea without breaking the bank, your much more likely to find something that works, and when you do, bring it back to other platforms perhaps.

What? You want an example?
Ok, here’s something really small. In Mac OS X you can create a custom view that draws stuff for your app and in 1 line of code you can convert it to a chunk of PDF data. 1 lousy line.
It’s a small thing, but it could mean the difference between your app outputting a beautiful, small, scalable PDF file and some ugly JPG. It might just make the difference between an idea that progresses and one that gets canned.

Still not impressed? Fair enough, it’s a fairly rudimentary example and it’s been in Mac OS X since the beginning. There’s much more exciting (but long winded) examples in newer frameworks such as CoreData, CoreImage and QuartzComposer.

*Infeasible isn’t actually a word, but for todays purposes let’s pretend it is and means the opposite to feasible