There may be times you’ve downloaded a cool application with a new kind of user interface component, and you’ve wondered: how was it built? One great example of this is the rotary wheel, used by ConvertBot and other applications as a way for users to select options from a menu. This component is intuitive to use because it resembles many similar controls we use in real life to make choices. For example:

• A ship’s wheel allows the captain to choose the direction of travel.
• To set the volume of your stereo, you use a rotary knob.
• You might also remember that we used to call people using rotary dial telephones.

Such shared knowledge allows us to recognize the “possible uses” of a rotary wheel, even when it’s a virtual wheel.
Note: A perceived use of an object is also called an affordance, a concept used in such fields as psychology, design, and artificial intelligence.
In brief, a rotary wheel is meant to be spun. Just as with hardware wheels, touchscreen wheels can be configured in many ways. For example, we might include stop points (as in the rotary dial on a phone), ignore initial taps in a given zone, allow just one direction of rotation, etc.
As you may have deduced, this tutorial will show you how to build an intuitive rotating wheel interface. You’ll then be able to integrate this component into your iOS apps and let other people wonder how you built it ;]

Read the rest on raywenderlich.com

This article from Business Insider got me started. Since I have to time to address potential fanboy arguments let’s go this way. For each time you think I am a fanboy I’ll think of you one of the following:

- troll
- user who has time to loose with lower quality devices/experiences
- user who likes to accumulate stress

Right now that Eric Schmit is promising that Android will soon beat iOS (whatever is the meaning of beating in this context), Android’s throat is getting more and more exposed. I can’t provide evidence but I started to feel a while ago that Android has found his way: more and more devices released and much buzz around the topic. But I always got in mind a few key aspects:

1. Fragmentation: it is not easy at all to build an homogeneous experience across many different devices
2. Too much fanfare about the number of devices activated per millisecond
3. Nobody has ever revealed how many dollars has Google shared with developers

While the second is mainly related to marketing and the too much diffused tendency to reveal meaningless numbers, as a UX designer, developer and entrepreneur I am pretty sensitive to points #1 and #3. The first is pretty a technical reason: developers have to write more code and carry more stress with respect to iOS. The third point is pretty a mystery to me: Apple is known to be pretty secretive, especially when prototyping, but is proud to reveal key numbers to attract more on their platform. Rhetoric questions for developers/entrepreneurs: which market would you dive in? the one where you know the current volume or the one you don’t know anything about? While reflecting on this please don’t fall into the childish thought that “more devices more potential buyers”, unless you are a rookie. Just consider that you are making money by selling applications, and a higher number of devices does not imply a higher number of sales. The key value is the “willingness to buy”, and the internet is full of articles supporting the idea that iOS users are more prone to buy applications than androiders.

Getting back to the main point of this article the new announcement from Samsung, that won’t allow upgrades to the new version of the OS on old devices, is really exposing Android’s throat to attacks. While it was relatively easy to copy (umm … take inspiration from) iOS and its ecosystem, now I think that Android has reached a pretty unsolvable issue: the one of upgrades. People who bought an iPhone 3gs (released in June 2009) can still happily use it today with iOS5 and the iCloud. Can you find a similar example in the Android world? I doubt so. The reason is exquisitely technical: relatively young devices have not enough hardware power to run new versions of Android OS. It is just a physical limit, and I think there is nothing to discuss. My opinion is that it is due to lack of vision. One of the few upgradeable devices is the Galaxy S2, because it is a flagship product, and preventing an update on that would mean users migrating to other devices in a hurry.
I am not a fan of Microsoft but if you bought the first model of Windows Phone you can still happily run the latest version of the OS on that. This means being on track.

Besides technical reasons I think that there is an issue related to the approach. While it was possible to “decouple” hardware and software on the desktop (and Microsoft has built his empire on that) this is much less doable in the mobile world, where hardware power is limited.

Here are a few suggestions for Google, makers and users.

Makers

HTC, Samsung and colleagues should follow Amazon approach. The only way to attack a well established market are a few. You can work on:

• the best product
• the best solution
• the best price

Amazon, to attack the tablet market, is betting on the best price. I don’t see a simpler way for competitors to undermine Apple’s iOS ecosystem. Building the best product or solution would take a lot of time.

Google

Google should close the gates, reorganize all the code to be more tightly coupled with hardware. They should put a lot of effort in rendering, demanding that (when possible) to the hardware. They should also devise crystalline rules about installation and updates. In 2012 I should not connect my phone to a computer to update the OS and I should not be forced to buy a new device to have the latest version of the OS. The recent acquisition of Motorola
is going toward that direction. If I were HTC or Samsung I’d be a bit worried, for I suspect new versions of Android will be super optimized for Motorola hardware. That’s the only solution I see for Android to resurrect.

Users

In the current situation, my suggestion is to go cheap. If you buy a $500 Android phone which is not OS-upgradeable it is not easy for you to afford a new purchase. If you have bought a $200 one, you have saved $300 (with respect to an iOS device) and you can think of using that money to buy a new model in one year.
Of course it is not easy to spot which models are upgradeable before you buy them (see crystalline rules above).
In general, we are told that a Google-approved Nexus device, should be eligible for upgrades (my addition: provided that hardware is powerful enough). So if you really like to buy an Android phone/tablet I strongly suggest to stick with those models or buy the new ones which will be released by Motorola in 2012.

Conclusion

While Google and friends are just chasing the highest number of activations per day, exposing his throat to competitors’ weapons, Microsoft and Apple are pointing on good experience, simplifying data migration and assuring compatibility with old models.

I’d like to conclude with a set of questions:

• where is all the “freedom” that Android supporters claim?
• do you realize that openness and (supposed) freedom, in the long run, are more costly than “closed-source” competitor solutions?
• do you see all the ifs you are going to face buying an android powered device?
• do you know that all this is due to a business model

?

• Not convinced yet? Have a look at this graph.

He moves like Steve Jobs and his attitude is inspiring as well.

This is an excerpt from my chapter on iCloud included in iOS5 by tutorials.

We all have “stuff” we use on our iPhones and iPads regularly like documents, pictures, videos, emails, calendars, music, and address books. But how many times have you tried to quickly open a document and realized “argh, I have it saved onto another device”?
Well, with the new iCloud feature in iOS 5, that is problem of the past!
iCloud is a service that helps you synchronize your data across devices. It is a set of central servers which store your documents, and make the latest version available to every device/app compatible with iCloud (iPhone, iPod, iPad, Mac, or even PC).
In this tutorial, we’ll investigate iCloud by implementing a set of simple applications which interact with cloud servers to read, write and edit documents. In the process, you’ll learn about the new UIDocument class, querying iCloud for files, autosaving, and much more!
Note to get the most out of this tutorial, you will need two physical iOS devices running iOS 5 for testing, such as an iPhone and an iPad. The simulator does not currently have iCloud support.

Under the Hood

Before we begin, let’s talk about how iCloud works. In iOS each application has its data stored in a local directory, and each app can only access data in its own directory. This prevents apps from reading or modifying data from other apps (although there are some alternate methods of transferring data between apps built into the OS). iCloud allows you to upload your local data to central servers on the net, and receive updates from other devices. The replication of content across different devices is achieved by means of a continuous background process (daemon) which detects changes to a resource (document) and uploads them to the central storage.
This works real-time and enables another interesting feature: notifications. For example, whenever there is a conflict about a document, the application can be aware of that and you can implement a resolution policy.
If you ever tried to create something like this with your own apps, you know there are several major challenges implementing this:

• Conflict resolution. What happens if you modify a document on your iPhone, and modify the same document on your iPad at the same time? You somehow have to reconcile these changes. iCloud allows you to break your documents into chunks to prevent many merge conflicts from being a problem (because if you change chunk A on device 1, and chunk B on device 2, since chunk A and B are different you can just combine them). For cases when it truly is a problem, it allows you as a developer fine-grained control over how to handle the problem (and you can always ask the user what they would like to do).
• Background management. iOS apps only have limited access to running tasks in the background, but keeping your documents up-to-date is something you want to always be doing. The good news is since iCloud synchronization is running in a background daemon, it’s always active!
• Network bandwidth costs. Continuously pushing documents between devices can take a lot of network bandwidth. As mentioned above, iCloud helps reduce the costs by breaking each document into chunks. When you first create a document, every chunk is copied to the cloud. When subsequent changes are detected only the chunks affected are uploaded to the cloud, to minimize the usage of bandwidth and processing. A further optimization is based on a peer-to-peer solution. That happens when two devices are connected to the same iCloud account and the same wireless network. In this case data take a shortcut and move directly between devices.

The mechanisms described so far are enabled by a smart management of metadata like file name, size, modification date, version etc. This metadata is pushed to the cloud, and iCloud uses this information to determine what needs to be pulled down to each device.
Note that devices pull data from the cloud when “appropriate”. The meaning of this depends on the OS and platform. For example an iPhone has much less power and “battery dependency” than an iMac plugged into a wall. In this case iOS might decide to notify just the presence of a new file, without downloading it, whereas Mac OS X might start the download immediately after the notification.
The important aspect is that an app is always aware of the existence of a new file, or changes to an already existing file, and through an API the developer is free to implement the synchronization policy. In essence the API allows an app to know the “situation” on iCloud even if the files are not yet local, leaving the developer free to choose whether (and when) to download an updated version.

Read the rest on raywenderlich.com

I’ll remember you like this, spreading creative fire.

I recently published a tutorial series titled “Building a Jabber client for iOS”.
Here is the complete list/

Part 1: Server setup
Part 2: Interface setup
Part 3: XMPP integration

The source code is available here on github

