Much has been said from both sides about whether the iPhone should support garbage collection or not and I won't go into the debate here, other than to say that I think there are valid reasons for it being that way - but that's not to say that it couldn't be made to work (it would be nice if it was at least optional).

A few pointers

As a grizzled C++ developer in past (and, as it happens, present) lives I'm not fazed by the sight of a raw pointer or the need to count references. That said I struggle to remember the last time I had a memory leak, a dangling pointer or a double-deletion. Is that because I'm an awesome C++ demigod who eats managed programmers for breakfast? No! Not just that! It's also because I use smart pointers.

Smart pointers make use of a feature of C++ that is disappointingly rare in modern programming languages (and often seen as incompatible with garbage collection): deterministic destruction. Put simply when a value goes out of scope it is destroyed there and then. There is no waiting for a garbage collector to kick in at some undetermined, and indeterminate, time to clean up after you. Then why does C++ have the delete keyword? Well I said when a value goes out of scope. If you allocate an object on the heap, the value you have in scope is the pointer to the object. C++ also allows you to create objects on the stack, and these are destroyed at the end of the scope in which they were created (there is a third case where an object is declared by value as a member of another object that lives on the heap - but I'll ignore that for simplicity). When that object is an instance of a class the developer has defined they can supply a destructor that is run when the object is destroyed. Often this is used to delete memory owned by the object - but it could be used to clean up any resources the object is managing, such as file handles, database collections etc. Smart pointers manage objects on the heap. Depending on the type of smart pointer they may simply delete an object in their destructor - or they may offer shared ownership semantics by managing a reference count - so destructors decrement the ref count and only delete when the count reaches zero.

I've crammed an overview of a rich and incredible powerful language feature into a single paragraph above. I haven't even touched on how smart pointers use operator overloading to look like pointers. You can read more details elsewhere. My point is that, because of smart pointers - made possible by deterministic destruction (or more generally an idiom unfortunately known as RAII) - garbage collection is not really missed in C++.

Using {

All of which is the long winded setup to my story for this post. The last couple of days I have been involved with tracking down an issue in a .Net app. I say "involved with" because there were three of us looking at this one problem. Three developers, with more than half a century of professional development experience between us, all on the critical path, tracking down this one problem. In .Net. The problem turned out to be with garbage collection. Actually there was more than one problem.

Is that a jagged array in your pocket?

Now this is not about knocking garbage collection. Or .Net. This is about how things are not always as they appear. In fact that's exactly what the first issue was. We have C++/CLI classes that are really just thin proxy wrappers for native C++ objects. The C++ objects are often multi-dimensional arrays and can get quite big. The problem was that the "payload" of these objects was effectively invisible to .Net. As far as it was concerned it was dealing with thousands of tiny objects. The result was that, when called from C#, it was happily creating more and more of these without garbage collecting the large number of, now unreferenced, older objects!

Actually we had anticipated this state of affairs and had made sure that all these proxy objects were disposable. This meant that in C# we could wrap the usage in a using block and the objects would be disposed of at the end of the using scope. The problem with this is that there is no way to enforce the use of using. By contrast: in C++ if you implement clean-up code in a destructor it will always be called at the end of scope (ok, if you create it on the heap there is no "end of scope" and you're back to square one. I'd argue that you have to make more of an effort to do this, however - and there are also tricks you can use to detect if).

As it happens using is not really the right tool here anyway. The vast majority of these objects, whether boxed primitives (we have a Variant type) or arrays, are semantically just values. Using using with "value" types is clumsy and often impractical. What we would really like is a way to tell the GC that these proxies have a native payload - and have it take that into consideration when deciding when and what to collect. Of course we have just such a facility: GC.AddMemoryPressure() and GC.RemoveMemoryPressure(). These methods allow you to tell .Net that a particular managed object also refers to unmanaged memory of a particular size (in fact you can incrementally add and remove "pressure"). Sounds like just what we need.

Unfortunately there is more to it. First we need to know what "pressure" to apply. If the data is immutable and fully populated by the time the proxy sees it then that is one thing. But if data can be added and removed from both managed and native sides it becomes more tricky. To do it properly we'd have to add hooks deeper into the native array objects so that we know when to apply more or less pressure. Furthermore many of our arrays are really jagged arrays, implemented in terms of Variants containing Variant arrays of more Variants of Variant arrays (if that sounds appalling you probably haven't worked in a bank. Or maybe you have). How can we keep track of the memory being consumed by such structures? Well it helps to keep in mind that we don't really need to know the exact number of bytes. As long as we can give the GC enough hints that it could bucket sizes into, say, orders of magnitude (I don't know exactly how the GC builds its collection strategies and I don't want to second guess it. I'd imagine even this is more granularity than it needs most of the time, but it seems a reasonable level of accuracy to strive for). Fortunately I already have code that can walk these structures and come back with effective fixed array dimensions, so multiplying that by the size of a Variant should get us well into the ballpark we need.

