Tag Archives: iphone

Google seeks to automate the home

Google made a bunch of announcements at its Google I/O keynote today. It showed off the next version of Android, called “Ice Cream Sandwich”; it announced its Music Beta, a service which looks a lot like Amazon’s Cloud Player, in which you upload your music collection to the cloud; it announced movie rentals.

The most intriguing announcements though were about how Android devices will be able to connect to other devices in future. The Open Accessory API lets manufacturers create devices which talk to Android over USB, and in future over Bluetooth, in a standard manner. The idea is that if you have an Android-compatible device – Google demoed an exercise bike – you can attach your smartphone and do some clever stuff, such as controlling it, analysing its data, or whatever is appropriate.

A related idea is called Android@Home. Google has developed a new lightweight wireless protocol which will let manufacturers create household devices that can communicate with Android:

We previewed an initiative called Android@Home, which allows Android apps to discover, connect and communicate with appliances and devices in your home.


The automated home is a grand concept where almost any device, from a light to a coffee maker to a fridge or a door becomes available to control and program. However, the examples Google gave were not exciting: playing a CD by waving it at a player, coding an alarm clock to turn the light on gradually. Big deal.

It is not really a new concept. Sun had ideas to develop Java as a universal runtime and language to automate the home. Microsoft has similar thoughts, maybe using the .NET Micro Framework. So far none of these efforts have come to much – will Google’s initiative be different?

Probably not; but there is something else going on here. I travel a bit, and it is now common to find an iPod dock in your hotel room. If you have an Ipod or iPhone you just plug in and go; if you have a non-Apple device, you are out of luck. That is a kind of pressure exerted on every guest, a hint that they might be better off with an Apple device.

Google wants to do the same for a variety of other devices, but with respect to Android. Here is a refrigerator, and by the way, if you have an Android device you can do this other clever stuff like, I don’t know, alerting you if the temperature goes too high, or letting you peek at the contents from your smartphone so you can see if you need to buy milk.

Same with the Open Accessory API. If Google can sign up enough manufacturers, it will be increasingly difficult for non-Android devices to compete.

That said, we did not hear much about Google TV at today’s keynote. Why? Because it has flopped; a reminder that not all Google’s efforts succeed.

Succeeding in an App Store world: lessons from the Angry Birds story

At Mobile World Congress earlier this year I heard Rovio CEO Mikael Hed address a small group of Apple platform developers on the subject of the changing world of app development. His starting point is that mobile apps and the app store model are transforming the business of software. Of course he has a games industry perspective, but my hunch is that what he says applies more widely. I note that the App Store concept has already come to the Mac, and that Microsoft will follow Apple with something similar in Windows vNext.

What is the effect of an App Store? It combines opportunity and challenge for developers. Opportunity because apps can be found, purchased and installed in a few clicks. Challenge because app stores attract lots of apps, and the barriers to entry are low, much lower than traditional retail channels. This forces prices down and makes it hard to have your particular app stand out.

The App Store model seems to include the idea of single-purpose apps at low prices. Apple still sells iWork, its office suite, for £72.00 as boxed product (UK prices), but on the Mac App Store it is split into three products, Pages, Keynote and Numbers, at £11.99 each. Even if you buy all three it is half the price of the box.

Mac desktop apps are larger and more sophisticated than iPhone apps, so I guess they will always attract higher prices; but I also guess that the factors which have driven down prices on the iPhone App Store will exert the same influence on the desktop store.

So where are prices going? Here is what Hed told us:

On the pricing side, we know now that on the App Store the standard price is fast becoming free, zero. And the premium price is 99 cents. If you go higher than that, then there are higher risks, because you might never reach the top ten, or top 100, and if you do, it will drop off very fast, there’s huge price sensitivity. So this also is a big change for traditional publishers who are used to high prices up front, and that’s the classic business model in gaming. That is changing, so game developers must find additional revenue streams.

This low pricing is the foundation of his thesis. Hed’s view is that software companies, in the games industry at least, have to be ready for it. Further, he thinks that the shift toward mobile is profound and will not reverse:

We are seeing right now a big shift from retail focused, location based games where you have to have your console plugged into your TV. That is slowly slipping away and in its place is coming the digitally downloaded game that you can play anywhere.

How then do you survive and prosper in this new world? Hed’s answer is to build a brand, and find diverse ways to monetize it.

He told us the history of Angry Birds. This, he says, is the first mock screenshot which his game designer made in 2009:


The way he explained this game concept to me was that you have these different coloured birds and then you have blocks with similar colours, tap on one of the blocks and the birds will fly and destroy that block. I listened to that description and I felt like, maybe this game concept is not a winner as such, but everybody liked these characters very much and we felt like, hey, we have really here a good starting point.

Rovio at the time was doing what Hed called “work for hire”, such as casual games commissioned by operators or other publishers. “We didn’t have a lot of capital to put into our game,” he said. Rovio kept half its 12-strong team doing the work for hire, and put the other half on Angry Birds. This meant the game took 8 months to develop rather than the usual 3 or 4 months, but he said this slower development time worked out well because the result was more polished.

Hed told us that most app developers push out apps too quickly:

They are concerned about getting their apps quickly out there on the market in order to start generating revenue. Before Angry Birds we did release a couple of other iPhone titles and they didn’t do well at all. We learned a lot from that and one of the things we learned is that never release something that is not completely finished, because it’s so easy for reviewers to just rip your game apart because something about it was not perfect. And that is exactly what is happening. It’s tremendously demanding, the consumer on the app store is tremendously demanding even if they pay only 99 cents, they still expect it to be perfect.

Even more significant was that Rovio consciously planned for Angry Birds to be more than just a game:

Our primary goal with Angry Birds was not to make a lot of money in the app store. Our primary goal was to build a brand.

Angry Birds took off pretty fast. It became the top seller on the iPhone App Store, first in Finland, then in the UK in February 2010, then in the USA in April 2010. Rovio made some decisions. First, it would stick with Angry Birds and build it into a strong franchise, rather than simply investing its profits into new game titles. Second, it would continue to offer free updates for the original app.

Where then are the “additional revenue streams” which Hed says are essential in order to thrive in this new world? In-app purchasing is one, he said, but Rovio decided not to sell additional levels via this channel. Instead it came up with the Mighty Eagle, which he calls a product rather than a feature:

In the Mighty Eagle we offered a way for users to pass levels that they are stuck on, so it gives added value to the users. But we made it into a product, and that is one of the important things of how we act in the marketplace, we make products, we don’t make features. And in this our big role model is Apple. You can see that nobody is that much interested in one “feature”. People want products. That’s why you don’t see Apple coming out with a feature called video calling. You see them coming out with a product called Face Time.

I am not entirely convinced by the distinction between products and features, but I understand the value of this way of marketing software. Hed says Rovio has been rewarded with a 40% conversion rate, much higher than for most in-app upgrades.

Rovio is also doing merchandising. 


This helps to sustain the franchise and to make sure that the franchise stays relevant for years to come, and it supports our game sales, and our game sales support our merchandising sales.

he says. It is another example of finding additional revenue streams.

Hed also talked about TV and film projects. Rovio partnered with 20th Century Fox to make a game that ties in with Rio the Movie, hence the game Angry Birds Rio.

He adds that mobile advertising is a key area:

We can see from the amount of time that people spend playing our games and playing everybody else’s games and using those apps, that mobile app advertising will be huge. We will see shifting of advertising towards mobile, because there users will be engaging for long periods of time, they will be exposed to brands repeatedly, they will be closer to the point of purchase.

This has worked for Rovio so far, though personally I am not sure for how long it can prosper if the Angry Birds franchise is all it has. It is a fashion thing and people will get bored of it – or does Rovio now have its own enduring franchise like Disney’s Mickey Mouse?

