Tag Archives: blackberry

On BlackBerry 10, Cascades UI and Adobe AIR

I spoke to Jeff Lejeune, RIM’s Advanced User Interface Director, here at BlackBerry DevCon Europe in Amsterdam.

He is part of the team responsible for the Cascades UI, a native code UI framework for the forthcoming BlackBerry 10 OS. One of the things he told me is that the Cascades name is actually being used for parts of the API beyond the user interface. It is a major part of the new operating system.

I had not appreciated until today the extent of the likely difference between BlackBerry 10 and the current Tablet OS 1.0 or Playbook OS 2.0. Since the PlayBook OS is already based on QNX, I had assumed that BlackBerry 10 would be an incremental update rather than a radical new direction.

Certainly there is less difference between PlayBook OS 2.0 and BlackBerry 10 then there is between BlackBerry 7.0 and the PlayBook OS, so my assumption was not completely wrong. That said, the introduction of the Cascades UI acquired with The Astonishing Tribe is a major change. Lejune told me that Cascades UI will be in effect the native UI of BlackBerry 10, and the built-in apps will use it.

The first version of the PlayBook uses both native code and Adobe AIR for its built-in apps.

RIM has given full backing to Adobe AIR at this event, presenting it as one of the supported development platforms and saying that it will support AIR for as long as Adobe does and maybe even longer. Even so, it would be fair to say that RIM is moving away from AIR and towards native code and Cascades UI in BlackBerry 10.

Further, Adobe itself has changed direction since the launch of the PlayBook last year. Adobe has made it clear that while Flash, Flex and AIR are still important, its strategic direction is HTML 5 when it comes to development platforms. Some aspects of Flex, the code-based approach to AIR authoring, are being wound down, including the visual designer in Flash Builder.

My sense therefore is that AIR is not the best choice if you are considering how to develop for BlackBerry 10 – and BlackBerry 10 is the future of RIM’s platform. The primary choice should be between Cascades UI, for best performance and integration, or WebWorks (PhoneGap), for development in HTML and JavaScript and cross-platform code.

What is in BlackBerry PlayBook OS 2.0: new universal inbox and remote control

Here at BlackBerry Devcon Europe attendees were shown the key features of PlayBook 2.0, an update for the RIM tablet that will run on the existing hardware.

Aside from new runtimes for developers and some usability tweaks, the main changes users will notice are a new universal inbox and PIM (Personal Information Manager), and deeper integration between the PlayBook and BlackBerry smartphones.

The PlayBook 2.0 PIM offers a single inbox for Facebook, LinkedIn and Twitter as well as email.

image

The PIM includes an embedded web browser so that you can view HTML messages without leaving the application.

The application also covers calendar and contacts.

image

If you look in detail at a meeting, you can see the other attendees, presuming that the information is available.

image

One of the aims is to aggregate information drawn from social networks and from the internet. It is a compelling idea, and one that Microsoft has also used. For example, when you view an email the Outlook Social Connector automatically looks up status messages from FaceBook and LinkedIn from the author. Windows Phone also aggregates information from multiple social networks in its People hub.

RIM talked about adding web information. We were given the example of getting an email from someone and viewing recent press releases from their company within the PlayBook 2.0 PIM. If this is well implemented, it does make sense, giving you useful background without the need of a manual web search. A contact record is no longer just name, address and company, but a portal into that person’s story and current activity.

The other big new feature in PlayBook 2.0 is remote control. You can use your BlackBerry SmartPhone as a controller and input device for the PlayBook.

What is the point of this? A good question, to which the most obvious answer is that you can use the physical keypad on a BlackBerry to type on the PlayBook. This drew applause when demonstrated.

I asked for other use cases on Twitter. The main other suggestion was using a BlackBerry as a remote when your PlayBook is plugged into a screen as a media player or presenter.

The concept goes beyond this though. Here is new CEO Thorsten Heins speaking in the keynote:

Just take this idea a step further. Think about BlackBerry 10 being a platform, for mobile computing, for smartphones, so it really shows the deep integration of the BlackBerry platform. Think about having your PlayBook somewhere on your desk at your home, and you can control everything just from your BlackBerry, I think that is fantastic

Incidentally, RIM’s operating system naming is confusing. This is how it goes. BlackBerry OS up to and including 7.0 is the old smartphone OS that is being phased out. The new OS is based on QNX and first seen in the PlayBook, which runs Tablet OS 1.0. Version 2.0 of this OS, due out later this month with the features mentioned above, is called PlayBook OS 2.0.

BlackBerry 10 is the next iteration of this QNX-based OS and will run on SmartPhones as well as on the PlayBook. BlackBerry 10 is expected later in 2012, probably towards the end of the year.

RIM’s future depends on wide acceptance of BlackBerry 10. The uncomfortable question: how many mobile operating systems can succeed? It seems that Apple iOS and Google Android are well established, but the future prospects of new entrants such as BlackBerry 10 and Windows 8 is open to speculation.

Update: I visited the exhibition here and spent some time hands-on with the version of the PIM that is installed on the PlayBook devices. It is disappointing, though bear in mind that it is not, I was told, the final version (though if the final version is coming this month you would have thought it is not far off).

Some key points:

  • The embedded HTML rendering in the email client is just for the message itself. If you tap a link, it takes you into the separate web browser app.
  • In order to get social network status updates from the author of an email message, you have to be logged into that social network and the author must already be one of your “friends”, or so I was told. I hope this is incorrect, as it seems largely to defeat the purpose of this kind of integration. Outlook’s social connector retrieves status updates from anyone irrespective of whether you are logged into that network or have them on your friends list.
  • I asked about SharePoint integration and received the vaguest of answers. A SharePoint app is in preparation but there is no word on when it might appear, and it may be dependent on some sort of Microsoft input.
  • There is no official cloud storage service from RIM. You can use third-party services like Dropbox. Enterprises are expected to use internal file shares, via VPN if necessary.

It seems to me that RIM is in danger of missing an important market for PlayBook here. Many RIM customers use Microsoft’s platform because of the link with Exchange. A tablet with excellent support for SharePoint and Office 365 would have obvious value, and Microsoft can be expected to tap into this with Windows 8. BlackBerry could get there first with PlayBook but it looks like this will not be the case.

What will it take to make RIM’s Playbook sell?

I am at RIM’s Blackberry DevCon in Amsterdam (where it is so cold that the canals have frozen). Attendees have been given a free Blackberry Playbook, the neat 7” tablet running an operating system based on QNX, acquired by RIM in 2010.

image

The Playbook was launched in spring 2011, and sales have disappointed. Exact numbers are hard to find; the Guardian estimated that RIM ordered 2.5m devices, while Crackberry.com says 5m. How many sold? In the three reported quarters, RIM said 500,000, 200,000 and 150,000 were shipped. Prices have been falling, naturally, but it seems that there are plenty left.

Nevertheless, this is an attractive device. The operating system is smooth and the size is convenient. Why has it failed?

One factor is that the device is designed as a companion to a Blackberry smartphone. Email does not work unless you have a Blackberry, or can get by with a web browser client. RIM thereby reduced the market to existing Blackberry owners, a mistake which should be rectified when version 2.0 of the operating system is released – expected later this month.

The second problem is the the extent to which Apple owns the tablet market. When you buy an iPad you know you are buying into a strong ecosystem and that every app vendor has to support it. That is not the case with the Playbook, making it a riskier choice. RIM’s fix is to introduce support for Android apps, though there are a few caveats here. Perhaps the biggest is this: if you want to run Android apps, why not just get an Android tablet and avoid any compromises?

The Playbook is a delightful device. The big question – for RIM and other new entrants into the tablet market – is what will make it sell, other than pricing it below cost?

Amazon found an answer for its Kindle Fire: low price, Kindle brand making it an e-book reader as well as a tablet, and a business model based on its retail business. Amazon can sell the device at a loss and still make a profit.

It is not yet clear to me what RIM’s answer can be. The most obvious one is to make it truly compelling for the large market of Blackberry smartphone users, but not if that means crippling it for everyone else as with the 1.0 release.

Another factor is that the device has to be nearly perfect. On the conference device, it took me 10 minutes to send a tweet. The reason was that the supplied twitter app is really a link to the twitter web site. That in itself is not so bad, but I found the soft keyboard unwilling to pop up reliably when twitter’s tweet authoring window was open. Making a correction was particularly frustrating. A small thing; but one or two frustrations like this are enough to make a good experience into a bad one.

Version 2.0 of the operating system does promise numerous improvements though, and watch this space for a detailed review as soon as I can get my hands on it.

Hands On with Adobe Flash Builder 4.5 for Android

I have been trying several cross-platform development tools for mobile, and today I set out to create an Adobe AIR app for Android using the new Flash Builder 4.5, available separately or as part of the Creative Suite CS5.5.

I made another calculator app, which may seem boring but gives me a chance to compare like with like.

You get started by running up Flash Builder and creating a new Flex Mobile Project.

image

The disappointment here is that only Android is supported, so it is not all that cross-platform. According to Adobe’s Andrew Shorten:

An update to Flash Builder, scheduled for June 2011, will provide additional options to package Flex applications for Apple iOS and will include built-in support for packaging both Flex and ActionScript applications for BlackBerry Tablet OS.

so we have not got long to wait.

Flash Builder is based on Eclipse. The IDE is slow at times, for example when switching to visual design mode, but the platform is familiar to many developers and it feels reassuringly enterprise-ready. I find it a productive environment.

I laid out a screen with buttons and a label to display the output. The alignment tools work well although I made them a little too small as you will see shortly. Then I started writing code. The language of Flash Builder is ActionScript, which is based on JavaScript.

Here I met my first little annoyance. You can easily create a click handler for a button by right-clicking in the designer and choosing Generate Click Handler, or by clicking Generate Event Handler in the properties window. However, I thought it would be smart for most of my buttons to share the same event handler. All I need to do is to read the label of the button which was clicked, and pass it to my addnum routine that processes the input:

protected function btn_clickHandler(event:MouseEvent):void
{
    var theButton:Button = Button(event.currentTarget);
    addnum(theButton.label);
}

This works fine, but the IDE does not let you select an existing event handler for a button. You can paste it in, or add in in the source code editor, which is what I ended up doing. The source code editor is rather good, with excellent code completion, hover-over help for keywords, and so on.

image

The second annoyance was with the label. I wanted to add a border. I selected the label but could not see a border property. I went to the full list of properties and found exotic things like dominantBaseline in the style list but still no border.

Then I found this in the reference for a label:

Borders are not supported. If you need a border, or a more complicated background, use a separate graphic element, such as a Rect, behind the Label.

I wondered if a panel would work, and started to type it in the editor:

image

Well, it looks as if Panel is overkill for simply getting a border, but it was interesting to see the editor report that “Adobe discourages using Panel when targeting profiles: mobileDevice”. I decided to do without a border for the moment.

I finished the coding and successfully ran the project in the Android simulator. Next, I attached a device and created a new Run Configuration for a device attached via USB. I plugged in my HTC Desire running Android 2.2. Provided USB debugging is enabled on the device, this works well. Not only could I run on the device; I could also set a breakpoint and debug on the device. Everything was a bit slow in debug mode but it worked.

image

Finally, I built a release version using Export Release Build on the Project menu. You have to sign the package, but there is a wizard to create a certificate for testing.

Here it is on the device – as I mentioned, the size of the buttons needs a little work:

image

