Android's Multicast Support is Broken

I discovered this for myself when attempting to do some home networking-related programming (UPnP/DLNA, mDNS/Bonjour all rely on multicast). Multicast sockets in Android simply don't work. You can read the full description of the issue here.

I was pretty surprised to see this, especially given that the underlying OS (Linux) definitely supports it. I guess it's understandable that the primary focus is on cellular networking at this point, but if Android devices have Wi-Fi, this is a huge omission. Given the iPhone's strong connection to the digital home, you can bet Apple isn't making it a low priority - in fact a number of applications have been built using Bonjour for the iPhone already, even before it was officially supported in the SDK.

So yeah, this is my excuse for not submitting anything to the Android Developer Challenge...

Don't You Dare Ask for My Mobile Password More Than Once!

As more apps go mobile, the potential for the abuse of those apps' users grows. One of my biggest pet peeves in this regard is mobile apps that assume it's just as easy to enter your credentials on your phone as it is on your PC. This is a huge error in judgement as the mobile user experience is already fragile and throwing up barriers risks alienating some very tenuous connections. I'm probably more patient and savvy than your average mobile user and this just kills me.

With the current de facto web standard of email/password, there's quite a bit of typing to do (even if you're on an iPhone!). This doesn't bother me that much, but I'm grateful to those apps that pre-populate the user/phone field or otherwise are considerate of the fact that I am on a mobile device. What does really burn me is apps that are frequently asking me to re-enter my password or don't save text that I've typed in the past.

An early version of the J2ME GMail Mobile app would ask for my password whenever communication with the server failed. (No this isn't an authentication failure, it's a network failure!). Another problem was that the entered password wasn't persisted until I explicitly exited the app, which I never did. This meant I had to re-enter my password whenever I powered my phone off and on. I don't think either of these were bugs as much as they were design issues that neglected to focus on the users' intentions. At this point, it seems like GMail Mobile is content to have you just enter your password once.

Last time I used it, GMail's mobile web interface had the same policy as the regular web interface - a successful login drops a cookie on your browser that expires in 2 weeks. This means that every 2 weeks I have to type in my full password on my tiny little mobile keypad. Multiply this by the number of mobile apps you use and you have a recipe for a very frustrated user.

On the other side of this, because mobile phones are arguable more personal and less secure than PCs, maybe app designers should be forcing more frequent authentication. How many times have you or a friend lost a phone on the bus, had it drop out of a pocket, or otherwise enabled the possibility that it falls into the hands of someone who decides to use it to access your personal information?

Maybe the best solution here is just to add a password lock to your phone and make sure it works out of the box. Sooner or later, people will get the message that your mobile phone is the best vehicle yet for identity theft and will put up with typing in a 4-digit unlock code. (Better yet, the next version of the iPhone should add a fingerprint scanner for use with the existing slide-to-unlock feature.)

In the meantime, please be considerate of your mobile users and design with these issues in mind!

The iPhone SDK is BREW Part Deux

There should be little doubt in anyone's mind that the iPhone Store is a walled garden, albeit a very shiny and new walled garden. The SDK has been out for a while now, and people have figured out that there a lot of things you just can't do with it. The most obvious limitation is that Apple forbids applications that run in the background.

While there are obvious reasons for prohibiting these applications (security, battery life, performance, user experience), none of these reasons are very good. Fring actually resorted to releasing an app for Jailbroken iPhones, but you can bet this won't be available through the iPhone Store anytime soon. My own opinion is that Apple is not only protecting the iPhone's user experience, but also plans to add a lot of these interesting features in the future (VoIP, MMS, IM, etc.), and doesn't want third-parties to get in the way (unless Apple has a deal with them).

I stand by my first-blush statement that the iPhone SDK is more polished and professional than the Android SDK. If you're looking to build a game or a way to access your interactive web app, you'll be very happy. However, if you want to build an innovative new category of application that relies on background processing, you're out of luck - you should go with Android, Windows Mobile, Symbian, or maybe (gasp!) even BREW.

Background applications are easy to build in BREW, which might make you think that BREW is more open than the iPhone. As long as you get the permission of Qualcomm and the carrier you want to deploy on, these applications are allowed. On the other hand, the BREW APIs are clunky and feel like they were designed by hardware engineers, while Apple's APIs are well reasoned, aside from being tied to Objective-C. (I don't have anything against hardware engineers, I just don't think they should be writing software.)

The irony here is that of the current distribution models, the iPhone Store most closely resembles the BREW model, though BREW is much more closed. BREW has more, higher fees (registration, testing, etc.), while Apple has just a $99 or $299 developer fee. Apple gives the developer 70% of the retail price, while with BREW the revenue share is a complicated dance. Overall, the iPhone store should be a boon for developers compared to previous distribution models. While it's not as open as pure web-based deployment it does have the benefit of handling billing and putting your application in a common catalog where it should be easy to find.

Will New E-Ink Controller Lead to Less Sucky Kindles?

E-Ink is a unique display technology that relies on reflectivity rather than backlighting like LCDs. While the technology has been in development for more than a decade, its adoption has been slow due to production issues and its Achilles' heel: slow refresh rate (500-1000 milliseconds).

Refresh rate and flashing has hindered E-Ink's use in highly interactive applications to date. In my opinion, Amazon's Kindle is unusable due to the interface kludges perpetrated on the design in an attempt to work around these issues (though there are a lot of unrelated design flaws as well).

A new version of the E-Ink display controller is claimed to have refresh rates similar to those of an LCD (15 milliseconds or 66 frames per second). If these claims hold true we should see new versions of the Kindle and other reading devices with vastly improved usability. Add color and E-Ink might be able to compete with LCDs someday.

The New Mobile Fragmentation