My main interest though is Hed’s insistence that software world is changing, prices are tumbling, and software developers will have to look for ways to monetize apps that go beyond the purchase price. “It’s the same for everybody. Now the industry is in the midst of transformation so everybody must adapt,” he says.

Mobile developers follow the users; PhoneGap most popular cross-platform toolkit says survey

Web Directions has published a State of Mobile Web Development based on input from around 1300 professional web developers. Note that this is a survey of web developers not app developers, which must skew the results if you are interested in the overall app picture, but it is still interesting.

One result deals with developer platform decisions. What are the factors that count when choosing a platform to develop for? New and minority mobile platform players will study this with interest, since getting a large number of developers on board is a high priority.

Here is the ranking of factors based on how many developers consider each one “Very important”:

  1. Number of potential users of your app: 68.55%
  2. Platform capabilities: 60.36%
  3. Ease of development: 58.55%
  4. Worldwide reach of marketplace: 40.02%
  5. Assistance in marketing your app: 23.40%

The message for the likes of Microsoft, HP and RIM is that the best way to attract developers is to sell lots of cool devices. Ease of development matters, but not as much as a large market.

Another section asks which toolkits are preferred if you are developing native apps with web technologies (note the exact question):

  1. PhoneGap 47.6%
  2. Appcelerator 26.5%
  3. Other 15.6%
  4. Adobe AIR 7.8%
  5. Apparatio 1.2%
  6. Rhomobile 1.2%

The sample here is rather small, with only 79 of the 1300 using PhoneGap, for example. I also quibble with the definitions here. Rhomobile’s Rhodes framework compiles Ruby to native code and I doubt it counts in the category “developing native apps with web technologies”. I am even sure whether AIR belongs alongside PhoneGap and Appcelerator, since AIR is Flash whereas the other two are HTML 5. Incidentally, Appcelerator is the company name and what should appear here is Titanium, which is the name of the cross-platform toolkit. Apparat.io is in private beta so its low take-up is not surprising.

Still, it is a good result for the top two. If you are interested in these toolkits don’t miss my recent interviews with André Charland at Nitobi (PhoneGap) and Jeff Haynie at Appcelerator.

The mobile app ecosystem before Apple – was it really this bad?

For some time I have been meaning to post about a talk I heard at Mobile World Congress, by Rovio (Angry Birds) CEO Mikael Hed. What interested me about this talk was not so much the Angry Birds app itself – now downloaded over 75 million times – but rather Hed’s thoughtful perspective on what it is like to be a software company in the App era. “It’s been a year of transformation not only for us but for the whole industry,” he told us.


Hed started his talk by describing life as a mobile games developer before Apple launched the iPhone in 2007. Rovio was founded in 2003, and did 51 titles before Angry Birds, encompassing “every type of game,” he said.

Before the iPhone came along we were on feature phones only. That market was completely different from the iPhone market today. Looking back on it, it’s a small miracle that there were any game companies in that ecosystem.

Why? Several reasons.

In order to have a game commercially available on a feature phone, you would have to make that game, and make probably nine other strong games in order to be interesting to the carriers. And the carriers would only take your game if you could support all the handsets that their customers had. That meant hundreds of handsets.

Dealing with the carriers was a huge headache.

You would have to make an agreement with each carrier in each country, and you had to have an all-day sales team working for you to do any business at all. It was really expensive.

After all that, the revenue share and payment system was loaded against you.

All operators would take more than half of the revenue that you would make, and then pay you a long time after your game is out. They would report quarterly, and once you get the report you send them an invoice, then they have ninety days to pay. So if by some miracle you manage to get your game onto their devices , the earliest time you would see your money would be six months later.

The system was poor for consumers too.

It was also very difficult for consumers to find these games. It varied a lot across the different carriers, how you find the games. You might have to send an SMS somewhere and get a link back, click on that, download the game, and then hope that the game would actually run on your device; and probably at the end even if you had the latest and greatest phone it was made for the lowest common denominator so it would not use any of the nice features of your phone. So you would get a poor experience, if it worked at all. That was the past ecosystem.

