Working with BlackBerry Cascade (1) - viewpoints from Nokia burning platforms

As mentioned in another article, I ported one of my apps to BlackBerry 10. In retrospect, I could have done this a lot sooner. But three months ago, the dev tool and documentation were not as mature as now so maybe that also hampered my progress.

I came from the burning platform that is Nokia. So my app was pure Qt/QML with heavy use of Qt components for UI. If you are of the same background, I hope my experience in porting to BB10 might be helpful to you.

First of all, you need to decide upfront which development environment you want to use:BlackBerry's

• Cascade: You need to use BlackBerry Native SDK.
• Pure Qt/QML: Use QtCreator 2.6+, all you need to know about making QtCreator 2.6+ works with BlackBerry 10 is at http://qt-project.org/wiki/blackberry.
  (I believe you can also use BB native SDK for pure QML now, but never tried that route.)

There are different issues for the two approaches, in my case they are:

• Cascade: Learning Cascade, rewrite UI, more #ifdef in C++ for blackberry specific codes 
• Pure Qt/QML:
• I couldn't get QML Text component to use the text style I wanted.
• Have to work around the lack of native BB10 Qt components, either by compiling Qt components for BB10 (there are pre-compiled libraries available on BlackBerry developer forum, but I never succeeded in using them. Nor have I been able to compile them from source), or by re-implementing the UI elements (which was not feasible for me....).

Whichever route you choose, you need to registered for code signing keys. I will skip the step since you can easily find reference on it. For pure Qt/QML, QtCreator 2.6 is good enough and if not for the font issue I encountered I might choose that. I ended up working with Cascade, and one thing I learned about Cascade was I felt the QML part was at times an afterthought. QML is kind of like an wrapper, but it is even more so in Cascade. Instead of thinking that you are working in javascript, think of using Cascade QML as if you are working in an "virtual machine" encapsulated in Qt C++. One powerful thing I learned is, the "attachedObjects" property is the bridge to expose Qt C++ objects directly into QML [1]. So instead of searching for QML elements to use in... well QML, you search for Qt C++ class to plug into attachedObjects scope. Or you can extend a class in C++ then register it into QML. The concept is different for me, and after stop thinking "why did BlackBerry implement like this," I started getting better progress.

Between beta and gold SDK, BlackBerry has added a few very useful elements in C++. This means that Qt elements such as QueryDialog{}, Sheet{} etc. have comparable elements in Cascade, just that you need to instantiate them in attachedObjects scope, not elsewhere. Gold SDK also simplified list manipulation and now header/data are just a string definition apart. Speaking of list manipulation, Cascade has separate DataAccess/DataSource class to populate list. In theory they are convenient but in reality, I found the lack of callback functions can limit their usefulness, e.g. if the data fetched is decorated with // for comment the DataSource ignores the data. Also Cascade uses indexPath, a QVariantList to specify the hierarchy within the list, and this can be confusing when you have headers. Cascade list provides more complex use cases, for example it offers context menu. One problem you will immediately find is that context menu seems to be isolated in its own scope and cannot access anything above it if you use "id.function()" syntax. There is a solution [2], and I found that context menu does have access to ListItemData property [3]. All API document can be conveniently found at [3], and a few useful UI component tutorials are at [4][5][6]. If you encounter any problem, first search BlackBerry developer forum. It is full of information and people there are willing to help.

Last but not least, there are free in-app icons available for BB10, courtesy of Myers Design [7]. I remember reading there is another one, but Myers' icons are awesome for me so I didn't search further.

Hope the above info is helpful. If you have questions, don't hesitate to leave a comment! Happy coding!

Reference

[1] "Cascade QML C++ Integration", https://developer.blackberry.com/cascades/documentation/dev/integrating_cpp_qml/index.html

[2] "ContextActions inside ListItem can not access ContextProperty in QMLDocument" 

http://supportforums.blackberry.com/t5/Cascades-Development/ContextActions-inside-ListItem-can-not-access-ContextProperty-in/m-p/1870985#M2383