Photo by Peter Kaminski - http://flic.kr/p/2A5db

A weak solution

So that was one problem (with several sub-problems). The other was that a certain set of these objects were being tracked in a static Dictionary in the proxy infrastructure. Setting aside, for a moment, the horrors of globals, statics and (shudder) singletons, let's assume that there were valid reasons for needing to do this. The problem here was that the references in the dictionary were naturally keeping the objects alive beyond their useful lifetime! In a way this was a memory leak! Yes you can get memory leaks in garbage collected languages. Of course what we should have been doing (and now are doing) is to hold weak references in the static dictionary. I'd guess, however, that many .Net developers are not even aware of WeakReference. Why should they be? Managed Code is supposed to, well, "manage" your "code" isn't it? Anyway, not surprisingly switching to weak references here solved that problem (and somewhat more easily than the other one).

I'll say again - I'm not having a dig at .Net developers - or anyone else who primarily targets "managed" languages these days. I've used them for years myself. My point is that there is a lot more to it and you don't have to go too far to hit the pathological cases. And when you do hit them things get tricky pretty fast. In addition to the fundamental problems discussed above I spent a lot of time profiling and experimenting with different frequencies and placements of calls to GC.Collect() and GC.WaitForPendingFinalizers(). None of these things were necessary in the pure C++ code (admittedly they are not often necessary in pure C# code either) but when they are it can be very confusing if you're not prepared

}

phew!

Now I started out talking about Objective-C but have ended up talking mostly about C++ and C# (although the lessons have been more general). To bring us back to Objective-C, though, where does it fit in to all this?

Clearly destructive

Well on the iPhone Objective-C lacks garbage collection, as we already noted. It also lacks deterministic destruction (or destructors as a language concept at all). So does that leave us in the Wild West of totally manual C-style memory management? Not quite. Probably the biggest issue with memory management in C is not that you have to do it manually. Personally I think a bigger issue is a lack of universally agreed conventions for ownership. If a function allocates some memory who owns that memory? The caller? Maybe - except when they don't! Some libraries, and most frameworks, establish their own conventions for these things - which is fine. But they're not all the same conventions. So not only is it not always immediately obvious if you are supposed to clean-up some memory - but the confusion makes it less likely that you will remember to at all (because, sub-consciously you're putting off the need to work it out for as long as possible).

Objective-C, at least in Apple's world, doesn't have this problem. There is a very simple, clear and concise set of rules for ownership that are universally adopted:

If a function or method begins with alloc or new, or has the word copy in it, or you explicitly call retain - the caller owns it. Otherwise they don't.

That's it! There are some extra wrinkles, mostly to do with autorelease, but they still follow those rules.

Other than some circular references I had once, and quickly resolved, I don't recall having any problems with memory management in Objective-C for a long time either

Epilogue

There. I've discussed memory management in four languages in a single post - and not mentioned the iPad once! As it happens you can use all four languages to write for the iPhone or iPad. So take your pick of memory management trade-offs.

[*] I tried to track down who tweeted "The 80s called; they want their memory manager back" during Stackoverflow Devdays. As it's difficult to search Twitter very far into the past I couldn't find the original tweet - but thanks to a retweet by Nick Sertis it appears that it was J. Mark Pim. Thanks J.

I've had a series of posts recently about the iPad, and historically one or two others that have touched on products rather than code. Primarily this blog has been about software development. The target audience is software developers. I will continue to write about software development. However I also occasionally intersperse this with commentary on technology that I feel is relevant to software development as a scene, if not as a discipline. I feel that the iPad is going to have a big impact on he future of software - maybe not in total, but in significant part. Not everyone will agree with that, but what are blogs for if not for putting opinions out there to be dissected (don't answer that)?

