C# on BB10

I recently managed to get a C# application running on a BB10 device, using a port of the mono interpreter – monoberry (https://github.com/roblillack/monoberry). The process was a little painful, mainly due to a lack of documentation, so I thought I’d walk people through the process.

I started from a virgin build of Ubuntu 12.04 – below are the steps I followed…


Prior to installing monoberry, you need to download and install the BB10 NDK. By default, this will install into /opt/bbndk/

A number of packages are required for the install. After a little trial and error, the below is, I think, sufficient.

$ sudo apt-get install autoconf automake libtool git mono-complete gettext openjdk-7-jre g++ libglib2.0-dev libfontconfig1-dev

Building monoberry

Monoberry is stored on github, and can be downloaded and installed as follows. Note that a number of other libraries are downloaded, via .gitmodules, including a fork of mono – I’m not sure how out of date this fork may be.

$ git clone git://github.com/roblillack/monoberry.git
$ cd monoberry
$ make 
$ sudo make install

Configuring monoberry

You need to setup the rc file (~/.monoberryrc) and copy the debug token bar file.

1) RC file
The init file should be created as ~/.monoberryrc. This is made up of two parts, a [core] sections and a list of [device.xxx] sections. These are documented here: http://burningsoda.com/software/monoberry/

For reference, below is my file with a little obfuscation. I have a simulator (sim) and Dev Alpha (dev):-

author_name = ABCDEF
nativesdk = /opt/bbndk/
debug_token = /home/ian/.monoberry/debugtoken.bar

arch = armle-v7
ip =
password = devicepassword
pin = 1234FFFE

arch = x86
ip = 
password = devicepassword
pin = 1234ffff

2) Debug token
In order to do the majority of interactions with devices, using monoberry (wrapping some NDK tools), a debug token needs to be installed. The method I used was as follows – this is not necessarily optimal, but it worked.

Firstly, follow the standard RIM instructions to install the PBDT and RDK files from RIM, and turn them into signing keys, inside the Momentics QNX IDE. Then, within the IDE, go to Window->Preferences->BlackBerry->Signing and click on the debug token you want. If one isn’t present, follow the RIM instructions to create a debug token and deploy it to the devices. Click on “Details” and copy the Author and Author Id fields into the above monoberryrc file.

Next, go to the path given for that debugtoken.bar file, and copy it into the path/location given in the monoberryrc file. If you’ll want to sign files in the future, copy the Author.p12 file (the location can be found in the above Preferences panel) to ~/.rim/author.p12.

Building your first app

The sample apps have .csproj files, rather than makefiles. These can be built using either monodevelop or xbuild. To build:-

$ xbuild paint.csproj /p:Configuration=Release

If you get errors, especially if they’re related to missing references, it’s probably because there’s either a path issue or a missing reference. To fix, I recommend opening the .csproj in monodevelop, and fixing the references. The most likely contender here is a missing libblackberry.dll – right click on References, select Edit References, then browse to the dll and add it.

Deploying the app

To run the app on a target device:-

$ cd APPNAME/bin/Release/
$ monoberry debug APPNAME.exe DEVICE
  [where APPNAME is the name of the built .exe, and DEVICE is the device/sim to run on]

The exe will get packaged into a bar, and uploaded. You should see a “result::success” following by a “Sending Request: Launch” and a couple more steps.

If you see:-

  • result::failure 881: application author does not match debug token author: Most likely the author_name in ~/.monoberryrc doesn’t match that in the debug token (unzip the debug token, and look in the META-INF/MANIFEST.MF file for the line Package-Author: )
  • Other errors involving the debug_token – check that the same debug token is on the device as ~/.monoberry/debugtoken.bar and that the Package-Author in the bar = author_name in the rc, and that Package-Author-Id = author_id.

Additionally/alternately, you can create the .bar file yourself and upload it. This is performed with the following command:-

$ cd APPNAME/bin/Release/
$ monoberry package APPNAME.exe

In addition to packaging the .exe and dependencies into a .bar file, this command will also create a simple app-descriptor.xml file (aka the bar descriptor file – more info here). I think you can edit this file if desired, and it will be used if you reissude the package command.

Extending the (limited) API

Currently, monoberry only supports a tiny subset of the available NDK APIs:- Button, Camera, Dialog, Event, Navigator, Platform Services, and a subset of Screen. However, this doesn’t limit your access to the NDK APIs, just makes them a little harder to access.

