At NSConference Dave Dribin made the following statement in a slide:
Delegates are preferable to Notifications which are preferable to KVO
Now this caused a bit of a murmur on Twitter, as it was taken as "KVO is bad". As this is an important topic and not one that can easily fit into 140 characters I thought I would write a post to outline my rules for when to use each technology and why use them where I do.
One of the main reasons delegates were listed as the most preferable is that they provide the least 'magic' way of communicating between objects while keeping them loosely coupled. It sends the message directly to the object and you can see what method is being run. As such it makes your code more self explanatory. So whenever you have a 1 to 1 relationship between two classes, opt for delegation over notification.
Notifications should really be used wherever you would use a delegate, but need to communicate with any number of objects. They should really be thought of as 1 to many delegates. Quite often in Cocoa you will see a case where there is a notification and a delegate method for the same event (eg change of selection in a table view). These are cases where 80% of the time you just need a 1 to 1 relationship, but occasionally do need a 1 to many relationship. You will rarely encounter this in your own code, unless you are building a class for use in multiple apps.
This is where I have found KVO to be the most powerful. You need to keep various UI elements in sync with your data model. Changing the value of the model from one view should also update the value in other views. KVO was built for exactly this situation and as such requires much less code than delegation and notifications.
To achieve the same effect with delegation or notifications you would have to add delegate methods or post a notification in each setter method of each model object. This obviously is a lot of code that needs to be written. Code that could have bugs and code that makes your source more cluttered. KVO of a value in an object requires just one line of code and the implementation of one method. And if you use bindings then it is actually no code at all.
I'll start with the exception to this: if you have multiple callback options then use delegates (eg NSURLConnection). But the vast majority of asynchronous operations need just a single callback. In these cases, if you are using Mac OS X 10.6, then you should be using blocks instead of delegates. Blocks reduce the layer of indirection in your source by putting the call back information inline with the invocation of the method.
The next two rules aren't quite rules of communication, but are relevant to the discussion at hand.
This should be pretty obvious. If something in your code isn't explicitly clear from the code itself then comment it. If you are sending off a notification say why you are sending it off, so you can get an idea of what it is doing elsewhere in the application.
There is no such thing as magic in programming, simply things we don't fully understand. If notifications, delegation, KVO or anything else seems like magic, then read up the documentation on it or ask a developer experienced in that area to explain how it works. When you find out how they work you realise that what seems like magic is fundamentally a very simple process.
Ultimately, what Dave said was right for some scenarios. Each technology has its use case and you should only use it where it is needed. You should always aim for the smallest amount of indirection in your code while still retaining loose coupling of classes. KVO and notifications are necessary in some occasions (unless you want to go crazy with delegation) but they should only be used when they are needed.
I have seen a lot of questions and comments on the iPad and I feel I need to write my responses to some of them down. So here goes.
The iPad is for casual computing. It is what many people said the iPhone would be for, before realising that the small screen isn't all that good for casual computing. The iPad really is a remarkable device, showing off the technology combination the iPhone introduced us to in a much better way.
But who is it for? Well it is for everyone. Some people are saying it is for their parents and that it isn't for geeks or professionals. I disagree. Yes it is ideal for those who don't want to learn how to use a computer, but that doesn't mean that it won't also be great for the computer literate. Hell, look at the popularity of the iPhone, that isn't just computer illiterate users. But just because it will work well for everyone, doesn't mean it will work well for every task.
Apple explicitly said that the iPad sits between the iPhone and the Mac. They have specced it out in that range, are marketing it in that range and priced it in that range. It sits in the middle ground, which is exactly the same place that many low end PCs sit. The exact sort of PCs that are bought for workers, schools or just by people who want a computer to get online but don't need anything powerful.
Think of all the people who have to travel around with bulky laptops just to fill out some forms when they see customers. The iPad is a much more portable way of providing that same functionality, for what would be a reasonably similar price.
In education the iPad would be invaluable. With the iBooks system, iTunes U, iWork all on this one lightweight device which costs only a bit more than a low powered laptop, it is the perfect education tool. It becomes the textbook, the educational video and the work machine all in one. With the ability to type but also sketch with your finger it could replace pen and paper for note taking for many people.
And finally think of the casual user. You don't need a bulky computer system any more, you can buy a sleek iPad that you can easily store in a drawer when you don't need it. It is powerful enough for everything a casual user could want, and then some. There is also something else significant I will get to in a bit.
From a technical point of view it pretty much is just a big iPhone. Sure it is faster and has different UIs on the apps, but it is running the same fundamental core. But it is very easy to underestimate how important the bigger screen is. There are many applications that work ok on the iPhone but would work so much better on an iPad
In the keynote video the developer of Brushes was brought on stage to show off the app. The extra screen space allows a much bigger canvas with more powerful tools. The iPhone lets you build a toy paint app, the iPad lets you build a real paint app.
The iPhone also doesn't really work for things such as office applications. Pages, Keynote, Numbers. Sure you could do them on the iPhone, but they wouldn't provide a good experience. The iPad offers a screen resolution that allows you to make these sorts of applications possible.
The other key thing is that there are some app concepts that work well on the iPhone but not on the Mac. There are also some that work well on the Mac but not on the iPhone. On the iPad the majority of these concepts from Mac and iPhone work equally well. You can build desktop calibre apps for the iPad, which you couldn't for the small screen of the iPhone.
The iPad replacing the Mac is as likely as it replacing the iPhone. The iPad is a 1GHz device with up to 64GB of storage and a 9.5" screen supporting a 1024x768 resolution. For casual computing that is fine. But for high performance tasks? No. For shared media system? No. For doing work that requires very large amounts of screen real estate? No.
For the iPad to replace the iMac for example it would need to have a 27" screen with 2560x1440 resolution, a 2.6GHz quad core processor and 1TB of storage. The fact is that such a machine would be both hugely expensive and incredibly impractical.
In the same way that an average laptop is always less powerful than an average desktop at any period in time, the iPad will always be less powerful than an average laptop. It is basic economics and physics. New high powered processors produce more heat and so need more cooling, over time processors of equivalent power will be made more efficient and smaller. The iPad is 1GHz, Macs reached 1GHz 8 years ago.
The iPad is also a much more personal device. I wouldn't expect to see many groups of people gathering round an iPad to watch a movie. The Mac provides a much better group media system due to the bigger screen size. Throw in the fact that you can add a remote and front row to the Mac and you have a home entertainment system, which the iPad is not.
Some people wanted a touch screen Mac with no keyboard or mouse. Such a product would fail miserably. This is essentially what a Windows Tablet/Slate/Whatever-they're-calling-them-this-week is. It is a laptop with the keyboard chopped off. And they provide a terrible experience. Not because of the hardware, but because they're running Windows.
Now that isn't to take a jab at Windows. The issue is that Window is a desktop OS. It has been designed for use with keyboard and mouse and doesn't work too well with a touch screen. Like OS X it has some multi touch functionality hacked on, but you are still moving a mouse cursor about and clicking on a 1px point.
A user interface for a touch screen where the primary input method is your finger requires a hugely different user interface. You can't have a 1 pixel line you have to touch and drag as you do with split views. You need to fundamentally change how controls behave as they need larger target areas.
Many parts of a desktop OS are irrelevant as well. Scrollbars aren't needed on a touch screen. They would take up valuable screen space that can otherwise be done by stroking your finger along the screen. Scroll areas are also inverted. Drag a scroll bar down on a desktop and the page moves down, drag your finger down on an iPhone and the page moves up. This is because you no longer have the disconnect between screen and input device.
There have been two large groups of people talking about multi tasking. Those who want it and those who think that casual users won't use it. Both groups are right and wrong. The iPad needs multi tasking, but it doesn't necessarily need to mean multiple apps running at once.
For those who don't think it is needed, I would ask whether you multi task in real life? Yes you do. Off the computer you listen to music while you work. On a computer you flip back and forth between a web page and a word processing document. You do multi task.
What you don't do is use 20+ applications all at once. Sure I have over 20 applications open but I don't use them all. As I'm writing this blog post I'm listening to music while flipping between typing up and researching on the web, with the occasional glance at twitter. Now on the iPad I could just exit to the home screen from Pages and open Safari, find what I want then copy and paste back into Pages. Then if I want to change my music I open up the iPod app and change it there.
The issue is that I am multi tasking whether the iPad allows me or not, but I'm having to go through the awkward process of quitting an app, opening another app, quitting that, opening the previous app. There needs to be a limited ability to switch quickly between a certain set of apps.
One way I have thought of is to use a 4 finger swipe. It would work much like 4 finger swiping on a MacBook Pro trackpad. Swipe horizontally and be presented a list of 'open' apps under your finger which you can choose from. Swipe vertically would bring up the home screen to open a new app. This makes the process much faster.
The best thing about this is that it can still be quitting the applications. I'm just not having to move my finger down to the bottom to press the home button, then back up to where I was on the screen to find the app I want (which may or may not be on a different page of apps). It removes the unnecessary movements of the hand as your switching appears under your finger and also reduces any sort of searching your brain has to do as what you want is in a line of a few choices.
What hasn't been talked about is the significance of the 3G networking deal. This is truly a revolution. No contract, you can sign up and cancel any time you want and it is a low monthly fee. If you only want the one device then this is the easiest way in the world to get on the internet in your own home. No installing filters and routers and modems. No phoning up an ISP to get them to connect you up in the next few weeks.
Sure it isn't the fastest internet, but it is fast enough for most basic uses. This is getting online the Apple way, except unlike the iMac adverts of the late 90s, there really is no step 3.
The iPad truly is a revolutionary device to those who can see its potential. To those who can't it is just an expensive, large iPhone. At the same time, it won't replace the Mac or the iPhone, it just isn't in the same market as either of them. It does have a few flaws at the moment but these are easily fixed. What is important is that this is a glimpse of one of the future forms of mainstream computing.
Back in July M Cubed started offering design services. This was meant to be an alternate revenue source to our software that we could rely on. Unfortunately this didn't turn out to be the case. While technically M Cubed is a 2 man operation, it is in reality a 1.5 man operation as Fabio has a separate day job.
Having a day job and then coming home and working nights and weekends leads to a person being worn out very quickly. A lot of our design work was being delayed due to Fabio not having the time or energy to do work and this was also filtering down into design for our products. Minim 2.0 was originally planned for a late november release, but delays in design related stuff meant it kept being pushed back.
The delays meant that the money coming in from design wasn't really worth the effort, and I was unable to help as I'm not exactly icon designer material. This has meant we have had to make the decision to stop offering graphic design services. While we were able to deliver what we hope was high quality products, circumstances meant we weren't able to offer high quality service. It is better to not do a job at all than do a bad job.
While we are stopping our graphic design services, we are introducing two new design services where we can offer a high quality of service as they are areas of design I am able to handle myself: Usability and Accessibility.
There are many services available to Mac and iPhone developers for graphic design. A quick google search will bring up pages of people offering icon or UI design services. But there are very few services that focus purely on usability and none that I have seen that focus on accessibility.
So what will our usability and accessibility design services entail?
Well in a nutshell, you give us your app and we will pick through the user interface and point out any areas where usability could be improved. We will explain why things are in need of improvement and what items are urgent.
Of course, there are different degrees of usability. You can make any user interface usable, in the sense of doing what the user expects, by following a series of rules. But usability can also be about how a user feels when using your application. Is it just functional or is it enjoyable? Our usability reviews will provide suggestions for areas where your user interface can be re-thought to make it highly enjoyable as well as functional, turning a user who is merely happy with their purchase into one who raves about your app to their friends and co-workers.
Our accessibility reviews will work in much the same way. We will go through your application and highlight areas where accessibility is lacking and give you details on how to fix them. But we are also going to do something a bit crazy. We will also show you how to find and detect the majority of accessibility problems yourself.
"But surely that is what we're paying you for? What is the point of us coming to you if you're just going to tell us how to do this work for free?". Very good questions. The fact is that 90% of all accessibility work is trivial. While I certainly am not opposed to you giving us your money, I believe that it is ultimately a waste of your money and of our time to keep coming to us for help with trivial matters.
What you may need help designing is the non trivial matters. How do you make a custom control accessible and what should the interaction model be for disabled users? What is the flow of my application like for disabled users? In a way, if our usability design is aimed at abled users of your software, our accessibility design is the exact same thing but for disabled users.
So how do you procure our services? Send us an email with details of your needs to design@mcubedsw.com and we will get back to you with an estimate of how long we think it will take. We charge an hourly rate so this will give you a good idea of how much you can expect to pay. So get in touch and start getting feedback on the accessibility and usability of your apps today!
As with most things in life, there are two opposing schools of thought when it comes to software. When it comes to the size of things you can either go big or small. Is your app going to have a large scope or small scope? Is it going to target the general market or a particular niche?
When I started work on Code Collector Pro 1.4 over the weekend I was confronted by the issue of whether to go big or small on two key points: the size of updates I release and the size of the classes I write. These are key decisions that affect all the software we write, so it is worth deliberating over them. Now these aren't questions I've only just asked, they are ones I've looked at continuously and am only just starting to set myself on.
There are two extremes to software release size. At the large end of the scale are products like Adobe Creative Suite, Microsoft Office and Apple's iWork and iLife suites. They have a release roughly every 1-3 years and they feature large updates to several applications. At the smaller end of the scale are products like WebKit or Adium, where small releases are made every day in the form of nightly builds.
Most Mac devs go for the middle ground of this, releasing several medium sized updates a year, though what constitutes a "medium sized" update varies widely. I've been striving to reach the smaller end of the scale with little success until now. The combination of full time education limiting coding time, and a lack of discipline when building releases has led to a series of sporadic releases that are quite large.
With Code Collector Pro 1.4 there was a long list of features building up. There hasn't been a release for 14 months and the featured planned involved would take a good 3-4 months to complete. The release eventually included a UI overhaul, new sharing features, syncing and a re-written syntax highlighting engine.
So I opted to break it up into smaller releases. The UI overhaul is a collection of many small changes and some under the hood changes and nicely separates into a different release. Sharing improvements and syncing were the two major features I wanted for 1.4, so these would fit nicely into a second release. And the syntax highlighting improvements would also fit nicely into a small release. As such the large 1.4 now became much smaller versions 1.4, 1.5 and 1.6.
The current plan is to work on 1.5 straight after releasing 1.4. But why not then combine them? Well there are 3 main reasons not to:
For those of you who aren't programmers a brief explanation. A class is a unit of code. It contains data and actions upon that data. While not always true, generally a class = a separate file of code. As with release sizes you can either have a few large classes or lot of small classes. Cocoa provides ways to help you divide your code up. Code relating to windows goes into Window Controller classes, code relating to any documents goes into your Document class.
Prior to OS X 10.5 there was a missing piece of the puzzle though. While you could easily split up your application into windows, it was harder to split up these windows into individual views. Then in 10.5 Apple introduced NSViewController, which made this task easy. This means you can split your UI up into even small classes, which leads to easier to maintain code and more reusable code.
As an example, these are the window and view controllers that make up a typical screen in Minim:
As you can see, this one screen has 4 main components. The window, which contains a sidebar and an info panel, the latter of which contains the current tab. Each of these is coded in a separate file. This means that if I need to edit something to do with the sidebar I open the sidebar view controller's file. It also makes things more re-usable. There is a file that contains the file manager view controller class. This same class is used for songs, podcasts, albums and shows.
Now Minim is build with Leopard in mind. Code Collector Pro however is very much a Tiger era application in its design. This is what Code Collector Pro's main window looks like from a class point of view:
There is one class that manages the window, the sidebar, the snippets list and the code view. It even controls the inspector panel. At 2420 lines long it is the second biggest class in any M Cubed app, beaten only by the class that talks to Lighthouse in Lighthouse Keeper. That over 3 times the size of the biggest class in Minim.
Now while a large class isn't necessarily a bad thing, a large class that does lots of different things is. If I want to edit something to do with the sidebar in CCP I've got to search through 2400 lines of code to find what lines are relevant, compared to Minim where I open a file where all the lines are relevant.
I'm currently working through the process of breaking up this monolithic class into much smaller, more manageable chunks. I've already managed to split it into 7 classes, I may be able to divide those even further. Ultimately though, this will add nothing new to the application. It will work exactly the same as it did before. What it does do is make it easier to add new stuff in the future.
So does size matter? Well as the title of the post suggests, it does. But what is a good size depends on many things. To quote Albert Einstein, "Everything should be made as simple as possible, but not one bit simpler". You should strive to make things as small as you can, but not unnecessarily. While I can break one large class up quite easily, another may not break up. It may be the case that it is already as small as it needs to be.
The same goes for releases. I can split up what was going to be CCP 1.4 into 3 different versions quite easily, they logically split up. However, Minim 2.0 couldn't have been split up. It was a large project, but it couldn't have been made any smaller. Everything has its size, the job of anyone creating something, be it a piece of code, a product or a business, is to find the right size.
This is the M Cubed Software weblog. From time to time we post information about our apps, including updates, tips and tricks or even the story behind how they were created.
If you would like to subscribe you can do so using the link below
You can view our monthly archives by using the links on the left, or search our blog posts using the field below to find what you are looking for.
Nov • Oct • Sep • Jun • Apr • Mar • Feb • Jan
Nov • Aug • Jul • May • Apr • Mar • Feb • Jan
Dec • Nov • Oct • Sep • Aug • Jul • Jun • May • Apr • Mar • Jan
