Archive for January, 2011

BlackBerry Dev Day Review

As a web developer I’ve been always interested in making my web apps accessible from any mobile devices, given that the trend is to have them “hooked” to the net. And BlackBerry makes no exception, or to be correct, BlackBerry are among the first to let their devices be permanently on.

So no wander, why I immediately register for the BlackBerry Dev Day. Bellow are some of my notes taken at this event.

First “hands-on” session was – Getting Started Developing on BlackBerry, which presented the BlackBerry ecosystem with some interesting statistics like:

  • 565 BlackBerry carriers in 175 countries
  • 55 million subscribers
  • AppWorld – the BB app-store (similar in concept with the Apple’s app-store), with a distribution in 70 countries, but … here lays the surprise, … none in the Middle East. But, there is a promise that BlackBerry is working hard on that. However, there are other channels of distributing the applications, like collaborating with the carries, or direct download.

A new developer should get hands on version 5.0 as the market share is 46% of all BlackBerries, plus anything developed on 5.0 is compatible with 5.x and the newer 6.x versions.

One other aspect, which appeared interesting from my point of view, was the overview of BlackBerry network transports (gateways). Each is in direct correlation with the speed of data traveling across the network, and ultimately can affect the user experience of the end user, in particular if the app is web based, where all data, including the UI elements are loaded from a remote server.

  • TCP Cellular
  • WAP
  • TCP Wi-Fi
  • BB Internet Service
  • BB Mobile Data Service (MDS)

Another point I learned was that all apps should be signed, so a developer must apply for a key to RIM, which costs around USD20, a key which can also sign PlayBook applications.

The usual developer tools are:

  • Eclipse
  • BB JDE Plugin for Eclipse
  • other IDEs

The Pillars of Web Development are:

  1. BlackBerry’s Browser – the application runs in the device’s web browser.
  2. Hybrid / BrowserField – the BrowserField is a browser which can be embedded into the application. From the user point of view the most relevant thing is that you can jump between focusable elements of a page without the need of a pointer (arrow).
  3. BlackBerry WebWorks – is the web application running as described above, but with full access to the device capabilities, be it BB messenger, PIM, calendar, geolocation, etc. Other particular features to WebWorks are the contextual menus which ensure a smoother navigation between different elements of the app, access to other widgets, exit/quit procedure.

The WebWorks Bootcamp emphasized on taking in consideration the network latency, and the advantage of using WebWorks (trying to compress the code as much as possible) as opposite to running in the browser app. In regrad to images, best is to use pngs or jpegs (the former being smallest in size), and allow MDS to resize them, instead of the browser to avoid latencies introduced by loading such high resolution images.

To my surprise, JavaScript is disabled by default in 5.0, in contrast to Apple’s devices which are pro-JavaScript, in fact for iOS there is an web-API to give the user the feel of a native app. Hmmm. The stated reason for disabling the JavaScript is that the power processing is much slower than that of a PC, so such scripts will run much slower. More, BlackBerry is designed to stop unresponsive scripts after 10 seconds. On the other side, the Adobe stuffs are at their “home”.

The recommendation in such case is to use 6.0, in order to give full user experience, where HTML5 and CSS3 are well supported, jQuery and over JavaScript frameworks work to their maximum.

As for the PlayBook (the tablet), the web browser is WebKit based, supports HTML5, CSS3, as well as Adobe’s Flash or AIR, and all discussed stuff re WebWorks apply here, too.

I haven’t insisted on the talks regarding the way of building native applications (although it worth to mention some examples, where the icon or the app title changes to the context – like the weather status, this way an app becoming a “Super App” and core part of the device and OS itself, being useful even without never opening that particular application).

In conclusion, we had part of an interesting day, with some examples in the real world. Hopefully, AppWorld will be available soon world-wide, so developers can address local markets, too. Myself, I’ll remain stick with Ruby on Rails, my current web development framework of choice.

Of course, native apps have their own advantage in terms of user experience for any type of “smart device”, but with continued improvements in network speeds and browsers capabilities, the web apps have a bright future. What do you think?