The NDK is comprised of header files, and libraries. By reviewing the header files, and the online documentation at http://developer.blackberry.com/native/reference/bb10/library_support_at_a_glance.html you can see what functions etc are available and what their prototypes are. You can then use P/Invoke to call native code in the DLLs. You then have the option to either: a) directly access the NDK APIs, or b) wrap them into a cleaner C# class, and then access via that. I recommend the latter approach. It is cleaner, and you have the option to add the code to the monoberry libblackberry.

For an example of this, please see: https://github.com/roblillack/monoberry/blob/master/libblackberry/dialog/Dialog.cs


In summary, following the above instructions it is relatively trivial to setup a C# build and deployment process for BlackBerry 10 (and, I would imagine, BB PlayBook). Currently there is very limited support for NDK libraries, however there is hope that this will expand as a) the project is still under active development, and b) it’s relatively easy to wrap the libraries with P/Invoke as needed.

There are still a number of questions outstanding though – the key one being ease of debugging. NDK debugging is normally handled via GDB, however this won’t work with an interpreted environment like this. Non-UI and non-BB10-specific components will be able to be run and debugged in native (i.e. Linux/Windows/Mac) environments with IDEs, but when the app is deployed on a device life will get much harder. This is currently an open question, and one to keep an eye on. Options include use of the Console, together with blackberry-connect and ssh, to log text output, but for those of us used to easy debugging using an integrated IDE, development in C# for BB10 will be a shock.

Still, a useful beginning, and I wish the project the best – I know I will be using it for my cross-platform development.

Update 30/1/2013

It turns out, I may have been too pessimistic about debugging. Mono comes with remote debugging support, and using the soft debugger I think I can debug live on the BB10 device. Even better, I can do it from Visual Studio! For info on the mono debugger, see: http://www.mono-project.com/Debugger and for info on debugging from VS there’s http://mono-tools.com/Debug.aspx I’ll update this post when I get a chance to try it out.


Flash media server

I’m a bit of a geek, so I have lots of mobile gadgets. I’m also into Movies and (good) TV shows. I have archived many of my DVDs at home onto a server, so I have a lurvely home cinema setup throughout my flat. The only problem is that I want to watch these movies on my aforementioned gadgets.

Now option 1 is to copy the files over whenever I want them. Unfortunately I never quite know what I’ll want to watch, and I can’t carry all several TB around with me…

For some files I can just browse (via my shiny new VPN) to an Apache service and download/stream them off that. But what about the high quality DVD backups? And I recently moved to mkv as a container, and most mobile toys can’t handle .mkv files. Flash is a nice standardised (well, nice may not quite be the word…) protocol/media format. One option would be to transcode all the files. But that’s just stupid. In order to stream on my 1.5MBps up pipe I’m going to have to transcode the quality down a fair bit, and I don’t want to either lose all my nice high quality files nor have 2 copies of every file.

What I really needed was something which would stream, and transcode on the fly. Unfortunately such a thing didn’t exist, for free, anyway.

But fortunately, as previously stated, I am a geek. And a geek on holiday…

So, I have written FlashServer. The language of choice is C# as that way I get help from .Net for a load of things, and as I’m going to be throwing around a load of strings, I can’t be bothered with C++. Plus, with Mono I can develop on Windows and run on both Windows and Linux – useful as my linux server doesn’t have X…

The result: after around 24 hours of work, I now have a working web server, which allows me to browse specified ‘shares’, and stream movies off them – movies which are transcoded into flash on the fly. Performance seems sufficient for my 1-2 user use-case. There’s no rate limiting, so streaming it will use up a lot of the ‘up’ bandwidth – I may add that at a future date as it will be easy enough. Transcoding is done by ffmpeg, with specific settings set either via a couple of hard-coded profiles, or able to be chosen at start time. There’s no fast-forward or rewind, although you can start your playback from an arbitrary location.

The source is available for download (in MS VS Express 2010 solution format) from here. Note that you will need Inno Setup in order to use the installer (and will need to change paths etc).

Windows users, feel free to try the installer. FFMPEG is bundled with it in exe form. You’ll still want to tweak the conf file before use though. Note that .Net Framework 4.0 is used – install it from: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9cfb2d51-5ff4-4491-b0e5-b386f32c0992&displaylang=en

For linux users, and those who don’t want to use the installer, a zip is available. This contains the .exe, a readme, and a sample config file. Please read the README, as you’ll need to point to your installation of ffmpeg. Terrifyingly, the program worked first time with mono, so something will undoubtedly go cataclysmically wrong at some point…

Please let me know (by a comment below, or email: flashserver at ianpeters.net) if you use this, and if you have any feature requests!

Those links again: