It’s been quite a while since my last post. The reason (as you might have guessed) is that we’ve been very busy with Ice Touch, which we released last week. If you haven’t seen it yet, I suggest that you head over and take a look.

Ice Touch really is quite a cool way to get network-enabled applications onto the iPhone and iPod touch. For example, we’ve ported our chat application to the iPhone, and you can use the chat server we host (or a server of your own) to run the Ice protocol straight from the phone to the server. We have also included an application that shows how to access a database from the iPhone.

Of course, strictly speaking, you don’t need Ice to do this. However, if you want to network your application using the facilities in the iPhone SDK, you are back to the way we did things twenty years ago, namely, raw sockets. And, as we all know, that’s a rather tedious way to do networking, and doubly so for a mobile device, with its often unreliable wireless network connections. Ice handles these things for you in its usual elegant way: failed operation invocations are retried automatically (provided they will not violate at-most-once semantics), and location transparency means that you do not have to hard-wire addresses and ports.

In fact, Ice Touch gives you a full-blown development environment with almost all of the features of Ice for Windows or Linux. To keep code size small, we made a few minor concessions in Ice Touch, but the important things are all there. In particular, the run time is fully thread safe, you can use TCP, UDP, and SSL, you can use synchronous and asynchronous invocations, and the iPhone can even act as a server.

Normally, you would not expect to run an Ice server on an iPhone. However, the server-side support is important for callbacks: you can implement an Ice servant in the iPhone and have it respond to invocations from a client elsewhere. In other words, with Ice, you can create push applications that allow a server in your corporate network to push information to the iPhone instead of having to poll the server from the phone.

Ice Touch provides the same router support as Ice for other platforms, which means that you can do all this even if the server you need to access from the iPhone is behind a firewall (thanks to Glacier2) and, because Ice Touch supports bidirectional connections, the firewall does not interfere with push applications.

The development language for iPhone applications is Objective-C so, naturally, Ice Touch includes an Objective-C mapping. The mapping is simple and elegant and nicely integrates with the Cocoa framework. For example, a Slice dictionary is mapped to a Cocoa NSDictionary, so you are already familiar with how to use it. After maybe half an hour of browsing the manual, you’ll be up and running, especially if you have experience with Ice for other programming languages.

Overall, Ice Touch is a great development platform for the iPhone and iPod touch. Ice Touch makes it easy to create networked applications that seamlessly integrate with your corporate computing environment. Or, if you are into the lighter side of computing, with Ice Touch you can create multi-user games without having to sink a large part of your budget into the development of custom protocol stacks and sockets code. And, in contrast to other mobile platforms, it is easy to distribute your application via the App Store.

We see a great future for Ice Touch. For one, the trend toward wireless mobile computing shows no sign of abating; the continuously improving wifi coverage and affordable unlimited data plans in many countries will accelerate this trend. Second, the iPhone’s computing power and memory capacity are at the point where it is possible to create fully-featured mobile applications with slick user interfaces that are fun to use, instead of having to live with applications that are crippled by the limitations of a less powerful device. Finally, future versions of the iPhone (and other mobile devices) will be more powerful still. It will be interesting to see the impact of Android, for example. I expect that, over the next few years, we will see a new renaissance in computing, driven by increasingly more powerful devices and applications that are truly distributed, with the user interface chores handled by the mobile device, and heavy-duty database and computing needs being met by remote data centers.

Ice Touch is the first and only middleware for the iPhone. It removes a major obstacle from the development of truly networked and interactive mobile applications. So, I suggest that you give Ice Touch a try, get your toes wet, and catch the wave. Or, as they say, the early bird catches the worm!

Cheers,

Michi.

Update: I just checked the new iPhone OS 3.0 and, sadly, none of the problems have been addressed, despite having submitted defect reports to Apple. Very disappointing, indeed…

I am one of the people who were lucky enough to get an Apple iPhone 3G on its release day. Prior to the iPhone, I used a Sony-Ericsson S700i, which I was never happy with: it had a clunky user interface, tortured data entry via the keypad, and essentially useless contact and calendar functions.

I depend a lot on a reliable calendar that allows me to track my appointments and reminds me when I have to be somewhere. Back in 1997, I bought a PalmPilot Professional, which had nice contact management, calendar, and expense tracking functions, all of which I use regularly. I have carried various Palm organizers ever since.

And here is the snag: I have also carried a mobile phone ever since, and it has often annoyed me that I have to carry two gizmos, both of which need their batteries charged, need to be synchronized, require software updates, and so on.

The iPhone 3G is the perfect stone for killing two birds: it has a nice user interface and is much easier to use than either the Sony-Ericsson or the Palm, and the iPhone comes with calendar and contact management functions. Being able to replace two devices with a single one was enough for me to queue up and buy the iPhone.

Getting the iPhone to work and copying all my existing data onto it was a breeze. It really is as simple as plugging it in, setting a few preferences in iTunes and, bingo, after the first sync, all my calendar data appeared on the iPhone. Awesome!

Now, it is almost two weeks later, and the shine has worn off. The iPhone is great, and most things work well and are well designed. (We can quibble here and there about things such as the inability to use voice-dialling or not being able to record video, but those things are not all that important to me.) However, the one thing I need most from my iPhone, namely its calendar, turns out to be the worst-designed application on the entire phone.

After syncing the iPhone for the first time, I looked at the calendar. A few things immediately jumped out:

• The month view shows the week starting on Sunday and ending on Saturday. This is not the way things are done in Australia, where the week starts on Monday.
• There is no way to search my calendar so, if I want to find out when my next dentist appointment will be, I have to scroll through all entries to find it.
• There is no way to enter monthly repeating appointments for a particular week. For example, it is impossible to say “the second Tuesday of every month”.

In contrast, Apple’s iCal application for OS X allows me to easily do all of these things.

Because I tend to get absorbed in whatever I’m doing (especially when I’m programming), it’s easy for me to miss an appointment, which is why I like to set an alert for most appointments. However, when I entered an event, I found that I have to set the alert manually. There is no way to set a default alert period. Again, iCal can do this—for example, I can ask it to add a default alarm 30 minutes before each event. There is no reason the calendar on the iPhone could not do the same.

That night, I went to bed early and was reading a book, when my iPhone suddenly went “bling bling”. What the…? When I looked I found that it was reminding me of an all-day event for the following day. At 11:30 at night, when I’m possibly asleep already? The culprit is not the iPhone, but iCal: iCal applies the default alert period to all events I enter, including all-day events that do not have a start time. Which means that, unless I explicitly disable the default alarm for each all-day event, I get the alert the night before, at 11:30pm.

The next day, I was out and about and happened to glance at my iPhone, only to realize that I was fifteen minutes late for an appointment, even though the appointment was in my calendar and had a 30-minute alert. And the iPhone did indeed sound that alert. However, what I got was one measly ”bling bling” that lasted for all of a second. I missed the alert because I was in a noisy environment.

My first thought was “I can install a different alert sound that lasts longer” but, digging through the calendar preferences, I quickly found out that I can’t. The alert sound is not customizable (even though ringtones are), so I’m stuck with that short “bling bling”.

I also looked for a way to set repeating alarms. For example, on my Palm, I can say ”alert me every five minutes for up to 40 minutes” and my Palm will ring an alarm that lasts several seconds every five minutes. No such feature on the iPhone’s calendar: all i can do is set a second alert, so I can have an alert, say, fifteen minutes before an event, and another one five minutes before. But that is all I can do, I have to enter the alerts manually for every event, and both alerts are that single useless “bling bling” that I can hear only if I’m in a quiet environment.

After these disappointments, I experimented some more and found other unpleasant things:

• If I use my iPhone to listen to music at low volume level, calendar alerts are played at that same low volume level.
• If I use my iPhone with headphones and put it down for a while, calendar alerts play through the headphones where I can’t hear them.

Now, how is that for brilliance? There is no option to always play alerts through the speaker, whether the headphones are plugged in or not! If I don’t want to miss any appointments, I have to religiously unplug the headphones and turn the volume back up all the way every time I put down the phone. But even doing that doesn’t help much because that single “bling bling” is easily missed, for example, if I leave the room for a few minutes.

It is obvious that the designers at Apple have never used their own phone, at least not to remind them of appointments. Presumably, either a lot of people at Apple are missing their appointments, or they do what smart people do and carry a Palm instead…

A little googling reveals that these problems have been present since the original iPhone, and that many people have complained about them. Yet, Apple chose to do nothing about these very real problems for more than a year.

Not one to give up easily, I decided “well, what Apple won’t do, I can do easily enough.” Writing a calendar application isn’t all that hard, so I decided to write my own. I downloaded the iPhone SDK and started reading the documentation. It took about two minutes for me to find the following in Apple’s Audio and Video Coding How-To:

How do I control playback level?

On iPhone, the user controls playback level using the hardware volume control.

How do I access the hardware volume controller?

Global system volume, including your application’s volume, is handled by iPhone OS and is not accessible by applications.

How do I control where sounds play (built-in speaker, dock connector, headphones)?

iPhone OS sends audio to the appropriate device, depending on user preferences.

Well, so much for my ambitions to write my own calendar with decent alerts. It’s not possible to do what I want to do (unless I’m Apple). (I know that this is not a hardware limitation because when the phone rings or an SMS arrives, the sound indeed plays over the speakers at a preset volume level, even when I leave the headphones plugged in.)

How is it possible for a company that prides itself on ergonomics and ease of use to fall this far short of the mark? This is design at its worst: it adds alerts, supposedly to help people keep their appointments, but does not bother to check whether the feature actually serves its intended purpose. To top it off, customer complaints about this very real problem are ignored.

Sadly, I shall continue to carry my Palm, and I shall continue to live in the hope that, one day, someone will make a single device that can make both phone calls and remind my of my appointments. (I’m not holding my breath though.)

Now, what does all of this have to with Ice? Well, on the surface, nothing. I wrote this entry mainly because I passionately care about good design and usability, and because I believe that a company that does not listen to its customers is losing the plot, and losing it fast. (And venting my spleen made me feel better…)

But, come to think of it, this story has actually quite a lot to do with Ice: ZeroC does listen to its developers and the suggestions they make. In fact, many features of Ice exist only because our developers pointed out that what we did wasn’t good enough. On top of that, we eat our own dog food: we use our own software and, believe me, when one of us finds something that is awkward to use or does not work as it should, we are not shy in pointing out to each other that it sucks and needs fixing.

There are two overriding rules when it comes to design:

Though shalt use what you design yourself.

The proof of the pudding can only be found where the rubber meets the road, that is, in actual use—not with a test bench setup.

Though shalt listen to your customers’ complaints.

Just because I think that my design is fine, that does not mean that other people think so too—chances are that they will use my design in ways I have never thought of.

Here at ZeroC, we keep both rules firmly in our minds.

Cheers,

Michi.