[3] "Cascade API documentation"

https://developer.blackberry.com/cascades/reference/

[4] "Cascade System Dialogs"

https://developer.blackberry.com/cascades/documentation/ui/dialogs_toasts/sysdialogs.html

[5] "Cascade Sample Apps"

https://developer.blackberry.com/cascades/sampleapps/

[6] "List Manipulation"

https://developer.blackberry.com/cascades/documentation/ui/lists/

[7] "Free BB10 in-app icons"

http://myersdesign.com/resources/

Ported BabyTime to BB10!

The release of gold BlackBerry native SDK really helped me get up to speed with Cascade development. And I finally ported my simpler app, BabyTime, to BlackBerry 10. Hurray!

Before that, I was struggling with Cascade development. Mainly it was the debugging, I forget why but I had a difficult time figuring out why the Cascade QML interface did not work. At one point I even gave up on Cascade and looked into pure Qt/QML approach. The problem with that was, I had to re-implement Qt components... and also for reasons I never figured out, the font style could not be changed for QML Text element. That was the final straw for Qt/QML and I went back to Cascade.

This was also the time when I tried revisiting the alpha device simulator. Again I forget the reason why I didn't use device simulator in the first place, but I didn't have any issue with gold SDK device simulator. To me that was the key turning point because it is faster to debug and experiment with UI layouts. Another key is I worked on BabyTime instead of Stockona. BabyTime is my second proper Qt app, and with the experience I complete separated the UI and the SQL backend to QML and Qt C++. This helped immensely because I could focus on re-implementing the UI in Cascade. The C++ SQL backend needed some changes because of the API differences between Qt AbstractModel and Cascade GroupDataModel. Even that was relatively minor, and this experience really makes me a believer of pure Qt C++ backend. 

My experience so far tells me to minimize code changes between Meego/Symbian and BB10, unsurprisingly, is to put database, network and list manipulation in Qt C++. More info about the porting experience will be documented in another article.

Blackberry 10 Alpha simulator black screen/not working?

I have been trying to install BB's IDE to try out Cascade but couldn't get simulator to work until today. Dumb me... because I found out I used wrong VMPlayer version. BB already stated VMPlayer 5.0 didn't work with simulator beta2, and by using VMPlayer 4.x the simulator ran fine.

While I googled for solutions, I saw some VMPlayer setting suggestions and figured I might as well document them below:

1. Make sure set memory to at least 1G, hard disk to 8G.
2. Set CPU to dual-core if your system has multiple cores.
3. Enable 3D acceleration.

What's next?

It has been well-over a year since the last post and a lot have changed.

Stockona lives on to expand to cover Symbian as well, and is now a lot more mature than it was a year ago. But the natural question for me (and I guess for every Qt developers) is, where should I go next?

At the start of 2012, it looked very much like Nokia's Meltemi and BlackBerry were two viable options. Then Meltemi got canceled when it was in last stage of development. BB also looked shaky and didn't guarantee longer-term platform stability. (At that time rumors flied that BB might consider WP8 as well.) The first half of the year really looked dark in terms of Qt mobile development. All of a sudden, Jolla appeared out of nowhere and the Mer/Nemo Mobile initiative suddenly made a lot of sense. Blackberry also reaffirmed their determination to weather through the launch of BB10 and here we are, waiting for both companies to launch their first Qt phones.

The Jolla story has been vague for now, they said very little except existing Harmattan app will almost instant work on Jolla devices. My guess is that Jolla will have their own Qt components so developers only need to change the import and re-compile. This sounds like music but the problem for Jolla is of course they have to gain market share from zero.

At this point, BB10 seems to be a better bet. It has a large user base and I think many current iPhone/Android users have owned Blackberry at one time. With major operators offering the devices, I think BB10 will be reasonably successful. The one problem I see with BB10 the UI might be too abstract and complicated that more novice users (iPhone users...) will have a steep initial learning curve getting used to the wide array of gestures and different menus/toolbars in the UX.