Ouch. Was it really that bad?

The immediate conclusion is that while Apple’s closed and dictatorial iOS ecosystem has drawbacks, it is at least one that works, whereas what existed before was badly broken.

So how are things for app developers now, in the Apple era? Look out for a follow-up post soon. And by the way, it is still by no means easy.

Building a PhoneGap app for iPhone with Adobe Dreamweaver CS5.5

After trying out Adobe’s new Dreamweaver CS5.5 for building a PhoneGap app for Google Android, I was keen to try the same for Apple iOS. In particular, I wanted to see if the performance problems with jQuery Mobile and PhoneGap on Android were also an issue on iOS.

This turned out to be more complex than I had imagined. Bear in mind that I have not done a lot of previous iOS development; but I reckon that makes me a good test case for Adobe’s market here. Ideally you should be able to use Dreamweaver alone to build your app and make a fortune on Apple’s popular app store.

I installed Dreamweaver CS5.5 without any issues and copied my Calculator example from PC to Mac. I am not going to repeat the steps that were the same as for Android; read my earlier post. I will mention that I puzzled over the setting for the IOS Developer Tools Path. After trying various sub-directories I eventually discovered that simply entering /Developer here works. One of the issues I have with this stuff is that clicking Help generally does not help. I resorted to watching one of Adobe’s videos and checking out the screen there.

My app worked fine though and I was able to run it up in the iPhone simulator. However I really wanted to test it on the device itself. The problem: this is all you get in Dreamweaver in terms of application settings:


I have not yet found any documentation from Adobe concerning what to do once your PhoneGap app is ready for on-device testing, though there may be some somewhere.

My solution was to download a separate install of PhoneGap, picking the latest version which is 0.9.5. Then I downloaded Xcode 4 and the latest iOS SDK; I had not previously installed this as I have only just signed up for Apple’s paid developer program.

I might have been better sticking with Xcode 3.x, as it turns out that PhoneGap’s support for Xcode 4 is still work in progress. I used Shazron Abdullah’s script which creates an Xcode 4 PhoneGap project from the command line. Then I copied my Calc application and the jQuery mobile directory into the project and opened it in Xcode 4.

Nothing worked and I had to do a number of things to get it to build. Most problems were solved using this guide by Cameron Perry and the comments which follow. Here’s what I recall doing:

  • I removed a red link to PhoneGapLib.xcodeproj and added it back from ~Documents/PhoneGapLib
  • I added i386 to the list of Valid architectures in build settings, for both the PhoneGapLib and my Calc project
  • I added an entry for PHONEGAPLIB to the Xcode 4 Source Trees, set to /Users/username/Documents/PhoneGapLib/ using the full path and not the ~Documents abbreviation.
  • I obtained an ID for my app from Apple’s developer portal and pasted into the project as the Bundle identifier (info section).

At this point the project almost built but I still got two Apple Mach-O Linker errors relating to PhoneGapDelegate:


I tried a couple of things to fix this. I added the PhoneGapLib project as a target dependency for Calc, which did no harm but was not a fix. Then I went to the Link Binary with Libraries section of Build Phases and added a reference to libPhoneGapLib.a


The odd thing is that libPhoneGapLib.a now appears in my project in red, suggesting something missing, but the project now builds fine; I am sure an Xcode 4 guru can advise.

So here is my app running on a real iPhone 4:


I slightly modified the design to fit the iPhone 4 screen.

Now for the bad news: performance is still not really good enough. To be clear, the problem is a slight pause between tapping a button and the number being entered. One bad symptom is that if you are in a hurry and tap several numbers quickly, some may not register. The iPhone 4 runs the app slightly better than my HTC Desire, but I would still not be happy releasing it with this performance – leaving aside the fact that a better calculator app comes free with the iPhone.

I tried specifying a release build in Xcode 4 but it made little difference. I suspect performance could be improved either by not using jQuery mobile, or by configuring it to reduce the richness of the buttons it creates.

Leaving that aside, it seems to me that Adobe has some work to do in making it easier to get from a Dreamweaver project running in the emulator, to an app that you can test on a device and deploy to the app store. Although the steps I took seem arduous, it is not really so bad once you get it working. You could create a much more complex app entirely within Dreamweaver, and then the work involved in moving it to Xcode would be pretty much the same as I had to do for my simple calculator. So I am not going to say that the PhoneGap integration is no use, just that it needs better documentation. Maybe in the next version we will get fuller integration that will do device build and deploy as well as building for the simulator.

Photosynth for iPhone: capturing the unphotographable

We are having some unusually fine weather in the UK and I went for a walk in the Derbyshire Peak District yesterday. I was reflecting how hard it is to photograph wide vistas of countryside when I remembered that I installed the Microsoft Photosynth iPhone app a couple of weeks ago.


It really is easy to use: you just fire up the app, tap to start a new picture, and turn the iPhone to new positions guided by on-screen markers. When the iPhone beeps, hold it still and a new photo is added.


Panoramic photography is not new of course; my old Canon Ixus has a panorama feature. However, you have to navigate several menus to get the mode engaged, manually position the camera, and then use a separate application to stitch the images together.

The Photosynth app by contrast is great to use, and I have taken a landscape picture which I would never have bothered with before. My only complaint is that the beep can be hard to hear, but even if you miss it, the app does a reasonable job, especially in bright sunlight.

There are plenty of interesting images now turning up on the official Photosynth site – check the Mobile Panoramas section.

For more information see the official announcement post and video.

The point to ponder is why the app has come out first for Apple’s iPhone, rather than the company’s own Windows Phone7? Apparently a Windows Phone version is in preparation.

Logitech’s Squeezebox app for iPhone and iPad: nice to have but a missed opportunity

Logitech has released a Squeezebox control app for iPhone and iPad, to match an existing app for Android.

I am a Squeezebox fan. The system is excellent for multi-room – just put a Squeezebox player in any room where you want music, put it on your home network (usually wifi), and it finds your music collection. You can get a player like the Touch, which I reviewed here, or an all-in-one unit like the Boom, which I reviewed here. I rip CDs to FLAC using dbPowerAmp. Squeezebox does multi-room properly, in that each player can play something different, and the sound quality is generally excellent. Internet radio is also available, and there is no need to have a separate tuner.

That said, the appeal of Squeezebox is limited by the techie nature of the product, especially the software. When Logitech acquired Slimdevices in 2006, I thought we might see a new focus on ease of use, but it has not really happened. Apple does this better, making it hard for Squeezebox to compete with iTunes and Airport Express or Apple TV, even though the Squeezebox system is more open and superior in some ways.

There are multiple ways to control a Squeezebox player. You can use a remote to navigate the display on the player, whether the simple but bold display on a Classic, or the graphical colour display on a Touch. You can use touch control on a Touch screen. You can use a web browser on a PC, Mac or any machine on the network. Or you use an app such as SqueezePlay on a PC, or third party apps like iPeng on iOS, or Squeezepad on an iPad.

All these methods work, but in general the web browser is the most feature-rich and good if you are sitting at a desk, while the apps are better if you have a suitable device like an iPhone, iPad, or Android smartphone. The remotes work, but you need to be close enough to read the display and navigation can be fiddly.

An iPhone app is ideal though, so it is great news that Logitech has now released an official app for the iPhone. It is free, and unless you already have iPeng a must-have for Squeezebox users who have an iPhone. Apps are better than a remote for all sorts of reasons:

  • No need to point at an infra-red receptor
  • No need to read a distant display
  • Album artwork on the remote
  • More features conveniently available

I downloaded the new app and ran it. The first thing you have to do is to log into Mysqueezebox.com, Logitech’s internet service. In fact, the impression you get is that you cannot use the app without logging on. I am not sure if there is any way round this, but it seems odd to me. Presuming you are using a local Squeezebox server, why require log-on to an internet service?

I already have a Mysqueezebox account though, so I logged on, whereupon the various players we have around the house appeared for selection. Once selected, I get a menu similar to that on a physical player or on SqueezePlay:


If I click My Music, I can navigate using the usual range of options, including Artists, Albums, Genres, New Music (which means recently added) or my favourite, Random Mix. Just selected an album is not enough to play it, but shows the tracks; tapping the first track starts it playing. Eventually you will get the Now Playing screen, which you can also access by pressing the musical note icon on the Home screen.


Perhaps I am fussy, but I am not happy with this screen. As you can see, the album artwork is overlaid with text and controls, and although a progress bar can be shown or hidden by tapping, the other controls seem immoveable, which means you cannot see the full artwork.

My other complaint is that the user interface, while familiar to those who already know Squeezebox, lacks the usability you expect from an iPhone app. Operating it takes too many taps. Take search, for example. You want to find a different song, so you tap Back to get the Home screen, then Search. Type something in, then click Search. The next screen then asks whether you want to search in My Music or Internet Radio. You tap My Music, and still get no results, just a list that says Artists, Albums, Songs, Playlists. You tap Songs, and now you finally get a results list. Tap a song to play.

Personally I think search is such a critical function that it should be available directly from the Now Playing screen; and that it should be smart enough to look for matches anywhere it can and present some top matches immediately.

Another annoyance is that you cannot actually play a song through the iPhone itself. This is such an obvious feature that I cannot understand why Logitech has not implemented it; it would enable your Squeezebox music collection for personal listening on a device. Perhaps Logitech imagines that it is protecting sales of its players, when in fact it is just undermining the appeal of the system.

Well, it is free, I like the Squeezebox system, and the app is useful, so perhaps I am complaining too much. It is frustrating though, because with a little investment in software Logitech could bring its excellent features to a broader group of users.

Native apps better than web apps? That’s silly talk says PhoneGap president

When I attended Mobile World Congress in February one of my goals was to explore the merits of the various different approaches to writing cross-platform mobile apps. One of the key ones is PhoneGap, and I got in touch with Nitobi’s president and co-founder André Charland. As it turned out he was not at that particular event, but he kept in touch and I spoke to him last week.

PhoneGap works by using the installed HTML and JavaScript engine on the device as a runtime for apps. That is not as limiting as it may sound, since today’s devices have high performance JavaScript engines, and PhoneGap apps can be extended with native plug-ins if necessary. But aren’t there inconsistencies between all these different browser engines?

Sure, it’s kinda like doing web development today. Just a lot better because it’s just different flavours of WebKit, not WebKit, Gecko, whatever is in IE, and all sorts of other differentiation. So that’s definitely how it is, but that is being overcome rather quickly I’d say with modern mobile JavaScript libraries. There’s JQuery Mobile, there’s Sencha Touch, there’s DoJo Mobile just released, SproutCore, which is backed by Strobe, which is kinda the core of Apple’s MobileMe.

There’s tons of these things, Zepto.js which is from the scriptaculous guy, Jo which is a framework out of a Palm engineer, the list of JavaScript frameworks coming out is getting longer and longer and they’re getting refined and used quite a bit, and those really deal with these platform nuances.

At the same time, phone manufacturers, or iOS, Android, WebOS, and now RIM, they’re competing to have the best WebKit. That means you’re getting more HTML5 features implemented quicker, you’re getting better JavaScript performance, and PhoneGap developers get to take advantage of that.

says Charland. He goes further when I put to him the argument made by native code advocates – Apple CEO Steve Jobs among them – that PhoneGap apps can never achieve the level of integration, the level of performance that they get with native code. Will the gap narrow?

I think it will go away, and people will look back on what they’re saying today and think, that was a silly thing to say.

Today there are definitely performance benefits you can get with native code, and our answer to that is simply that PhoneGap is a bundle made of core libraries, so at any point in your application that you don’t want to use HTML and JavaScript you can write a native plugin, it’s a very flexible, extensible architecture … So you can do it. We don’t necessarily say that’s the best way to go. Really if you’re into good software development practices the web stack will get you 90%, 95% of the way there, so that apps are indistinguishable from native apps.

