Recently, Mark Wadham dumped his iPhone 4 in favour of an Android-based phone, the HTC Desire S and wrote a blog post about his switching experience.

Overall, he really seems to like his new phone, but he also lists a number of shortcomings compared to the iPhone. I noticed that one particular complaint stood out amongst the others, and Mark tried to play it down a little:

While certainly not bad, the UI clearly wasn’t designed by the UX experts at Apple and I spotted a number of irritating inconsistencies and unintuitive aspects of the ui.

It’s hard to gauge just how much of this is simply me being used to iOS, but there is definitely some room for improvement of the user experience. I think if the UX guys at work tried this phone they would find it quite irritating to use.

To disable [haptic keyboard feedback] I had to turn off two settings in completely different parts of the menu…. yeah, people into UX shouldn’t get this phone

It’s not as fun to use as an iPhone, and if you’re a real UX freak you should probably stick with the iPhone at least for now

Despite the lesser UI experience, I actually like Android, mostly because of the freedom.

[The Android phone is] missing the cleanness of the user experience, consistency in the user interface […]

Overlooking the irony that Mark switched to Android because it's more "open" than iOS, he apparently thinks only "UX freaks" would care about the user experience, which couldn't be more wrong. We are all users, which is why we all care about user experience (except maybe for @evilmattgemmell).

Perhaps only a user experience expert can pinpoint what exactly is distracting or imperfect about a device's user experience, but those shortcomings are certainly going to annoy all users. If your device or software (or any other kind of product really) annoys your users, you have utterly failed in designing something worthwhile. A simple "usable" doesn't cut it.

Today is my last day as an employee at Enough Software and as of tomorrow, I will be independent. Hopefully this means I'll get to spend more time working on iOS and Mac projects of my own, but especially in the early stages of my new-found freedom, I will do a lot of contracting to cover the bills and make enough money to pay for our upcoming wedding (in September) and our honeymoon (January 2012).

Over the years, I got to work on a number of exciting projects (such as S-Banking, which was #1 in the German App Store for quite some time and was even featured in one of Apple's TV commercials in Germany) at Enough Software, and I'll really miss the place and my co-workers. There are a lot of talented and bright people working here (including the best boss in the world), and transitioning from working at an office to working from home won't be easy. I'll also miss downtown Bremen, which is an awesome place to work - everything is so close!

On the other hand, I already have the best co-workers in the world, on Twitter. Fraser Speirs once said that Twitter is like an office for the self-employed, and I couldn't agree more. Before Twitter, it would have been harder for me to take this step. I am pretty certain that I would feel that my fiancé, Maxie, and I were going through this alone and that no-one could possibly relate to what we're doing. With Twitter, I know there are dozens of others who have made the same experience or are doing it right now. When I tweeted about my last day as an employee, I got over 50 people congratulating me and wishing me good luck in my future endeavours in a matter of hours. People were even complaining (jokingly, I hope) that their timeline consisted of nothing but people congratulating me. If this isn't the right place and the right time, what is?

I am really excited about the upcoming changes, but of course, as with any life-altering decisions, I am also a little scared. It might all backfire and I might be looking for a new permanent position in a few months. I am hoping that my skills as an Objective-C developer are sufficient, so this hopefully won't happen. But there are just too many variables in a situation like this and it might not depend solely on my abilities.

I'm already working on a new iPhone app which I'll hopefully be able to tell you more about in a few weeks. I also have just started a contracting gig for a well-known Cocoa developer here in Germany, so my bases for the beginning should be covered. I also have a half-finished update for Folio Case, which needs just a little fine-tuning, localization and beta testing before it's ready to go out. Looks like there won't be a shortage of projects for a while. :-)

In the end, working on my own means that I will enjoy a lot more freedom than I used to have. I will have a say in which projects I will do, and which projects I won't do. If the market stays the way it is, this might mean that I will get to try new things and even have my input on UI and UX valued - which isn't always the case when you're contracting. It means letting go of a steady income, which is something I will have to adjust to, but I am pretty certain that eventually, it will be worth it from a financial perspective - not to mention my personal happiness.

Today is my last day as an employee. Tomorrow, I will be an indie.

