Tag Archives: html

Sensation Vodafone 360 widget live

Sensation_H1
It’s always cool to work on new mobile platforms. And since I’m a big believer of HTML as a future cross-platform development environment, the Vodafone widget platform shows a nice promise. I had done some experiments with the platform, but now the first widget went live.

Together with The Saints I developed a widget for Sensation for the Vodafone platform. It shows the latest video’s from Sensation’s Youtube channel. It also shows the news around their world-wide events, and the latest tweets from the official Sensation channel.

For those running the Vodafone widgets, or owning the H1 or M1: It’s available in the Vodafone widget market. http://widget.vodafone.com/dev/widgets/sensation_16528

Since most of the content of Sensation is on public platforms (Youtube, Twitter), which all have an API, the widget could be developped fairly easy without further technical support by the organisation.

HTML5 webapps broken on the iPad

iPad?

Apple seems to be a big proponent of HTML5: They use it for their new iAds, as Steve proudly announced during his last Keynote. So when I wanted to maken an Ipad webapp, I didn’t expect any issues. For a client of mine, I planned to work on an iPad webapp this week. It’s even the reason I bought an iPad.

Let’s start with the only good news: Setting an homescreen image, with

<link rel="apple-touch-icon" href="/custom_icon.png"/>

does work, and if you make the image 72 pixels wide, it looks great on both iPhone and iPad (the previous advice was 57 pixels, but this looks blurry on the iPad as it’s scaled up).

On the iPhone, there are some other properties you can set on a webpage to make it work offline: Besides the homescreen icon, you can set the status bar color, startup image, and viewport size, and make files work when not online. The result looks and works like an app instead of a webpage: No URL field, navigation buttons, a startscreen, etc. Apple invented these, and has extended their support in their OS updates. See for a good description: How to Make an HTML5 iPhone App and a great HTML5 example app is the PieGuy game. They work great, and can make it easier to build and distribute an application, without sending it to Apple for approval (the current appstore mess is a whole different blogpost).

Since Apple supports this in their iPhone OS, and the iPad runs iPhone OS 3.2, I expected this all to work. Unfortunately, it doesn’t.
On the iPad, the startup image and viewport size are ignored when run in webapp-mode. The viewport size is only used when shown in a normal browser window, and the startup image is never shown :(.

On an iPhone with OS 3.1, both do work. This makes the result, on an iPad, work more like a (broken) webpage, than an application.

Why did apple take working stuff out, when upgrading the iPhone OS from 3.1 to 3.2 for the iPad? Is this a simple omission which will be fixed, or is apple actively moving away from HTML5 webapps for the iPad, further pushing their appstore? Only time will tell.

Update:

I looked into this some more, and have more results:

If  you use a image with the right size, (1024*768), it does (sometimes) work on my iPad as startup image. My previous tests used a iphone-sized image, which is totally ignored on the iPad. However, it often takes a few tries before it shows the loading image, and sometimes shows a screenshot of the page, before showing the default loading screen. (so the flow is then screenshot->default.png->webpage).

I still can’t get the viewport tag to work in webapp mode: If I set the viewport to a predefined with, like:
<meta name=”viewport” content=”user-scalable=no, width=1024″/>
this does work in Safari, but is ignored in Webapp mode. If I set a scale:
<meta name=”viewport” content=”initial-scale=1.0, user-scalable=no”/>
and test in Safari, this does work on first load. However, if I rotate my ipad, and rotate back, the scale is set differently.

Mobile Widget Camp talk: Hello Cats

View more presentations from PanMan.

Today I gave a quick (really quick: About 3 minutes) talk on how easy it is to build a mobile widget. To show that I ported the jQuery Cats example to a mobile widget. In the talk above I go over all the steps needed to run web code on a phone. Not shown in the slides, but it was in the talk, is that this actually runs on phones :).

Comparing mobile widget platforms

picture-33 V.S. wrt_quickstart_button

Mobile widgets seem to be the new black. This week I tried two different mobile widget platforms: The Nokia Web Runtime and the Opera/Vodafone widget platform.

Both platforms make it possible to build applications that can run on mobile phones, developed in languages known to all webdeveloppers: HTML/Javascript and CSS. Nokia with it’s runtime (logically) targets it’s own handsets for this platform. Opera has a broader approach than just phones: They see the widget platform as something that can run on phones, but also desktop PC’s, set-top boxes, internet tablets, and even game consoles. While this sounds ambitious, Opera makes browsers for all these devices, so it might not be to far-fetched.