New is cool. I like to try new things, even alpha or beta stuff. I like to see changes, improvements, new directions. I like the way Apple continuously pushes improvements: one new iDevice almost each year, new software solutions, new ways to save data. But I can’t let the things I like to influence my business in a bad way.
If you are like me you probably have a machine (in my case a MacBook Pro) which is your faithful daily companion. There is everything you need, the tools you use daily. An operative systems is not a toy application you can live without. It’s part of that faithful companion, something you count on. OSX Lion is something I cannot count on yet. I installed it on a spare Mac mini, which I use for experiments. I like the new interface, the way it is inspired to iOS, the way it is easier to use. But there are tools I work with daily, which are still not fully compatible with Lion. The first release of new tool is not perfect, even if it has been extensively tested during the alpha and beta stages. This happens to each product, even if it is built by great developers. Check out the Mac or App store to see how many 1.0.1 or 2.1 versions you can spot. Those minor version changes reflect updates which are needed to improve and fine-tune applications. Not even Apple is immune to that. I bet there will be a Lion 10.7.1 soon. The same applies to other Apple products like XCode. That’s another tool I use daily. There has been a 4.0, then a 4.0.1, a 4.0.2 and now a 4.1. If you search the Twitterverse it’s easy to spot people lamenting crashes of Lion or XCode. I can even venture a bet that 50% of Apple developers is still using XCode 3.
Not to mention 3rd party apps. Part of my daily job is based on the Adobe Creative Suite, which sometimes is buggy per se, regardless of the OS. I don’t want even imagine how it behaves on Lion, considering that Adobe is lazy (BTW compatibility issues are listed here) Also historically known applications like Coda are unstable and crashy, in spite the fact it has been upgraded to be Lion compatible. See here and here for example. I remember I had the same approach to Snow Leopard, which I installed at least two months after the first release.

I can understand people which install Lion to test it or review it. But really, what’s the sense of installing it and polluting the Twitterverse like screaming kids? Software development is craftsmanship, it takes time. Or is Apple so trustful that people blindly upgrade without doing any check?
Personally I can support an application crash a week, and a kernel panic error a month. Something more frequent would kill my productivity and raise my stress. My suggestion is to wait at least the next minor release. Moreover:

• monitor relevant twitterers and bloggers to have a glimpse of the current situation
• talk to people you trust, ask them how is the current release,
• monitor Apple’s forums,
• check the website/forums of each application you use for your business

And even after that be a bit doubtful. We are talking business. Or would you prefer to tell your client that the last release got screwed due to a Lion crash an app crashing on Lion? :)
That said, when do you plan to install Lion? Did you already install it? How many issues did you have?

Update.
If you like to check whether an app is compatible with Lion you can consult roaringapps

This is an excerpt of a tutorial I wrote for raywenderlich.com.

Many iOS apps use HTTP to communicate to a web server, because it’s easy, convenient, and well-supported.
However, in some cases you might find the need to go a bit lower level than HTTP, and communicate using TCP sockets to your own custom server.
The advantages of doing this are several:

• You can send just the exact data you need to send – making your protocol lean and efficient.
• You can send connected clients data whenever you want, rather than requiring the clients to poll.
• You can write socket servers without a dependency of a web server, and can write in the language of your choice.
• Sometimes you just have to use sockets, if you are connecting to a legacy server!

In this tutorial, you’ll get some hands-on experience writing an iPhone app that communicates to a TCP socket server using NSStream/CFStream. Also, you’ll write a simple socket server for it to connect to, using Python!
The iPhone app and chat server will implement chat functionality, so you can chat between multiple devices in real-time!

This tutorial assumes you have a basic familiarity with Python and iOS programming. If you are new to Python programming, check out the official Python tutorial. If you are new to iOS programming, check out some of the iOS tutorials on this site first.
Without further ado, let’s do some socket programming!

Read the tutorial on raywenderlich.com

Things change. Newspapers have been the gates of daily knowledge. Now we have blogs, twitter and so on. Either newspaper will learn how to find their place in this new context or they will die, probably slowly. We are in need of great content. Once only journalist were allowed to write it. Now everybody can. That means there will be more crap around, but also many more voices and much more coverage about niches that once were never considered.
In any case blocking the content of a website when you open it on the iPad is just a signal that that newspaper are getting more and more desperate.

Here is an interesting piece by Dave Winer

Scenario: I am involved in the launch of a new product. My feelings? Thrill and excitement. Many questions are rolling in my head. They can all sum up to how will it go?. I really don’t know. I am more than convinced that a product has to lead people to think “it just works”. I am more than convinced that an entrepreneur is a trust builder. You don’t just build a product, you build trustful relationships by means of a product. If people don’t trust you or your company they don’t use your products. If you don’t listen they don’t use your products.
This attitude, coupled with excitement, is getting along with me these days. I don’t feel I am ready. I think I will never feel ready. There will always be something that I feel it’s unfinished. But you have to cut to the chase, otherwise you’ll never release. Moreover, you risk to work on stuff that is not needed by your audience.

My only commitment: I will listen. I am ready to receive mails and tweets that help to co-build the product.
All this stuff is rumbling in my head as we are approaching the beta release of pomo.me, the easiest web application to manage your time with the pomodoro technique.