So how is performance, bearing in mind that the app is trivial. Well, the good news is that performance is OK, though launch is a little slow, except for one thing that I have not figured out. Sometimes I touch a button, and see the graphic effect as the button depresses, but the input does not register. It seems most prone to this just after launching, and usually a second tap works fine.

The vsize reported for the app process by the Dalvik Debug Monitor is around 200K, similar to that for the PhoneGap version.

Overall I am impressed, though I would like to understand the button issue, and I am beginning to wonder if my year-old HTC Desire is a bit under-powered for AIR. Device performance is improving rapidly, and Flash optimization is part of the design process for mobile graphics chips, so my guess is that AIR will be more than viable as a cross-platform toolkit for mobile. You also get the benefit of all those lovely Adobe design tools.

Developers and mobile platforms: lies, damn lies and surveys

I’ve been reading the IDC/Appcelerator developer survey about their attitudes to mobile platforms. The survey covered 2,760 Appcelerator Titanium developers between April 11-13, so it is certainly current and with a sample just about big enough to be interesting.

The survey asks developers if they are “very interested” in developing for specific platforms, with the following results, and with comparisons to 3 months ago:

  • 91% iPhone (fractionally down)
  • 86% iPad (fractionally down)
  • 85% Android phones (down from 87%)
  • 71% Android tablets (down from 74%)
  • 29% Windows Phone 7 (down from 36%)
  • 27% Blackberry phones (down from 38%)

The survey is titled:

Apple shines, Google slows, and Microsoft edges RIM in battle for mobile developer mindshare.

Is that a fair summary? It is not what I would highlight. I cannot read the exact figures from the chunky graphic, but it is clear that the iOS figures are also fractionally down, maybe by just 1%, but hardly much different from the Android figures on a sample of this size. Both are pretty much flat.

The figures for Windows Phone 7 and Blackberry are more dramatic; though we should at least note that Appcelerator Titanium is a cross-platform toolkit that does not currently support Windows Phone 7, and that its support for Blackberry is only in preview. That was true last time round as well, but I’m not sure that asking developers about their plans for a platform which the toolkit does not currently support is the best way to gauge overall interest.

Another question that interests me: is developer interest a cause or an effect of a mobile platform’s success? A bit of each, no doubt; but personally I think the “effect” model is stronger than the “cause” model. Developers pick a platform either because they have immediate customers for apps on that platform, or because they think they can make money from it.

Nurturing a strong developer community is definitely important for a platform provider; but I doubt it ranks as highly as other factors, like building a strong retail presence, delivering excellent devices at the right price, and focusing on usability and a good end-user experience.

If you are interested in Appcelerator Titanium you might like to read my interview with the CEO at Mobile World Congress; and this discussion on whether Titanium really builds native apps.

RIM’s new BlackBerry tablet, WebWorks developer platform – but who wants small tablets?

Blackberry has announced its pitch for the emerging tablet market, the 7” screen PlayBook. It has a new OS base on QNX Neutrino, a webkit-based web browser, Adobe Flash and AIR – offline Flash applications – front and rear cameras for video conferencing as well as taking snaps, and includes a USB port and HDMI out. There is wi-fi and Bluetooth but no 3G in the first release; you can connect to the Internet via your Blackberry. Storage is not yet specified as far as I can tell. There is no physical keyboard, which is surprising in some ways as the keyboard is the reason I hear most often for users choosing a BlackBerry smartphone over Apple’s iPhone.

image

Alongside the PlayBook RIM has announced a new developer platform. WebWorks is an HTML5 platform extended with access to local APIs, and targets both the Tablet OS and BlackBerry smartphones:

BlackBerry WebWorks applications can tap into the always-on, notification-based, push-enabled, contextual and social attributes of the BlackBerry smartphone. These applications can also access hardware features and integrate with other apps, and are powerful Super Apps that are fully integrated into the BlackBerry Application Platform.

In order to access local resources you need to package your app as a Blackberry application. Java and native C applications are also supported.