The past few days have seen some pretty big announcements in the mobile platform space.

Nokia is putting Microsoft's Silverlight on S60 and S40 phones.

Google announced its first mobile port of Gears - to Windows Mobile.

Steve Jobs rejected Adobe Flash as being too slow for the iPhone.

Today Apple released the iPhone SDK. (My first impression is that it has a much higher degree of quality and completeness than the Android SDK, but I'll withhold a full judgment to another day.)

Then of course there's Yahoo Go 3.0, Google Android, and some other lesser comers as well. What all this points to is even greater fragmentation than the mobile space has seen in the past. Of course there will be a shakeout eventually, but over the next few years there will be a lot of options for mobile developers. Choosing which platform to develop for will be even tougher than in the past since these new platforms offer a broader variety of approaches - web-based + offline, declarative + script-based, Java-based. On the upside, this should make it much easier to get apps deployed onto some phone. On the downside, with all of these options, J2ME fragmentation is nothing compared to what's coming.

Modu Unveiled

After an interesting teaser video a few weeks ago, Modu Mobile has unveiled itself. The basic idea here is that a Modu device forms the core of a mobile phone and can thus be swapped into new devices as the user desires. This is somewhat reminiscent of the Wildseed SmartSkins platform except that it slims down the core to a tiny credit-card sized device that can fit inside many different form factors.

I think Modu has a chance at gaining some acceptance by phone OEMs/ODMs as a way to reduce development times and certifications costs. It also neatly solves the phone upgrade data-migration problem which so many people have now. Of course, there's probably a limit to how many times you can upgrade the carrying device before the Modu core becomes functionally outdated.

The teaser video intimated that you would be able to slide Modu into other devices like cameras, cars, and media players, thus personalizing that device with your data and wireless connections. I think this is a neat idea, but an impractical one. The first problem is usability as it implies that a user will be swapping the Modu core in and out among a number of devices. This seems awkward and neglects those scenarios in which two devices are active at once. The second problem is getting device manufacturers to commit to building this hardware interface into their products. Unless you're a brand like Apple (and are able to convince these OEMs to ignore the fact that you're competing with them), this is a tough sell.

There are two core ideas at work in Modu, both focused on personalizing devices that you use. Data personalization makes your personal data available on any device. Companies such as Realm Systems have built personal server devices with this core idea in mind. Network personalization is at the core of the personal router - a great idea whose time has yet to arrive, though if you've ever tethered your laptop to your mobile phone using Bluetooth you've got the basic idea.

I believe personalization is incredibly important for the coming age of consumer computing which is moving away from the PC and towards the mobile device. People will use a full-featured mobile device for most of their daily communication and information retrieval operations. Other devices will become task- or location-specific adjuncts throughout the course of the day. If you need to compose a document, sit at a workstation "PC". If you want to enjoy viewing friends' movies and photos, lounge in front of the home theater system. When you're in the car, your content should be available at your fingertips without thinking too much about it.

A lot of this personalization is already being delivered today through the web, but as the range of devices and interactions becomes broader today's web looks less viable in this world (How do you present an HTML page on a device that has no display?)

I have some strong opinions about how such a (software-based) personalization system will operate. If you're an investor or entrepreneur that thinks this space is as compelling as I do, ping me and let's chat.

Why would Nokia buy Trolltech?

After reading this morning's news of Nokia's pending acquisition of Trolltech, I could only wonder, Why?. Apparently a number of other people also had similar thoughts. Certainly Nokia has recently been buying a lot of companies with tenuous connections to their core mobile business, but presumably this is part of their expansion into services via their Ovi initiative.

Here are the facts as I see them:

• Trolltech's Qt is a cross-platform UI toolkit that started off on the desktop and has more recently appeared in mobile devices as Qtopia. It is available in an open-source or commercial license.
  
• Qt doesn't appear to have much traction in commercial devices, so it can't be considered a threat to Nokia in any real way.
  
• Qt/Qtopia doesn't have a great user experience. The only device I see that has a nice shiny UI is the Sony Mylo and maybe some newer Motorola devices. Neither of these appear to use the default look and feel. The Qtopia framework in particular was really old-school and a non-starter for building a shiny device.
• Nokia's S60 platform has really only been deployed in smartphones and S40 isn't really programmable in the same way. Neither of these is very developer-friendly despite Nokia having made a large (and confusing) array of development tools available.
• Nokia already has its hands in open-source with Maemo/Hildon, WebKit, Open C, Posix for S60.
  

Clearly Nokia isn't doing this to "take out" Trolltech as they are no threat at all. Also, it isn't an attempt by Nokia to "buy in" to open source as they already are knee deep in the stuff. Given the prevalence of Flash on the web and expansion of Nokia into services, they do need a cross-platform runtime to compete with the likes of Flash, which the press release pretty much says.

Nokia's software strategy for devices is based on cross-platform development environments, layers of software that run across operating systems, enabling the development of applications across the Nokia device range. Examples of current cross-platform layers are Web runtime, Flash, Java and Open C.

If you look at these four platforms, the only ones that are viable on the web are Flash and Ajax (web runtime). Qt gives Nokia a way to get into the Flash/FlashLite/AIR (web/mobile/desktop) space. As is, I don't think Qt is a sensible platform for this - it's crusty and ugly (sort of like S60), but it DOES run on many platforms, so it's a good basis for a cross-platform RIA runtime. With this in mind, hopefully we'll see something along the lines of the Flash or Ajax model with declarative UI and scripting built on top of Qt.

Of course, I don't think write once, run anywhere really makes sense across web, mobile, and desktop apps for usability reasons, but having a single codebase on which a developer can make some quick UI tweaks to make it viable on any of these sure makes sense.