Development-wise, BB10 has its own IDE and seems like BB only intends to provide some of the Qt components (e.g. Dialog, sheet) but not the full suite of Qt components in their own version. It is a shame, because I think Qt component is such a good initiative to ease UI development for individual developers. I started learning BB10's Cascade and so far it looks like the porting is reasonably doable. The pagestack navigation concept is almost equivalent to Cascade's navigation panel. Many Harmattan Qt component have equivalent ones in Cascade. One useful component that is missing is the SelectionDialog, but I won't complain about such minor issue. The real pain for me is to use BB10 IDE. The interface is plain ugly. The BB10 simulator just doesn't work for me and without a simulator I cannot test UI and see how to customize BB10 UI concept to fit into Stockona's need. The situation is similar to when I started working on Harmattan version, just that at least QtSDK has Qt Designer to at least see UI mockup. I am attending next week's Blackberry Jam developer conference, and hope I got the answer and also got an Alpha device to work on.

In summary, I guess my plan is as simple as wherever Qt goes and I go....

Porting to Harmattan (3)

Some time ago, I decided that the only feasible way for Stockona to run well on Meego Harmattan was to re-work the UI using Qt components. The main reason was window focus issue that's very annoying to me. For whatever reason, the VKB in Harmattan doesn't work well with pure QML TextInput element. The focus becomes sticky once VKB is shown. I have tried to fill the un-used area on screen with MouseArea element to make de-focusing works like how it should be, but then sometimes when I switched in/out of task manager, the VKB popped up for no reason. I gave up debugging this and step-by-step changed the UI to Qt component. I was unsure if it would be worthwhile doing so, but in the end I think it was a correct decision. Qt component works great, and takes care of the UI design work so I have more time fixing some of the logic bugs instead of trying to put together graphic elements like what I did on Fremantle. I found the Sheet and Dialog (QueryDialog to be specific) elements to be especially handy for taking user inputs and displaying information to users.

The only disadvantage using Qt component is of course the portability becomes an issue for other platforms. Now I have been focusing on the Harmattan version and made several releases, the code base has become quite different to Fremantle's version in several areas. I am kind of lazy to merge the changes back and seriously hope the community project to make Qt component available on Fremantle will be working soon.

Porting to Harmattan (2)

To recap, the issues I had earlier were:
1) VKB stays visible once launched.
2) App stays in landscape mode.
3) After a few launches, an empty toolbar showed up along the bottom of the screen and stayed there afterwards.

For (3), I found out it was due to setting the QDeclarativeView to showMaximized() instead of showFullScreen().

For (1), I couldn't figure out why TextInput element is not working probably. I tried changing to manually handling the focus, but still saw the same issue happening. In the end, I decided to apply a dirty trick. I simply set closeSoftwareInputPanel () method of TextInput elements when user clicks outside the TextInput fields, and further calling the method again when exiting the setting menu. Even with this ugly patch, flicking action on Stockona still sometimes invokes the VKB for no reasons.... again, the root cause is a mystery to me for now.

For (2), I have tried wrapping the QML into Qt components. At first, I tried wrapping my main QML page into a Page element, then push it into PageStackWindow. For whatever reasons, it didn't work. I then found out about the Window element. The documentation says it can wrap any QtObject and although the doc suggests not to use it directly, I found it worked for me.

The last thing I did today was changing the control button height so it's easier to click on them instead of clicking to the symbol list below.

At the end of the day, I made some progress but I am unhappy that I have little idea about the root causes of the various issues. Hopefully the community will figure out some commonly-good practices when using Qt components, and also the Qt documentation for Nokia's Qt components will improve with time.


PS - One thing worth noting is I found out it was super easy to set up N950 to connect to QtSDK by WLAN. Just fire the "SDK connection tool," then enter all the information in QtSDK and the deployment to device just works afterall. It greatly sped up the development time! (N900 probably supports this as well, but I remember you need to install some MADDE-related packages... I'm glad those packages are built into N950 by default.)