A winner? Well, there is a widespread industry presumption that we all want tablets; for example NVIDIA CEO Jen-Hsun Huang is planning on this basis, judging by what he said to the press last week. It is certainly a market in which every vendor wants a presence. There are a number of open questions though. The new tablet market is really defined by Apple’s iPad, and success for other operating systems and form factors is yet to be demonstrated. Personally I am not sure about the 7-inch screen, which is perhaps too large for a pocket and too small for the desktop-like web browsing you can do on an iPad. Here are the dimensions:

  • BlackBerry PlayBook:  7-inch 1024×600 screen,130mm x 193mm x 10mm
  • Apple iPad: 9.7-inch 1024×768 screen, 189.7mm x 242.8mm x 13.4mm

I doubt there will be much enthusiasm for carting around a phone, a small tablet, and a laptop, so in order to be viable as a portable device for work it has to be a laptop replacement. I do see this happening already with the iPad, though for me personally a netbook is both cheaper and more practical.

Apps are another key factor. It is smart of RIM to support Flash and AIR, which along with HTML 5 web applications are likely the best bet for supporting something like the PlayBook without a lot of device-specific work.

HP will not do Android or Windows Phone 7 smartphones – but what chance for webOS?

HP’s Todd Bradley, Executive Vice President of Personal Systems and formerly CEO of Palm, was interviewed by Jon Fortt at CNBC. Fortt asks some great questions which mostly get woolly answers, but did get this statement from Bradley:

We will not do a Linux, Android phone. We won’t do a Microsoft Phone … we’ll deliver webOS phones.

I will be interested to see if HP sticks to this commitment. HP is Microsoft’s biggest customer and huge in business systems, but that does not necessarily mean it can make a success of a mobile platform on its own.

Mobile platforms stand (or fall) on several pillars: hardware, software, mobile operator partners, and apps. Apple is powering ahead with all of these. Google Android is as well, and has become the obvious choice for vendors (other than HP) who want to ride the wave of a successful platform. Windows Phone 7 faces obvious challenges, but at least in theory Microsoft can make it work though integration with Windows and by offering developers a familiar set of tools, as I’ve noted here.

RIM Blackberry is well entrenched in the Enterprise and succeeds by focusing on messaging and doing it well. Nokia and Intel will jostle for position with MeeGo.

It is obvious that not all these platforms can succeed. If we accept that Apple and Android will occupy the top two rungs of the ladder when it comes to attracting app developers, that means HP webOS cannot do better than third; and I’d speculate that it will be some way lower down than that.

You have to feel for HP, which has supported Microsoft’s failing mobile platform for many years – with the occasional lapse, remember when it became an OEM vendor for Apple’s iPods? – and now has decided it cannot rely on the company in this area. That is understandable. However, HP is heavily invested in Windows. It may be choosing just the wrong moment to abandon ship; or it may find that doing its own thing with webOS is no better. Google Android would have been a safer though less interesting choice.

Android the new Windows?

I’ve just reviewed the LG GW620 Android phone. I was impressed by its features but disappointed by its usability – it’s not that bad, but scrolling web pages accurately with touch I found almost impossible – it’s hard to avoid scrolling too far and missing out a chunk – and why does LG supply the device with four different email clients?

Apple’s iPhone is much more expensive and compares badly on features, but has the usability and polish that the LG phone lacks.

OEM Android versus Apple iPhone – it reminds me of Windows vs Apple on the desktop.

One is for the mass market, cheap, feature-rich, a bit chaotic, always a few annoyances, but you put up with them because you can still get things done, and it’s an open platform which lets you do what you like.

The other is premium-cost, single-vendor, less annoying, and you spend more time getting on with what you want to do and less time fighting the machine.

I don’t intend this as a  complete parallel. There are more than two popular operating systems in the SmartPhone market right now – Symbian, Meego, WebOS, Blackberry; and Microsoft has big hopes for Windows Phone 7. That said, it is hard to see all these platforms thriving long-term.