On a side note: It’s interesting how  the boundaries between applications, websites and widgets are all disappearing: These widgets are basically downloadable webapplications, which can run totally offline (but often will interact with the  data on the Internet).

File formats

To start with the good: Both platforms are really similar. They both use a renamed zipfile to pack a bunch of HTML, CSS and Javascript files with a config XML file into one downloadable ‘application’. Opera calls it’s config data config.xml, and it’s files .wgt. Nokia uses info.plist XML files (which have a really strange syntax, for XML files. Who came up with that?)  and .wgz for the files. But on general the differences here aren’t that big, and it should be possible to build one widget that runs on both platforms (if you copy the file to the two 2 extensions). The actual code is all standard HTML, with some (Javascript) extensions to interact with the device, and the various states a widget can be in (some can be dockable, for example).

A advantage of the Opera platform is that they target the (still developing)  W3C standard which (hopefully) leads to more interoperability between widget platforms.

SDK’s:

The SDK’s they offer are more different: Nokia offers a HUGE SDK (seriously, 622 MB install to run some HTML code?!). Also their SDK will only install (and run) in Windows, which is a pitty as a lot of webdev’s use Mac’s these days (I know it’s possible to run windows apps on a mac, but it is less convenient). Another disadvantage is the need to signup on the Forum Nokia website to download the SDK: The signup isn’t too much of a hassle, but for me it took quite long for the confirmation mail to arrive. This SDK does allow you to run widgets, but doesn’t assist in the creation of the files (not that it’s too hard to do manually, but still). In their defense: they also offer a plugin for the Aptana Studio, and this will become the preferred method of development, but I wanted to use my own editors to start with. I have also taken a look at the Aptana studio, and that looks cleaner (but stopped working at my computer after a few hours).

Vodafone Betavine/Opera offers a small SDK, which consists of 3 parts. The first is a Betavine branded “widget packager”. This is a simple tool that assists in the making of the XML file, and the creation of the zipfile. It includes some sample widgets. It also allows you to add some know frameworks to your widget, but unfortunately the popular jQuery isn’t one of the included frameworks. While the process this isn’t too difficult to do manually, the wizard is a nice way to get started. Also included is the standard desktop Opera browser, that enables you to (test) run widgets. The third item in the download is a Betavine branded .sis file that can be installed on Nokia S60 phones to run the widgets.

Phone Integration

In terms of Phone integration the Nokia runtime is the clear winner: The widgets immediately work on the 5800 Xpress music I tried them on, and to the user look like other applications. The Vodafone widgets on the other hand, first required me to install the Vodafone Runtime on my phone. Even then the widgets (currently) don’t live with the other applications, but in their own, branded, folder. While this isn’t too complex, tasks like these are hard to explain to the average user. However I expect Vodafone to have their runtime pre-installed on phones they sell, and to have more device integration.

Another advantage of the Nokia platform is that it has Device libraries which enable widgets to access device specific data. This includes location, calendar entries, contacts, and other data. Having this access makes the widgets a true application platform, and are a big advantage over standard (mobile) websites that don’t have these capabilities. This is something that is missing from the Opera platform.

Conclusion:

I now have a phone which has 2 widget runtimes: Both the Vodafone/opera and the Nokia one. Both are similar in what they support, and while Vodafone/Opera had a bit smoother process (for me), the Nokia SDK also works and currently offers device integration that the Opera platform lacks. The next few months we’ll see a battle between these two, to become “the one true” widget platform. My guess is that both grow towards each other: Opera will add device capabilities (starting with location), and since the Opera one is backed by the W3C, it will become the standard. Nokia will simply start to (also) support this standard, which shouldn’t be too hard: Mostly adapting a different type of config file and extension. However I do hope that standard will offer the device capabilities that Nokia currently has.

Important to conclude is that it’s really simple to develop for both platforms: I have ported some HTML/Javascript code I had to both platforms in just a few hours. So get hacking, and build a nice widget!

(Full disclosure: I organized MobileDevCamp, sponsored by Nokia, and I am organizing Mobile Widgetcamp, sponsored by Vodafone. However this post only reflects my own opinions).