Unless you suffer from Not Invented Here Syndrome, you most likely enjoy using open source iOS code that other developers share via github (or other places) as much as I do. Whenever I see a useful new piece of code, be it a whole library or just a simple class, I immediately want to check out how it works and begin to think about how and where I can use it in an actual project. In other cases, I have a particular problem that I need a solution for and I may check to see whether I can find something suitable which already solved that particular problem. Then there's also the case where I develop a solution and open-source it for everyone to use.

Over the past few weeks, I compiled a list of what I think are useful and/or interesting open source iOS libraries/classes, focussing solely on components that provide some sort of drop-in UI and leaving out anything that doesn't require linking against UIKit. If there is enough interest, I may write another blog post on non-UI components in the future.

So, without further ado, here are some components that can be useful in one of your next iOS projects, or which you simply might find interesting to play around with. Some of these are well known, but hopefully you'll find something you didn't know existed.

Three20

Three20 is an open-source Objective-C library, originally developed by Joe Hewitt as part of Facebook Connect for iPhone. Three20 is probably the most well-known 3rd party library for iOS development and is in use in numerous popular iOS apps, such as Facebook, Posterous and Pulse.

The library uses modular design, so developers can choose which parts of the library to use in their own projects, or develop extensions on their own.

Among the things the library offers is a launcher which resembles the standard SpringBoard on Apple's iOS devices. Three20's URL-based navigation all across the app brings with it persistence, to ensure a smooth user experience even if the app was terminated while in the background.

One of the most popular components is the photo viewer, which uses the standard datasource pattern to mimick the user interface of Apple's own Photos app. The message composer emulates Apple's Mail app to send any kind of message and is completely customizable, including autocompletion of recipient names, based on a data source you provide.

There are also a number of clever components to facilitate the use of remote content in your app, such as an image view which takes a URL as a parameter and loads and displays the content by itself and a similar class for a table view. This is useful in a lot of cases and can vastly reduce the amount of glue code a developer has to produce.

Another notable component is the built-in HTTP disk cache, since the default iOS component only uses a RAM cache - and as we all know, RAM is a scarce resource of many iOS devices and its contents will be lost when an app is shut down.

Tapku

Perhaps the second biggest library after Three20, Tapku also emulates a lot of what Apple has built into their apps that come with iOS, but has left out of the Cocoa Touch APIs. A prominent example of this is Coverflow, which Apple uses in the iPod app when in landscape orientation. I've used Tapku in the past for its calendar component, which closely resembles what Apple uses in their Calendar app.

The library comes with an example project, so you can check out each component before you add the code to your app.

InAppSettingsKit

One of the not so strong points of iOS is user-adjustable preferences. The Apple-approved way of dealing with such preferences is to use a settings bundle, which will automatically appear in the Settings app. There are a number of advantages to this approach, such as consistency across application, but it also means that the user has to specifically look out for an entry for your app in Settings in order to make changes - or they have to be told that there is such a possibility, which is plain annoying.

Enter InAppSettingsKit, which allows you to mimic the behaviour and style found in Settings.app inside your own app, based on your settings bundle (although there are customization options). The library provides a uniform experience for your users along with great ease-of-use.

ShareKit

Many people nowadays use social networks as a large part of how they communicate with their friends and relatives, and to find information and entertainment. Users commonly share items they find interesting with their friends on social networking sites, and it can make sense for your app to allow users to easily share things.

This is where ShareKit comes in. It provides an easy method to provide sharing functionality for a number of social networks (such as Facebook, Twitter and Delicious) plus e-mail. The library's design is rather smart, to it will only offer those services which support the type of content the user wants to share, such as URLs, images, text or files. It even works offline out of the box and will persistently store items which can then be send when a connection is available.

Route-Me

Route-Me is an open-source replacement for large parts of MapKit, including support for various map sources. As of now, it supports OpenStreetMap, Microsoft VisualEarth (now Bing Maps) and CloudMade out of the box. There are classes for various other map sources, such as Yahoo!, but those are included only for demonstration purposes and are not intended to be used in an actual application for licensing reasons.

Hockey

Ever since iOS 4.0 introduced over-the-air installing, developers have been finding interesting ways to use it, especially to facilitate distribution of ad-hoc builds, which are commonly used for beta testing purposes.

Hockey uses this approach to really make it easy on users to install new versions of apps they offering code for both PHP5-enabled servers and an iOS component which allows for in-app updates, including support for update notifications.

The client library is optional though, so Hockey can also be used for installing and updating apps from Safari.

MTStatusBarOverlay