It's also interesting that, while my iPad posts gave it a run for its money for a while, my highest ranking post to date remains the one about setting up Time Machine backups to network drives. I'm not sure if this is a good sign or not. But one thing is sure. I'm not going to switch my focus to writing about products just to get the page hits. That's not why I write this blog.

Well that's enough indulgence of the forbidden fruit of meta for now. We will now resume our usual programming (pun very much intended).

Like the iPhone and iPod touch the iPad does not allow multi-tasking of third-party apps. That is, if you are using one app and want to start another you must close the first app. I wouldn't rule out that changing in a future update, but I'm more inclined to think we won't see it even on the iPad - at least not in a general form. Why?

The way I see it multi-tasking is used for three purposes:

1. Background apps, such as music players. The iPod app does run in the background, of course, but there is certainly a case for third-party apps such as Spotify or Last.fm to have the same ability.
2. Notifications. This is at least partly addressed by the Push Notification service that Apple now provides. More on that in a moment.
3. Fast switching between apps

I'd say that (3) is probably the number one reason we usually have so many apps open at once. After all we can usually only interact with one at a time. As the time it takes to (save and) quit one app and start (and restore) a new one gets closer to zero our need to have the apps open just so we can switch to them diminishes or disappears. From what I have read and heard the iPad gets us pretty close to the threshold where this happens. By some reports it crosses that threshold. I'll reserve final judgement until I see it with my own hands (mixed metaphor intended).

Going back to reason (2) let me explain what I mean by being only partly addressed so far. Imagine a calendar-type app - such as Event Horizon. You set up events and appointments - which may be days, weeks or months later. Ideally the app would be able to alert you of upcoming events in much the same way that Apple's own calendar app can already do. One way to achieve that now would be to use the push notification service. This would work but has two problems. First it's a bit heavyweight. Your event data would need to be synced up to a cloud service which could then decide when to push a notification back to the device. Cloud services certainly have their place, but bringing them in solely to provide alerts seems out of proportion. Secondly it means you will not receive the notification if you don't happen to be connected at that time. You will get it when you do get online, but that may be too late! Furthermore you need to be connected for the alert to sync up to the cloud in the first place. These all seems unjustifiable limitations when it concerns data that you already hold locally on your device. Therefore I think it reasonable that some sort of Scheduled Notification API should be made available. This could work just like the Push Notification service, allowing badges, messages and alert tones to be "pushed" to the user, with the ability for the user to open the associated app straight away, or defer that until later. The difference would be that the notification would be posted by the app itself for delivery at a specific time in the future and would never leave the device. I don't see any technical challenges to providing such an API.

If a scheduled notification API is made available I think the only significant remaining need for background tasks would be for things like music players. If Apple do allow background tasks in the future I think it will be limited to these types of tasks, and very strictly policed in the app store approval process. I'll say again, I don't believe Apple will ever allow general purpose multi-tasking in App Store apps. - and I don't believe they need to with the concessions just described. Note that I am ruling out other scenarios such as video encoders or bit-torrent clients, which I don't think are appropriate apps for running on these devices in the first place. If you can think of anything genuinely useful for a significant number of people that wouldn't be covered by such provisions I'd be interested to know.

Does this mean that, before such apps arrive, the iPad is just an empty slab? Perhaps useable only for the very old, the very young, or the technically illiterate? Not at all. The key reason that there has been such a backlash against the iPad is that there was so much hype about it before the announcement. It wasn't just that everyone had idyllic expectations of what it would be for them - although that certainly didn't help. Just the fact that there was hype meant that everyone was watching this event as being a turning point in the history of computing. The trouble with historical turning points is that they are often only recognisable as such when you have the historical perspective. Put it this way: if the launch of the iPad really does turn out to be the moment of a revolution in computing, when looking back on this in years to come, would it seem reasonable to think that its lack of a front-facing camera or support for Flash would be a factor in that status?

I think it's quite likely that some sort of camera facility will arrive at some point - either by way of a future hardware upgrade, or as a peripheral. There are some practical challenges there, but if they can be overcome I suspect they will. As for Flash, that's another story. I'm with the camp that hopes it doesn't get it. There is plenty of good discussion of why that should be the case around already. Whether you agree with that or not, and whether Apple does eventually allow Flash or not, I think is irrelevant to whether this device will change the way we think about computing in the future.

Some great articles and blog posts have been written already about why the iPad really is a revolutionary new device. I think I can summarise them in one sentence:

The iPad takes the tasks we use personal computers and the internet for the most and packages them into a focused, polished, device with an interaction method that gets out of the way.

To add a couple more sentences to that: It does this by removing the need to know about mice and windows and multi-tasking and file systems and cables and hard drives and memory and even, to some extent, physical keyboards! Not that those things are gone forever - just that, for most tasks - tasks that even us technically-savvy power users perform much of the time - they are just a distraction! They are, or were, the means not the end. The iPad gets you to what you were trying to achieve more directly than any device before. If this is not what you wanted that's fine. That doesn't mean this device won't change the way many - perhaps most - people interact with and think about computers forever.

But that hasn't answered the question of what can we use the iPad for right away? Well, even assuming there are no additional game-changing apps available on launch (remember that's still 2-3 months away) there are still some very worthwhile apps bundled with the device, or available on the app store (including Apple's own iWork suite). While none of these are conceptually revolutionary, the ways you interact with them, and when you can use them, may well be. Here are some of the things I can see myself doing that currently would be either impossible or a different quality of experience:

• Reading on the train. The laptop is not always possible - iPhone too small for sustained reading
• Reading/ watching video at the gym
• Browsing maps. Especially when planning future or reflecting on earlier travel. Looks like such a better experience than a laptop.
• Picture frame in my office. I was planning on getting one anyway - this will save me the cost and looks better than most, if not all, dedicated devices anyway.
• Task management. It's been great having GTD apps like Things with me all the time on my iPhone, but they still suck for data entry or big re-orgs - so I usually have to wait until I have access to my laptop - by which time I often have forgotten (which was why I was using them in the first place!). I'm confident that at least once such app will be available on, or shortly after launch. If not the existing iPhone versions, in pixel doubled mode, will still be more usable just be dint of a larger keyboard.
• I'm hoping that the Remote app for controlling iTunes will soon be updated with an iPad UI as that will be an awesome way to control my household media
• Showing photos. When family visit it's been great that we can browse photos on the TV or a laptop - but this will be a far more natural and intimate experience.
• Playing vConqr. No seriously - it's going to be great! :-)
• Of course casual browsing, email contacts and calendar when I'm away from my laptop - or even instead of using the laptop for such things. That way I keep my workspace a little tidier. Obviously I'll still do serious web-browsing on the laptop (if only because of multiple-tabs and copy-and-paste into my other desk-top apps).

I should point out that I consider myself very much a power-user of my laptop/ desktop computers. I have my laptop (a Macbook Pro) connected to a 30" display and still use Spaces to give me more workspace area! As a developer and technologist this will alway be my primary computing experience, but I still see myself using the iPad for more and more tasks too - and not just when I'm on the move. For many people I can see it being their primary, and at some point only, computing device (for now, at least, it seems the iPad still needs to sync against a general purpose computer but the need for that seems to be decreasing).

I started to write about multi-tasking here too, but realised I had a lot of material that diverges from this post, so I've moved it into its own article, which I'll post a bit later.

So Apple's fabled Tablet, the iPad, has finally been unveiled. While many of the rumours turned out to be spot on, at least as many more missed the mark. Inevitably there will be a section of the community who feel disappointed with the reality. After all no single device could live up to every expectation. I mean it doesn't even have sharks with frickin' lasers!

However, while Apple have made clear what they think this device is initially going to be used for I think ultimately it's going to be the developer community that proves whether this really is a new device category. Can you imagine the iPhone now still being just a phone that does email, music and internet? Certainly they are still very much core to the iPhone experience, but what really sets the iPhone apart are the apps that have taken it in directions that Apple would never even have thought of. Of course Apple know that too and have already released a new SDK for developers.

This is what makes this time especially exciting to me, as I am part of that developer community. I have one iPhone app out there at the moment, vConqr, a turns-based strategy game somewhat based on the board game, Risk. vConqr should work quite nicely on the new device as is, and of course I have plans to tweak it to take advantage of the new form factor and features. But I have other apps in the pipeline, including one idea that I have been brewing for about five years now. In fact, back in 2005 I was shopping around for tablet computers, looking for a platform to do my app idea justice, but I never found anything compelling. I had initially planned to write a desktop version, which I did start work on, and when the iPhone came out I put it on my queue for an iPhone version. But when I started hearing that rumours of an Apple tablet device where gaining momentum I realised this could be the ideal home platform. Today's unveiling has turned that hope into reality and I can confirm that I am now fully committed to bringing this product to market.

I hope you'll forgive me for not describing exactly what my idea entails just yet, although I have mentioned it to some people in the past. I'll go as far as saying that it is a productivity app that is largely a synergy of two existing app concepts - both of which I fully expect to see numerous implementations of becoming available, individually, for the tablet (as, indeed, they already are for the iPhone). My offering would not simply be a tool that provided both functions - or even a way of seamlessly switching between the two. I believe the integration of the two concepts leads to a sum that is greater than its parts, and throwing in some extra factors (think "cloud") leads to something that, for the last five years, I've wished I already had almost daily and I'm very excited about finally following through on.

Of course, I'm not suggesting that my app will be the saviour of the iPad! In context my point is that, as a developer, I have ideas for this device that would not work so well on any other platform yet. I'm sure I'm not the only one. What the iPad ultimately becomes associated with is something that will not fully emerge until time has allowed the developer community to provide that answer.

As I start to work on Two Blue [Dacted] I'll post a little more information - just to keep you in suspense. You can also follow me on Twitter as phil_nash where I may say more from time to time.

I have covered the background to most of my choices in some detail (some would say too much - but I invoke Blaise Pascal here) in the first two articles of this series, the rather consistently named:

Code formatting in C++ Part One

Code formatting in C++ Part Two

Page width

The proposals below refer often to page width, and by this I mean the number of characters that you would normally expect to be visible while reading and writing code in an editor. For example, it used to be common to keep within 80 characters (or less) due to text mode screen sizes. These days windows can easily be sized to much greater character widths, but I would still recommend adopting a page width of between 80-100 characters. It is not a hard limit, although it is more important in some areas than others. Personally I still try to stick to 80.

Proposal 1: Formatting variable declaration blocks

char*          txt = "hello";
int            i = 7;
std::string    txt2 = "world";
std::vector<std::string>            v;
std::map<std::string, std::string>  m;

Variable declarations should be grouped together where possible (without violating the principle of locality - ie, keeping them close to first use) in "islands" of no more than 16 lines at a time. If there are more than 16 variable declarations in a group then use single lines of whitespace to break them up. Try to keep variables of similar length in the same block.

Within each block, align the variable names as much as possible. Where there is a large variation in type name length, sub-group longer names and shorter names together and align variable names in sub-group blocks instead (note how the vector and map, above, are separated out this way)

Proposal 2: Formatting function signatures

Function definition signatures

////////////////////////////////////////////////////////////////////////////////
void ClassName::MethodName
(
	char*          txt = "hello",
	int            i = 7,
	std::string    txt2 = "world",
	std::vector<std::string>            v,
	std::map<std::string, std::string>  m
)
const
{
	// ... method body
}

The example here is for a method of a class, but the formatting would be the same for a free function

The return value and function or method name (along with any modifier prefixes - e.g. static, or namespace prefixes) appear on their own line.
Next are the parentheses - both of which appear on their own line - indented to the same level as the preceding line.
Within the parentheses, each on their own lines, are the arguments - formatted according to Proposal 1. Any post-fix modifiers (just const, in this case) appear on their own line, followed by the function or method body.

This is almost certainly the most controversial proposal and I will take up my additional rationale in the next article

If a comment block does not already precede the signature, use a line of forward slashes for about a page width (e.g. I run them up to the 80th column).

An additional point worth mentioning here is that this style lends itself well to being used with the Doxygen "inline comment" method of documenting function and method arguments.

Function prototype signatures

void MethodName
	(	char*          txt,
		int            i,
		std::string    txt2,
		std::vector<std::string>            v,
		std::map<std::string, std::string>  m ) const;

If a separate prototype is required there are some differences to the formatting. This might seem a little odd but I'll provide the rationale in the following article.

First, the parentheses appear in-line with the arguments block, rather than on their own lines. Furthermore the whole block itself is indented with respect to the function name. Finally, any post-fix modifiers (which may include the pure virtual marker here) appear on the same line as the closing parenthesis.

Note that no line of comment characters precedes the signature. Ideally functions and methods would be fully documented at the implementation site and the documentation extracted from comments using a tool such as Doxygen. There are reasons to consider keeping the prototypes clear of too many comments, but obviously you can put them here if you are sure that is best for you

Proposal 3: Function calls

LongMethodCall1( "some text",
                  aString,
                  anInt,
                  anotherArgument );

string returnVal = ReallyLongMethodNameCall
		( "some text",
		  aString,
		  anInt,
		  anotherArgument );

In both cases the arguments are aligned, one line each, with parentheses on the first and last lines. The first line should share the line with the function or method name itself, unless that would push the argument list across such that any of the arguments end up beyond the page width

General Principles

The proposals above are deliberately narrow in focus, concentrating on those areas that are often left out of standards, or not sufficiently described, and where using an ad-hoc approach is often less than satisfactory. However there are some simple emergent themes that can be carried through to other areas of code:

• Types and identifier names are separated into columns through alignment
• Code is kept within a page width where possible. This is especially significant for code that you need to refer to at a glance, such as function prototypes - and is often where it is most overlooked!
• For "structural" code, such as function signatures, consistency is especially important, even in places where it seems unnecessary (e.g. splitting short function signatures across multiple lines - even empty constructors). For implementation code the choice of when to split can be guided by the page width.

I have made some recommendations in these proposals that are not specifically backed by the discussion in the previous articles. I will attempt to cover these in the next, and final, article in this series.

Apple recently released their latest mouse. It's a smooth, minimal design, connected via bluetooth, but of particular significance it claims to be "the world's first Multi-Touch mouse". But how good is it in practice. Do the multi-touch features enhance usability? Does it break Apple's curse when it comes to mouse designs (historically they tend to suck)?

There are many reviews of the Magic Mouse springing up over the internet already - on both professional and personal sites, as you would expect. However using a mouse is such a subjective experience that I feel there is still some value in presenting my own experience so far with it. Not least becausea fair amount of controversy surrounds it

One button to rule them all

Apple are often criticised, if not ridiculed, for only supporting a single mouse button. In fact that is not true and Macs have supported multi-button mice by default since at least the mid-90s, and through third-party drivers since long before then. What they have continued to do until only relatively recently is to ship with only a single button mouse, and advocate that all features should be accessible with only the single button.

In 2005 Apple released the Mighty Mouse, first in wired form, then a year later with a Bluetooth variant. This added not just one extra button - but three (for a total of four)! Unfortunately this mouse had problems - most notably in the very area that it appeared to have finally caught up in! To perform a right click you had to lift your left finger, or else the click was interpreted as a left click! There were also other criticisms, such as the ball clogging with dirt frequently.

Since it was Apple who first popularised the use of a mouse for personal computing, it seems odd that for many years now most discerning Mac users eschew Apple's own mice for third-party devices - usually Logitech. Originally the main reason was the lack of extra buttons, but more recently the implementation of multiple buttons has been badly executed. So the release of the Magic Mouse has been met with much hope that Apple have finally got it right - but have they?

Almost but not quite

Sadly the right-click problem is still there. If your left finger is touching the mouse during a right click then a left click event is fired. If, having read this you are ready to give up in disgust, please read on. Personally I have found this to be not as much of an issue as I thought it would be, and by getting past this sticking point I have been able to enjoy the nicer features this new device has to offer.

First, the USP for the new mouse is its multi-touch ability. Now this is not as fully featured as an iPhone screen, or the newest Macbook Pro/Air trackpads, but since this is in addition to traditional mouse features it's a good first step. At it's most basic it replaces the scroll-ball of the Mighty Mouse, offering full 360 degree scrolling by dragging or flicking (just like on an iPhone screen). Scroll-ball diehards fail to see what the fuss is about, but if you've never liked scroll-balls much, and if you're already used to the iPhone way of doing things, this new surface is very nice indeed. In addition to basic scrolling a two finger swipe left or right invokes the back and forward buttons of a browser, respectively. These gestures are a little more awkward at first, but are still useable. It would have been nice if pinch-to-zoom had been available too, but I suspect that would require a more advanced touch surface to work reliably.

Size matters

What about the form factor. This is another highly individual area. If you're used to the ergonomic styles of many of the Logitech mice, which fill the cup of your hand, you may find the Magic Mouse to be small and cramped. Moving from such a Logitech device myself I did notice the difference, but don't find it a problem. I think the differentiating factor is how long you tend to be tied to the mouse. I can imagine that if you are a graphics designer, or someone who spends the majority of their time with their hand on the mouse, the advantage of an ergonomic design become significant. As a developer I'm generally more keyboard oriented. Switching from mouse to keyboard frequently, if anything, is easier with the smaller design as I only tend to touch the mouse with my finger-tips.

Despite being much smaller than my Logitech, the Magic Mouse is roughly the same weight. This is not unusual since the Logitech I have is a wired mouse. As a wireless device, the Magic is probably at the lighter end of the spectrum - but not so light that it feels flimsy. The weight seems just about right - any lighter and the multi-touch gestures would likely knock the mouse around.

Batteries included

Another criticism of the Magic Mouse is that it takes AA batteries, with no integral charging facility. Obviously rechargeable batteries can be used but then it is up to you to take them out and charge them separately. For a mouse with this form factor I think it would be tricky to get the charging circuitry in too - but I could be wrong. It remains to be seen whether this is a real issue or not. I've had battery powered mice before they've been a minor inconvenience, but then so have those with their own chargers - remembering to dock them all the time. Again this is a very subjective experience

Magic or curse?

So is this the Apple mouse that's finally worth getting? Well it seems this question is tougher to answer than before. It still has the right-click problem, and it has a number of other possible downsides too. However the extent and merits of each are highly subjective, and you may be surprised yourself at the experience. Therefore the only conclusion is to try it for yourself. Fortunately they are readily available for testing out in Apple stores around the world.

I have sanitised (as pdf) and uploaded the slides from my devdays presentation on iPhone development. Enjoy.

For various reasons I missed a chunk of the conference, and as my mind was on my own presentation I wasn't quite as attentive to the rest as I would normally like to be.

Nonetheless the highlight for me, and I think most attendees, was Jon Skeet's entertaining, yet thought-provoking, foray into how we can't even get the most fundamental aspects of software right: numbers, text and dates - all accompanied by a sock puppet called Tony. I also enjoyed Christian Heilmann's coverage of the Yahoo YUI web toolkit, and especially the little known YQL. From the twitter back-chat it seems I am not alone in both being blown away by YQL and not having heard of it before!

Divided Opinions

As for my own presentation, one of the points I brought out was that people tend to either love or hate Objective-C.

It seems this dichotomy extended to my presentation as well, so I feel it's worthwhile to fill in here some of the things I had to leave out of the talk. Trying to fit an introduction to an "alien" language, a sampling of the SDK, and a coding demo into a 50 minute presentation was always going to be a challenge. Some things had to go. A lot had to go! In the end it was a case of following the adage, adopted by the iPhone community, of do just one thing but do it well. At least the first part worked out.

Why the focus on Objective-C?

There is more to iPhone development than Objective-C. Even if you leave Monotouch out, the bulk of what you need to learn is actually the libraries and platform. Then there's the IDE, Interface Builder (more on that in a moment), the headache of submitting your application to Apple, the review process etc etc.

However, these are all things you can readily read about on the internet or in books. In the case of the libraries learning them is actually pretty easy - it just takes the time to read the docs. Knowing what to look for takes a bit more effort, but even that is usually just a case of googling around. So the value of trying to cover just a fraction of that in the time allotted is questionable. I did try to show a little of XCode and the APIs in my code demo - just enough, I hope, to show that you can get a lot done with a few lines of descriptive code.

But here's the bigger problem: just to be able to demo those few lines of code I needed to explain enough the syntax of Objective-C for the demo to make sense. Learning Objective-C for the first time is not easy right at the start, but that's exactly where I needed to be!

So for my 10 minute code demo to make sense, all the slides preceding that were the minimum that seemed necessary just to get to that point. Just writing the code and hoping people will follow it wouldn't cut it!

But why use Objective-C at all? With Monotouch gaining traction - and just the day before the presentation getting full debugger support - isn't it easier to just use that? Well, I'm not entirely qualified to answer that as I have yet to try it for myself - but it certainly looks very good. In the U.S. my counterpart for the iPhone sessions was Rory Blyth and he seems to be all over Monotouch.

In my presentation I brought out a few points that I believe show that at least a basic understanding of Objective-C is necessary to be an effective iPhone developer - for now, anyway. From what I have heard Rory made similar points in his presentations. They are:

• Documentation - all Apple docs for the iPhone APIs (except those that are pure C APIs) describe the Objective-C usage.
• Books and web articles - similarly the majority of these also assume Objective-C
• Debugging - this was an obstacle, but, as mentioned, has now been addressed in the latest release. Again I do not have first hand experience
• Not all the APIs have been exposed to Monotouch yet, although it's getting pretty darn close. Notably Core-Data is currently missing and there are other limitations that may or may not be of relevance

Of course all of these will change, although - as with Mono itself - there will always be a certain amount of catch-up as the raw APIs evolve.

Another potential obstacle is that Monotouch has a price associated with it. It's not an unreasonable price, but it may put off those just looking to casually tinker with it. One point that I forgot to mention in the talk (there were a few - due to technical difficulties I did not have access to my notes) was that, even with Monotouch you still need to be running on a Mac! One or two Twitter comments seemed to imply otherwise so it's worth clearing that up. Also, to run on the device or submit to the app store you still need to join Apple's developer programmer at the same cost ($99/ year for a non enterprise membership). Therefore the cost of Monotouch really is an additional cost.

So the premise of my presentation was that, if you still want to pursue iPhone development, whether or not you plan to use Monotouch at some point, you'll need some Objective-C fundamentals and that has a steep initial learning curve. I attempted to temper that by observing that the curve flattens out quite quickly the other side, and that the iPhone APIs are quite sensible, easy to use, and fairly self-documenting (even if this leads to quite a verbose naming style at times).

What I wasn't saying

As often happens when you put yourself out there, some of my motivations appear to have been misconstrued. I did not give this presentation to try and convince anyone to take up iPhone development, nor to dissuade them from doing so. If some have decided that, having seen Objective-C, they want nothing to with it, then hopefully that just means that I saved them some time, rather than doing them any injustice.

My objective (pun partly intended) was really to say that, if you have already decided that you want to have a go at developing for the iPhone, don't be too put off by the initial difficulty - it gets much easier. Beyond that I hope that I clarified some things. If you never intended to do it in the first place I believe it's always beneficial to look at other ways of doing things - regardless of whether you consider them to be better or worse. That was the theme of the conference, after all.

Why didn't I show Interface Builder

This was probably the number one question posed to me directly, or on Twitter. For this I have two answers. Whether they are good answers I make no claim to:

1. My focus, as I've said, was on Objective-C. Having gone to some lengths to try to give an accessible crash course in the language basics in a small amount of time it didn't seem logical to then almost completely ignore it and use a GUI builder tool. Several people posted on twitter that my demo would have been simpler if I'd used Interface Builder to do it That may or may not be true but that wouldn't have supported what I was trying to do. I do concede that I should have pointed out, at least, that it could have been done using IB.
2. Not everyone thinks that Interface Builder is worth using for building iPhone apps. Personally I think it's fine for some things, if you're already familiar with it. For many tasks, especially if you'll have to customise the controls a lot anyway, it can add as much complexity as it removes. That is all IMHO, of course, and others are welcome to disagree with it - as they will. My purpose here is just to explain my own motivation in largely excluding it from the presentation

Was it really that bad?

If you didn't see my presentation you may conclude from the above that the whole thing was a disaster! Actually I was pleasantly surprised at the volume of positive chatter on the Twitter back-channel, as well as from people who approached me personally. Obviously I was pleased that they enjoyed the session and that I didn't completely suck, but more than that I was pleased that what I set out to do did reach a good number of people. Thanks to everyone that gave me feedback, good and bad, directly and indirectly. This has certainly been a challenge and I've enjoyed the opportunity of helping people to think along new lines.

Onwards

I know that I'll have picked up a few extra readers of this blog as a result of the conference, and that they will largely be reading it for iPhone related material. I'm not a prolific blogger, but I have been posting a little more frequently of late, and intend to keep the momentum going. I don't just blog about iPhone development, however. I also cover C# and C++ as well as more general themes. See the archive links on the side for more.

Time Machine

Enabling Time Machine for network drives

defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

Getting a working disk image

Time Machine could not complete the backup.
The backup disk image "/Volumes/backups-1/Wall-E.sparsebundle" could not be created (error 45).

Finding the Computer Name

Finding the MAC Address

ifconfig en0 | grep ether | awk '{print $2}' | sed 's/://g'

Creating the sparsebundle

sudo hdiutil create -size 320g -type SPARSEBUNDLE -nospotlight -volname "Backup of <computer_name>" -fs "Case-sensitive Journaled HFS+" -verbose ~/Desktop/<computer_name>_<mac address>.sparsebundle