Sunday, February 10, 2013

Geek'ish application development for Blackberry 10

Hi there again,

As indicated in my previous post, I am now about to summarize my developer experience for the platform Blackberry 10. As written before, the regular way of developing applications for this platform is to use the Momentics IDE or QtCreator.

Those environment usually generate the necessary qmake build system files, bar files for you to a certain extent I guess. Admittedly, I have never used them for this purpose, so this is just a gut feeling. Anyway, this is not so important for the scope of this post.

Goal

When I had started to develop my first application, I made some research if it had ben possible to develop applications the way I like: command line and cmake. For those of you, who are not familiar with cmake, it is a nice cross-platform Makefile generator thoroughly used in many projects. One open source reference is KDE for this.

Interestingly enough, I got some messages in private after my cmake based projects that people found those files and used in a similar fashion one by one. This is nice, but some explanation is necessary for newcomers. So, let us dig into more details about this.

CMake Toolchain file

In order to make cross-platform development with cmake, usually one has to produce a correct toolchain file. I looked around on the internet, and there was some examples available for QNX. I took one of those essentially to start off with. That is also one reason why it is a bit bloated, and a much simpler would be enough for achieving what we wish to.

If you are not interested in the underlying operation, you can skip the explanation below, and you can just use my toolchain file right away.

The important changes I made were the followings:

Use the proper toolchain binary

Use the 'qcc' build wrapper. It is essentially a wrapper around the compiler, linker, and so forth. You can find more complete documentation about it here.

This is a very important change because I started with the "ntoarmv7-g++" which is a link to the "arm-unknown-nto-qnx8.0.0eabi-g++-4.6.3" toolchain file. I also tried the latter directly, but I encountered crash for my applications even for a very simple test case without cmake. The program crashed even before entering the main function. It took me two nights at least to track the problem down.

Use the proper toolchain binary flags

Once I figured out I would have to use 'qcc', there were still some problems that I encountered, albeit slightly different. I had to realize the usage of certain flags is necessary. Once I made it work with the proper flags without any build system, I had to figure out the proper way of setting that for the toolchain file. Now, we have all the information necessary so here it goes the statement:

-> SET(CMAKE_CXX_COMPILER_ARG1 "-Vgcc_ntoarmv7le -lang-c++)

Instruct cmake to use the toolchain file created

-> -DCMAKE_TOOLCHAIN_FILE=/path/to/the/toolchain/file.cmake

The location of the toolchain file

This is only my personal opinion, but I found it simpler to put the toolchain file into the project because then I did not have to carry that on to other machines I worked on. It is also simpler to ask other non-cmake developers to test my application if I pass a command to them.It is not a huge file, so it probably does not take up much space in the repository either. It does not clutter the project that much either in my opinion.

Find modules for Cascades libraries

This is also a very important step to find the Cascades libraries for your application. This was not a big deal, albeit I have not had time to solve this issue nicely either. So, there are rooms for improvements. :)

I have created separate cmake find modules for each library for the time being, but perhaps it should be handled more like Qt4 with a joint find module, and one can request anything out of that. So, there would be a macro with a few parameters. It would not be then necessary to copy and paste the code. If you are not up to that contribution, you probably better go with the files I created. You can find them below.

Deploying the application to the device

I wrote a primitive python script for this after gathering all the information what flags to use. Here you can the result. This one is more or less just a hint as it cannot be used that directly. I chose python because then I can also use this on Windows and elsewhere as python is a nice cross-platform scripting language.

Essentially, there are several tools that have to be used for installing and then launching the application on the device from your host system:

Set up the Blackberry NDK environment

I personally made an alias for this, but here you can find the comment:

-> source /opt/bbndk/bbndk-env.sh

blackberry-connect

I have not tried to develop over Wi-Fi because I use mobile internet, so that was not an option. I also prefer the usb link as it is faster and more reliable. I made aliases for these, too. You have to supply a proper public ssh file. I think the default length is not proper, but a new one can be generated easily. Here you can find the command for setting this all up:

Debugging from command line

A simple ssh connection can be used for logging into the device once the development mode is switched on in the settings. It has to be done after each boot as of now on my devalpha, at least. Make sure the connection is established properly and the blackberry-connect process is still up. Here you can find the command for that: -> ssh -i ~/.ssh/id_rsa_rim devuser@169.254.0.1Once this is done, there are some tricks to get information about QML syntax issues, C++ crashes, reading your intended log file, and so forth: -> slog2info -w

Application signing for AppWorld

Note: Do not forget that you have to increase the -buildId value for each new signing.

Testing someone else's application

This is also a common request that someone would like to get feedback about the application before even getting approved in the AppWorld. In such cases, you may request your friends and acquaintances to test it. This could also happen vice versa so that you are asked for testing an application and provide feedback. Hence, it is useful to know how you can do that. Here is the command I used.

Conclusion

Like many things in the life, this is also possible. I do not find any issues with this workflow for application development, but I am a bit strange developer. I am glad to have found the way I like spending my time. Many thanks go to Bill Hoffman from Kitware for patiently helping me with cmake issues on the cmake mailing list.

Hey Laszlo, thanks so much for this article. I've been developing for BB10 for nearly a year using Momentics (eclipse... yuck) and have played a bit with QtCreator to see if it might be suitable for my next app.

At this point though I'm about to try to compile QtGStreamer into a BB10 library. The QtGStreamer makefile is designed for cmake, not the qmake tool that installs with Momentics. I've been developing with IDEs for over twenty years and haven't needed to mess with makefiles and make tools since probably the mid-80's, so while I'm not clueless about make tools I'm pretty seriously out of practice.

I'm assuming (perhaps wrongly) that I can just install a Windows version of cmake and use it to build QtGStreamer binaries. I'm sure you know that while BB10 devices are ARM based, the BB10 Simulators are x86, so any solution I settle on must build for both processors.

I'm wondering if you have any thoughts or suggestions for me as I start this?