In the past few years, we've seen a lot of UI innovation come from 3rd party developers, such as Tweetie's (now Twitter for iPhone) pull to refresh (see EGOTableViewPullRefresh below) and Reeder's status bar overlays that indicate current progress without wasting valuable screen estate.

MTStatusBarOverlay replicates this status bar overlay and makes it easy for developers to implement this kind of behaviour in their own apps, along with extensions such as a detail view that pops out of the status bar.

ARAnnotatedSlider

Written by yours truly for Folio Case, this is more an example of showing how to use Key-Value-Observing (KVO) in order to react to UI changes than a complete 3rd party library, but it should be able to adopt it for usage in your own apps without too much hassle.

This example allows developers to add a callout view to UISliders, thus giving users direct feedback on their actions in the same place where they are currently focusing on anyway.

EGOTableViewPullRefresh

Ever since Loren Brichter came up with the pull-to-refresh mechanism in Tweetie (now Twitter for iPhone), other developers have tried to emulate the behaviour. One such implementation is enormego's EGOTableViewPullRefresh, which comes pretty close to Brichter's original (sans sound effects).

Cross-posted to the Enough Software Company Blog.

In Folio Case, I'm using a custom UISlider with annotations to allow users to easily skim through the document and find the page they want. When the user taps the knob, a small bubble shows up that shows the page number that corresponds to the position where the knob currently is. The page number within the bubble is constantly updated as the user drags the knob around. When the user lets go, the app turns to the selected page, the knob snaps in place and the bubble slowly fades out. This approach makes sure that the user gets the information when he/she needs it and it doesn't stand in the way of getting things done.

Ever since Folio Case was released, I've been asked how I achieved this effect, as there is no built-in functionality for this behaviour in UIKit. The short answer is: using KVO (key value observing), I track whether the knob is being touched and moved and react appropriately.

The long answer is, well, longer. If you're not familiar with the concept of KVO, you might want to read Apple's Key Value Observing Programming Guide. In short, Apple describes KVO as "a mechanism that allows objects to be notified of changes to specific properties of other objects". In practical use, this means that I can register as an observer to any property other classes expose, such as a UIView's frame. If I choose to do so, I will be notified whenever the object is being moved within its superview, which causes its frame to change.

Now, in order to track a UISlider's knob movement, we will have to get a little tricky. A UISlider instance, once it is being displayed on the screen, has three subviews, all of which are instances of UIImageView. The third and foremost UIImageView instance contains the UISlider's knob. This might change at any time, so if you're going to use an approach like this in production code, be aware that it might change with the next release of iOS. However, the worst thing that can happen in this case is that the bubble won't be shown anymore.

In ARAnnotatedSliderView, which is my class to manage the UISlider and the bubble that is being conditionally displayed, I have the following method:



kARPageScrubberViewKeypathFrame and kARPageScrubberViewKeypathTracking are simple constant NSStrings, @"frame" and @"tracking", respectively. The first property I want to observe is the knob's frame, to be notified of changes in the knob's positioning. The second property I want to observe is the UISlider's tracking property, to be notified when the user starts tracking the knob with his/her finger and when they stop, so I can dismiss the bubble. When one of those notifications kicks in, I react to it using this method:



When the knob's frame was changed, this code makes sure that the bubble view stays right on top of it to ensure a smooth experience for the user. When tracking starts, I can use this notification to display the bubble, and when tracking stops, I can set up a timer to dismiss the bubble after a short while.

As you can see from the complete code, this class is taken from Folio Case without (many) changes, and so is not well configurable. The bubble will always display "Page %d" where a class that was intended as being reusable would probably allow you to customize this setting. I've set up a small example project for this on Github, if you'd like to check it out and play with it. If someone ends up making a fully reusable class out of this, please let me know.

If you'd like to get back to me, feel free to leave a comment here or follow me on Twitter.

When I released my iPad PDF reader Folio Case on Thursday, I received a lot of praise for it. People found it to be beautiful, easy to use, even calling it the most elegant solution currently available on the iPad. Since Folio Case was focusing on a very pleasant reading experience, I never regarded the most downloaded PDF readers as my main competition - the differences were just too big, since those apps usually focus on a huge amount of features and lagged behind in user experience.

However, Apple today released an update to iBooks, their fantastic eBook reader software from which Folio Case takes quite a bit of inspiration. iBooks is a direct competitor because it plays in the same league as Folio Case, if not actually higher. It has a reduced feature set, but a beautiful reading experience. The biggest problem here for me is, obviously, that iBooks is free while Folio Case is priced at $5.99 - and they say you just cannot compete with free. I cannot say I planned for this to happen, but I'll likely find out soon if it is possible to sustain a competitor to iBooks. The least I can do is try to keep my app from finding its untimely death at the bottom of the App Store charts.

So what's my plan of action here? Fortunately, Folio Case had its origin as a fun little project on the side which just started because I didn't like any of the available PDF readers out there, and it seems others didn't either. That means that it's easier for me to keep this app going than it would be for someone who depends on the income from their App Store sales. Speaking of sales, I thought I'd share some sales numbers here to illustrate my point:

Thursday, June 18 2010: 85 sales
Friday, June 19 2010: 100 sales
Saturday, June 20 2010: 123 sales
Sunday, June 21 2010: 76 sales

That's 384 sales in total since Folio Case was approved for sale in the App Store, or about € 1,180 in revenue for me after Apple's cut and before taxes. Not bad for four days of sales, but I don't expect these to stay at this level at all, for two reasons. First, there's now pretty good competition which is free. Second, this was the launch, which had quite a bit of buzz on Twitter and was bound to have higher sales numbers than what an app like this would get a few weeks after its release. I'm pretty happy about selling 20 copies of Folio Case per day in the long run, but even that is going to require some effort on my part.

So what am I going to do in the future? While Apple has several advantages over me, especially in the resources department, I believe I can be more flexible and deliver more quickly. I can have direct connections to customers, which helps both me and all of them. For example, on Saturday I had a pissed off customer who was complaining about crashes in Folio Case and demanded his money back. We wrote back and forth, I got help from him and identified the issue and submitted a fix, which is currently in review. The same customer just wrote to me, saying that iBooks behaves worse than Folio Case in his case, crashing more and not recovering at all. Suffice to say, thanks to me being able to help him out and taking a real interest in his problem, the customer is now rather happy.

Cases like this will be my chance to keep Folio Case a viable product in the future. Right now, I am working on Folio Case 1.1 which will, among other features which I have yet to reveal, hopefully contain Dropbox support (Dropbox has yet to accept my application). Folio Case already allows downloading documents from the web, which iBooks doesn't, and this feature will help to allow users even more flexibility in managing their documents. Also, people seem to just love the page turning effect, and iBooks for some reason doesn't use that for PDF documents. Users who want a PDF reader which does exactly what they want it to do and offers a great reading experience at the same time will find it in Folio Case. In the future, I see Folio Case as the app iPad users should get when they have outgrown iBooks.

In the end, I cannot say whether it's a smart idea to put more effort into Folio Case from a return-on-investment perspective. All I know is that it's what I love to do, and it's what those existing 384+ customers deserve, so I'll just push forward now. If I didn't have a day job and were living off the money from my App Store sales, I might see things differently. But even if I only get 10 sales per day in the next few months, it was all worth it because it's just been incredible so far.

In some of the applications that come with the iPhone, such as the App Store and Mobile Safari, Apple uses a technique for paging-enabled UIScrollViews that show a little bit of the neighbouring pieces of content instead of displaying a single view controller over the whole width of the screen. I think those previews are a really great UI element, since they're much easier to spot than the UIPageControl which usually sits right below the UIScrollView. It shows the user that there is more (or no more) content right next to what they are currently seeing.

If you've ever used UIScrollView's pagingEnabled property, you probably know that this is not easily doable. The UIScrollView will stop only at multiples of its frame's width and cannot be configured to stop at shorter intervals. I recently needed to implement a paging-enabled UIScrollView and was trying to replicate this behaviour and found a way to implement these previews.

Read on for the full tutorial.

Read More

History of NSConference

Ever since the inaugural NSConference 2009 ended, I've been looking forward to the next one. I, pretty much like everyone else, had a fantastic time there and really enjoyed Scotty's approach to hosting a conference.

Despite a number of really great and thoughtful presentations at NSConference 2009, the main focus and benefit for me was community. I met so many interesting and smart people there who have helped me become a better Cocoa developer in every regard. NSConference is the kind of event you can benefit from even if you don't think the sessions will bring you much new knowledge.

With this kind of experience from last year's conference, Scotty (@macdevnet) and Tim (@timisted) had a lot of work to do. According to a blog post by Scotty, 85% of the delegates in 2009 signed up for the 2010 conference. That's a huge number and goes to show just how great the conference last year was. The question on my mind was not if this year's conference could live up to our expectations, but more how they would do it.

Changes to Last Year's Conference

There were some major changes in this year's conference. The most obvious one was that in addition to the workshops, which took place on Sunday, and the main conference (Monday and Tuesday), there now was an optional iPhone day that could be booked in addition to the main conference or on its own. This day even saw a number of new attendees, most of which did regret not going to the main conference after they experienced NSConference for themselves.

Another major change compared to last year's conference, which took place at the University of Hertfordshire campus in Hatfield, was that all workshop rooms, the main conference room and our hotel rooms were now in the same building. Even the restaurant and bar were there, which made it really easy to get to places and to find people.

A very welcome change were the sponsored soft drinks during the coffee breaks, including Red Bull. Yes, there was free Red Bull. It was awesome.

The Venue

The venue for this year's event was in a rather remote location in a town called Wokefield Park near Reading, England. It was easily reachable by car, but I took two wrong turns on the way and ended up really close to the edge of the world. A lot of attendees got there by public transport, which wouldn't really have been an option for me, since I was traveling from Stansted Airport. Given my plane landed at 7pm and the train line between Stansted and London isn't currently operating on weekends, it would have taken me at least 5 hours to get there. So instead I chose to rent a car and get used to driving on the wrong side of the road and lots of roundabouts.

Remote location aside, the venue was a great choice for the conference. The rooms were rather nice, they had Nintendo Wiis there (although I didn't have time to play) and they had a number of coffee makers in the hall way, which all provided decent coffee. The instructions to make tea were a little confusing, but fortunately Mike Lee (@bmf) applied his engineering talent to the problem and quickly figured out what they meant.

The Workshops

I did sign up for Matt Gemmell's (@mattgemmell) workshop appropriately titled "The World According to Gemmell", but because of conflicting schedules, I only got to experience about half of it. There was a lot of talk about the iPad, bathroom reading and the opportunity for us developers to create apps for the device or adopt our existing ones. We were sitting in groups and, as a group exercise, got to design an iPad app. Matt graciously provided a number of ideas for groups who couldn't decide what to do. There were also some opportunities to get live feedback from Matt and the rest of the group on problems people were currently facing in their own apps.

As I had to leave rather early, I don't really have any more insight to the end of Matt's workshop and no idea what was discussed in Drew McCormack's (@drewmccormack) workshop at all, but I'm sure others who were there will fill this void.

1st Conference Day

The main conference keynote was delivered by Mike Lee (of Delicious Library fame), who told us various anecdotes where he could apply his engineering skills to everyday (and rare) situations in his life. While doing that, he disclosed his super secret algorithm for awesomeness and encouraged us to fix problems whenever we encounter them and be the hero. During his session, Mike established the ongoing Matrix theme that we could see throughout the entire conference.

After an encouraging keynote, Jonathan "Wolf" Rentzsch (@rentzsch) took us on a journey through many inner workings of Mac OS X and Objective-C applications. He delivered great insight into static analysis, runtime analysis, code injection and enhancing. He introduced us to various tools and showed how they relate to our jobs as Cocoa developers and did a really great job of not diving in too deep, so even people unfamiliar with the subject and the tools could follow his presentation. Some of the things I took away from this presentation are of a philosophical nature which should prove helpful in my future career.

After this exciting subject, Dave Dribin (@ddribin) gave his talk about clean code, which involved a lot of practical tips and some really controversial theses about various design patterns, such as delegation vs. notifications vs. KVO and the use of singletons. These statements caused a lot of discussion during Q&A and during the whole conference, but Dave had a good answer to every single question that was asked, which for me really made the impression that he had some great points there. I left the session feeling good about the design principles I currently employ and with the intention of adopting even more of the practical tips he presented.

Next on the agenda was Drew McCormack's talk about data presentation, in which he focused mostly on table views (cells vs. views) and the Core Plot framework, which he started and helped develop last year. He presented various actual uses of the framework, which is still in development and pre-1.0. Based on my observation of the talk and what various other developers said during the break, Drew really got some attendees thinking about implementing the framework in their own apps.

The final session for the first day was Marcus Zarra (@mzarra) on Core Animation, which he just recently wrote a book on. His talk was aimed at novices and didn't dive in too deep, but gave a good overview about the topic. He introduced us to implicit and explicit animations, and showed a small demo app that proved how little animation code you actually have to write to get decent animations. Unfortunately, the allotted time for the session didn't allow him to go deeper and teach us about more in-depth procedures.

The first day of the conference came to a close with a delightful banquet, which took place in the same room where we had our sessions. We all got to have some great conversations with like-minded people over wine and a three-course dinner. It moved to the bar once the wine was empty where we continued to have a phenomenal time that caused many of us to go to bed rather late and catch little sleep.

2nd Conference Day

The second day of the main conference was kicked off by Jeff LaMarche (@jeff_lamarche), who was still severely jet-lagged and missing his clothes (he had replacements though) because the airline misplaced it and didn't deliver it until later that day. Jeff told us about some Objective-C language and design features and gave us an overview of runtime features, such as reflection/introspection. He made a point to make it clear that messing with the runtime can be rather dangerous, but he gave some safe-to-use examples of what can be done.

The second session of the day was Andy Finnell's (@macgeek02) in-depth talk on OpenCL using an example app where he modeled the effect of painting with watercolour. He talked about OpenCL devices, contexts, vectors and queues as well as the meaning of OpenCL kernels and various implementation details. Unfortunately, the physics involved in modeling the spread of watercolour on paper are rather extensive, and Andy lost me and several other listeners during that segment. However, he did put up the source code to his sample app, so we can investigate this on our own.

The next two sessions, on source code control by Dave Dribin and code signing by Graham Lee (@iamleeg), filled in for Matt Gemmell, who unfortunately had to leave the conference early for medical reasons. We were relieved to head that he did get better and is fine again now. Dave delivered his talk based on a talk he gave last year for a CocoaHeads group. He referred to version control systems as "Time Machine for your source code" and gave us various reasons on why we should use VCSs. His talk was very fact-based and had a history of source control systems up to current DVCSs such as Git and Mercurial. Graham Lee gave an overview of code signing and cleared up some myths around the topic and concluded with a demo.

Following the lunch break, Aaron Hillegass (@AaronHillegass) of Big Nerd Ranch and Cocoa Programming for Mac OS X fame gave a talk on data persistence. He commented on the change away from direct file system access which we're currently seeing in the "cloud" and on the iPad. He followed it up with rather interesting bits about sync services, algorithms, examples, archiving and DBMS, which lead to notes about Core Data. Aaron had various pros and cons about every persistence solution he talked about, even Core Data, which led to his recently developed open source BNRPersistence framework, which looks very promising and is a lot faster than Core Data in most cases. He mentioned that the framework is still work-in-progress and that the community is welcome to supply patches.

Right before the mysterious Cocoa Rumble, which I am not going to talk about here (you have to see it to believe it), Danny Greg (@dannygreg), Martin Pilkington (@pilky) and I (@arepty) presented Scotty with a few gifts that dozens of Mac developers from around the world contributed to. We have video for it, so I am not going to write everything down. Just see for yourself.

Obviously, this day was followed by a lot of drinks and chatter in the bar, and much like the previous nights, everybody seemed to enjoy themselves and went to bed way too late at night. Unfortunately, this marked the end of the main conference and already saw a good number of developers leaving.

iPhone Conference Day

The day saw Mike Lee delivering his keynote titled "Meet the User" to a partially renewed crowd, and Mike does really know and understand the user he wants us to meet. Mike gave some practical real-life examples of bad user experience and showed us how they translate into our domain. He talked about feature creep, unnecessary branding and meaningless version naming schemes. This talk left me excited about the rest of the day and thinking about various incidents where I was guilty of letting slip in some of the user experience issues Mike talked about.

In the day's second session, a better-rested and well-dressed Jeff LaMarche introduced us to OpenGL ES on the iPhone. He talked about differences between OpenGL and OpenGL ES (i.e. direct mode), differences between OpenGL ES 1.1 and 2.0, when to use OpenGL ES, the Cartesian coordinate system and its different uses (y-up vs. z-up). He gave a good overview and some pointers concerning data types and function naming schemes and general performance considerations, such as Thumb optimation for ARM6 and ARM7 CPUs. That's when the talk got a little more into the deep technical stuff, but was still very easy to follow, which I was a novice in terms of OpenGL ES really appreciated. We learned about triangles and the winding rule, viewports, orthographic code and geometry. Shortly before the end of the talk, Jeff also touched the topic of lighting and introduced its different aspects (ambient/diffuse/specular).

Right before the lunch break, we got to hear Marcus Zarra talk about his absolute favourite topic, Core Data. Marcus introduced a framework that he has written called ZSync which allows for easy synchronisation of data between Macs and iPhones. Previously, this wasn't as easy to do due to the lack of Sync Services on the iPhone. The framework is still under development and will be rolled out in 3 phases, leading up to cloud sync at one point. Like BNRPersistence, feedback and contribution by developers is welcome. I could tell from the Q&A that people were genuinely excited about this technology and are looking forward to using it in their own products.

The second-to-last presentation of the day was about developing a game using Core Animation, presented by Drew McCormack who must have been exhausted after his workshop on Sunday and his talk on the first day of the conference. Drew explained how he created the whole game using Core Animation rather than OpenGL ES and why this probably is a bad idea, but worked out for him anyway. He presented various animation inside the game and showed us, based on his source code, how they were implemented. I was really surprised to see how easily many things can be done using Core Animation and a free game programming library (for physics), such as cocos2d.

The conference's final session saw Jeff LaMarche's third appearance, and by now he could hear the beer calling for him all the way from the bar. Ignoring those calls, Jeff gave us a good overview of GameKit and quite a bit of example code and even provided some methods for working around GameKit's lack of an online play API, for which we still have to use low-level CFNetwork ourselves. He provides sample code for his implementation, but it's not a large-scale open source library like BNRPersistence or ZSync.

As an iPhone developer, especially the final 2 sessions made an impression with me, mostly because they covered APIs which I hadn't yet used. However, they got me really excited about writing a Core-Animation-based game using GameKit for local multiplayer. In combination with the upcoming iPad, I think there's an opportunity around the corner which I may have to explore.

Conclusion

NSConference 2010 in the UK was a great conference and even managed to be better than last year's conference. I felt the focus of the talks was a little different, with lots of frameworks being introduced and discussed. However, almost one week later, I still don't see any of it as advertising. I rather regret not having had the time to have used any of the great technologies introduced by these talented developers.

I took a lot of practical advise from the conference, but also various general tips and tricks about user experience and life as an engineer. Maybe that's because of all the smoke breaks with Mike Lee, but it certainly helped my thought process in so many ways.

In general, it showed once more that NSConference's focus is community. One thing I constantly heard from various random attendees is that it is so much easier to get in contact with people at NSConference compared to other conferences. And this is one thing I wouldn't want to miss for the world.

Thanks to Scotty, Tim, Dave and everyone else involved for putting together such a great conference for us to enjoy and get together.

Photos

I took some pictured during the event and a selection of those is available on Flickr: http://www.flickr.com/photos/alexrepty/sets/72157623253034969/

Cross-posted to J2ME Polish Blog

One nifty little iPhone feature that left an impression with me is the way that the keyboard in the "Messages" application slides in and out with the keyboard, as if it were attached to it - but it isn't. I needed a similar feature for an app that I'm currently working on for a client, so I decided to investigate how to implement this feature in my own stuff.

Although my first instinct was to simply use an implicit animation using UIView's +beginAnimations:context: method, I decided to quickly search the web for some information on how other developers approached this problem.

The results were a little surprising, possibly because the proper way to do it wasn't as easily available before iPhone OS 3.0 - various people on different message boards and mailing lists suggested a hack that involved looping through all instances of UIWindow to find the one containing an instance of UIKeyboard, a private class that isn't even documented in the iPhone SDK. Those hacks then proceeded to modify the dimensions of the view that contains the keyboard and adding the UIToolbar instance as a subview, so it would animate into the key window right along with the keyboard.

Needless to say, these hacks are not exactly future-proof or what I would consider a proper implementation of this feature. The Core Animation route was the one to go, so I proceeded in that direction.

More about this after the jump. Read More

…and all I got was this lousy lanyard:



Seriously though, I had a great time at the recording of the 11th edition of Apfelshow, Apfeltalk.de's monthly video podcast. I got to talk a bit about Lab Tick and being a Mac and iPhone developer in general.

Watch the full video (German language) after the jump. Read More

A couple of weeks ago, my employer, Enough Software, published a small booklet titled "Mobile Developer's Guide to the Galaxy" in co-operation with Sevenval and WIP. For the second edition, which has just been released, I've been asked to contribute a chapter on iPhone development.

So I did, and it can be found on pages 16 through 20 in the PDF, which you may grab here. Feedback is welcome, a contact email address can be found in the document (p. 52).

Enjoy!

Lately, I have been using a lot of REST APIs for various projects that I have been working on. One development pattern that I have constantly used among all these projects is that of using various NSOperation objects, feed them to an NSOperationQueue and get the results fed back to the caller via delegation.

Why Would You Do This?

Now, why would you go through the trouble of learning all these APIs, creating a delegate protocol and implementing all this stuff if you could use a simple initWithContentsOfURL: (or similar)? The main reason here is asynchronous networking. If you're going to just fetch network data, such as strings, images or whole XML documents from remote servers, you are going to see some latency, especially if you're developing for the iPhone and running on an EDGE or 3G network.

If you were to use synchronous networking from within your main thread, you would be blocking your application's UI until your method stack returns and the system can redraw your views. If you're looking at multiple seconds of latency, which might easily occur if you're fetching dynamically generated data from a server, this practically makes your application unusable. The solution to this problem is to push networking tasks into separate functions and move those to different threads.


Asynchronous networking keeps the main thread available for drawing and other tasks.

Clean Thread Management

Of course, you could just detach new thread selectors all over your controller, but that would be rather ugly, error-prone and a bitch to maintain. Fortunately, Apple introduced NSOperation and NSOperationQueue a while back (in Mac OS X 10.5 Leopard).

For your projects, you will create a subclass of NSOperation and override the -main method to do your bidding. This is where the heavy lifting should take place and all your network latency will not matter anymore. I have written a sample application that uses an NSOperation subclass to fetch an image via HTTP and return it to the controller using a delegate protocol that I have written specifically for this task. My -main method look like this:


- (void)main {
    NSImage *image = nil;
    NSError *error = nil;
    
    NS_DURING
    
    if ([self isCancelled]) {
        NS_VOIDRETURN;
    }
    
    NSData *data = [NSData dataWithContentsOfURL:_url options:NSDataReadingUncached error:&error];
    if (nil != error) {
        [(NSObject *)_delegate performSelectorOnMainThread:@selector(errorOccurred:) withObject:error waitUntilDone:NO];
        NS_VOIDRETURN;
    }

    image = [[NSImage alloc] initWithData:data];
    
    NS_HANDLER
    NS_ENDHANDLER

    sleep(2); // for illustration purposes
    
    [(NSObject *)_delegate performSelectorOnMainThread:@selector(didReceiveImage:) withObject:image waitUntilDone:NO];
}


This method does nothing more than what you would previously have done to retrieve an image given a URL (_url and _delegate are instance variables that were filled during initialization). The delegate implements the selectors defined in my protocol, errorOccurred: and didReceiveImage:.

So much for the heavy lifting. But how do you actually get this method to run in the first place? This is easy, thanks to NSOperationQueue, which provides a method to queue NSOperation subclasses for execution. In my application controller's -awakeFromNib method, I instantiate my NSOperation subclass and add it to the NSOperationQueue like this:


- (void)awakeFromNib {
    [_progressIndicator startAnimation:self];
    NSURL *url = [NSURL URLWithString:@"http://alexrepty.com/other/kiwi.jpg"];
    ImageFetchOperation *operation = [[[ImageFetchOperation alloc] initWithURL:url delegate:self] autorelease];
    [_queue addOperation:operation];
}


Add the implementation of the delegate protocol and you're done! What you end up with is a nice, clean and efficient way of dealing with networking that helps to keep your code readable, error-free and makes for a better user experience by keeping the main thread free of blocking operations.


Delegation makes sure your application controller has immediate access to the image once it has been fetched.

Yes, the cat in the picture is mine. :)

Feel free to download the source code for this example and use it in your own projects. If you have any comments or questions, use the box below or ask me on Twitter.

Update: I've published the source code for this tutorial on Github:
http://github.com/alexrepty/Asynchronous-Image-Fetcher/fast_forward

I have just released Lab Tick 0.9.4 which introduces full 64-bit-support for users running a 64-bit-capable machine and Mac OS X 10.6 Snow Leopard.

Download the new version here or use Lab Tick's built-in updating mechanism.