Some of the native features we see in iOS apps, they’re reminiscent of Flash home pages of ten years ago, sure you can’t do it in HTML and JavaScript but it doesn’t add any value to the end user, and it detracts from the actual purpose of the application.

The other thing is, a lot of these HTML and JavaScript things, are one step away from being as good in a web stack as they are in native. When hardware acceleration gets into WebKit and the browser, then performance is really just as good.

Charland is also enthusiastic about Adobe’s recent announcement, that PhoneGap is integrated into Dreamweaver 5.5:

Two things are exciting from our perspective. It gives us massive reach. Dreamweaver is a widely used product that ties in very nicely to the other parts of the creative suite toolchain, so you can get from a high-level graphic concept to code a lot quicker. Having PhoneGap and JQuery Mobile in there together is nice, JQuery Mobile is definitely one of the more popular frameworks that we see our community latching on to.

The other thing is that Dreamweaver targets a broader level of developer, it’s maybe not super hard core, either Vi or super-enterprise, Eclipse guys, you know, it’s people who are more focused on the UI side of things. Now it gives them access to quickly use PhoneGap and package their applications, test them, prove their concepts, send them out to the marketplace.

He says Adobe should embrace HTML and Flash equally.

I also asked about Windows Phone support, and given that Microsoft shows no sign of implementing WebKit, I was surprised to get a strongly positive response:

We have something like 80% of the APIs in PhoneGap running on Windows Phone already. That’s open and in the public repo. We are just waiting basically for the IE9 functionality to hit the phone. The sooner they get that out in public, the sooner we can support Windows Phone 7. We have customers knocking at our door begging for it, we’ve actually signed contracts to implement it, with some very large customers. Just can’t there soon enough, really. I think it’s an oversight on their part to not get IE9 onto the phone quicker.

PhoneGap is at version 0.94 at the moment; Charland says 0.95 will be out “in a few weeks” and he is hoping to get 1.0 completed by O’Reilly OSCON in July.

I’ve posted nearly the complete transcript of my interview, so if you are interested in Charland’s comments on building a business on open source, and how PhoneGap compares to Appcelerator’s Titanium, and what to do about different implementations of local SQL on devices, be sure to read the longer piece.

Escaping Apple: trying to switch away is hard

Mark Wadham posts his Thoughts on switching to Android. Last week he sold his iPhone 4 and switched to an HTC Desire S. I found this interesting, since I have an iPhone 4 and an HTC Desire.

The motive behind Wadham’s switch was to escape Apple’s “over-controlling ways”, rather than immediate dissatisfaction with its products, and there is mild disappointment running through his whole piece:

So in summary, android isn’t really /that/ far off the iPhone. It’s missing the cleanness of the user experience, consistency in the user interface and the glorious wealth of apps, but hopefully that will all come in time. This is a great little phone and I’m happy I made the switch. 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, but if you’re someone who likes to tweak and customise and play around with your device android seems much more suited than Apple’s offering.

There is also some irony: HTC’s offering is not as free as he would like.

I would have loved to get rid of HTC Sense and install one of the modded roms like Cyanogen, but that currently isn’t possible due to restrictions HTC has placed on these new handsets …The good news is that, according to the research I’ve done, the root for the Desire S (and the incredible S) isn’t far off.Actually the worst thing about this phone is that it comes with a Facebook app that I can’t remove until it gets rooted.

Still, there is no question that Android is a less tightly controlled platform than iOS. The fact that you can install apps from outside Google’s Android Market is all you need to know.

In usability though, Android falls short. It lacks the obsessive attention to design that characterises Apple’s devices and software; and once you are used to iOS it is particularly hard to switch:

Eventually I got the hang of it, but even now after two days of playing and installing apps and tweaks, the UI still feels counter-intuitive and I have to consciously remember how to do things rather than it being obvious and simple like iOS.

One thing I have noticed since getting these two phones is the impact of Apple’s dock connector. There are countless iPhone/iPod docks and although there is often an option to use a non-Apple device with a mini-jack cable it is not as convenient or elegant. You cannot easily build a generic Android dock because there is no exact equivalent.

Another issue is apps. Once you have purchased a bunch of apps, you can transfer these to another iOS device. If you switch to Android, you have to start again.

There is also iTunes to think about. Let’s say you have got used to iTunes and have your music stored there. While it is possible to transfer non-DRM music to Android or other non-Apple devices, it is not necessarily obvious how to do so; and iTunes itself will only sync to Apple devices. Personally I am not a fan of iTunes; but I can see how it tends to encourage users to stick with Apple.

The bottom line is that escaping Apple requires some determination, once you are hooked into its ecosystem.

Review: Lenco iPD-4500 portable iPod dock–zip up your sounds

Today’s gadget is an iPod travel dock with a few distinctive features. The Lenco iPD-4500 zips up to look like a sturdy travel bag; though at 250 x 180 x 80mm it is on the bulky side.


It is not really a bag, but unzips to form an iPod dock in the base with speakers in the top.


Although  it looks as if there are four speaker drivers it seems only the lower pair are active. The top panel is ported for better bass extension.

The unit has a built-in rechargeable NiMH battery which claims up to 8 hours of playback from a full charge. A mains adaptor is supplied. If mains power is on, then when seated in the dock, the iPod or iPhone charges, but not when on battery.

Along with the iPod dock there is a standard mini-jack input for non-Apple devices or smaller iPods. Controls on the device itself are limited to on-off and volume, but a compartment on the base unit opens to reveal a tiny remote, secured in a clip, with on-off, play-pause, track forward and back, and volume.


Lenco also supplies a short mini-jack cable. I would have preferred a longer cable, since the short one will be awkward if you want to connect, say, a laptop for playing a movie; but of course you can use your own cable.

Sound quality

So how does it sound? Contrary to what I had expected from the advertised “bass boost”, this is not a particularly bass-heavy or boomy unit but has a pleasantly balanced sound. It is important to set your expectations. No, the iPD-4500 does not sound as good as docks geared more for home use, that are heavier, larger and more expensive. Compare it to the tiny speaker in an iPhone though, and it is a massive improvement. I rate it one of the better-sounding travel docks I have tried. It is worth experimenting with position too; you can get a weightier sound by positioning the dock near a wall or in a corner. As with any audio device, I recommend hearing it before purchase if possible.

According to the rather uninformative specifications there are 2 x 3W speakers, though without qualification 3W does not mean much. What you really want to know is how loud it goes; and the answer is loud enough for enjoying music in a hotel room or a small tent; but not loud enough if you really want to rock out or drown out significant background noise.

Design and appearance

It has to be said, this is not a beautiful device. A colleague said it looks like a toasted sandwich maker; and I see her point. It does not bother me because I care more about the convenience and the sound, but it is a factor.

I also noticed that the hinged panel which gives access to the front compartment tends to catch when you try to close it so needs to be operated with care.

On the plus side, when zipped up the iPD-4500 does feel securely protected from knocks and bumps, and I would be more confident about subjecting this to the rough and tumble of travel luggage than with most portable speakers.

A flaw is that the mains adaptor does not fit in the pouch, but has to be carried separately. Further, if you were camping rather than in a hotel, it might not be easy to recharge. A car adaptor would be worth considering.

Value for money

The iPD-4500 is on offer for around £75.00 which is at the upper end of the price range for a portable iPod dock. Then again, it sounds good, includes a rechargeable battery and a remote, and has a particularly robust integrated case.

It still strikes me as a premium price; and bear in mind that the Logitech Rechargeable Speaker S315i, for example, claims up to 20 hours playback, though with no remote, and plays somewhat louder. The S315i is nominally more expensive, but seems widely discounted to below the price of the iPD-4500.

What might swing it is if you particularly like the sound quality, or if the strong packaging suits your travelling lifestyle.