My life has changed upside down recently: I have been accepted to Saarland University Graduate School and I will move to Germany soon. I will try to keep this updated as possible.

Well, a short break on continuous integration posts!

Continuous Integration is such a great idea: it works as a trainee that constantly downloads/builds/tests/deploys you application and notifies you whether something goes wrong or nice. I really do believe that (of course, besides several other advantages) it improves the project overall quality and also helps you to keep the application ready to be reviewed by a stakeholder.

If you are still skeptical about it, please take a look that this marvelous post here [Martin Fowler] .

Let´s discuss how you can set up a environment for a more complex project. So, unfortunately, this is tutorial for beginners (for basic/how-to-install-and-run instructions, check it on internet).

Introduction

The system consists of one server located in a external environment (for example, AWS services) and several mobile clients (iOS, Android and QT clients). Basically, the mobile applications fetch content/data from the server.

We need to constantly build/deploy the server and build all mobile clients. One very interesting point in this scenario is the amount of platforms: iOS (to build iOS client), Linux (to build Android/QT client - I´d rather use Linux for Android projects) and Windows (to build the server).

Besides svn checking-out + building + testing + deployment, we will also use QA solutions, such as Sonar and some static analysis tools for different platforms.

We will use Jenkins as CI server.

Proposed design


As I said, the system consists of several components: mobile clients (iOS, Qt and Android) and also servers. In this case, I´d rather use master-slave approach. You can create one slave for each mobile platform and also another one for for servers. To the given example, the solution is defined as it follows:


You might ask me why this is too complicated! But believe on me. If you have complex systems to build, this approach works a lot better: it´s easier to organize and to maintain, and each component on its own environment. In my next post, I describe how we set up all of this :-)

After a loooong break, I am back to this. I have to confess that I had had several new/cool stuff during this pause: new projects, mind-blowing findings, exciting/stressful experiences, lovely/irritating people. And all of this had consumed a lot of my free time. I am not saying that I hadn´t had time at all: I had done some new/different things with such slots of time than only writing about technical stuff.

Well, but anyway, let´s keep track of new stuff. The main reason to start blogging again was the simply fact that I am not used to describe all solutions for tricky problems in general: how to cross-compile certain applications for ARM devices, how to set up a smart CI environment, and so forth. I swear I have tried it really hard, but my evil side always tells to myself: "if you need it some other day, you will remember it". So, this is also a kind of "Raul´s Recipes Book".

I am really convinced that it will work :-)

As part of my next posts, I will describe a bit more about how lovely is a CI environment for a relative huge project (of course, how you can set up all of this and put the pieces together). Specially, when it has such different clients, such as iOS, Android and QT applications.

This tutorial is designed for those ones that need DBus but suffer a lot to find documentation even about simple things, such as how to pass a dictionary as parameter.

Initially, I had to invoke a Bluez method that needs a dictionary as parameter. But how could I do it? It not easy at all to find a detailed documentation about it and I had to look for a solution at BlueZ source code.

In this case, I'm using the newest BlueZ Health API (support for HDP/MCAP). The following piece of code shows

static char *start_health_session(DBusConnection *conn)
{

  DBusMessage *msg, *reply;
  DBusMessageIter args;
  DBusError err;
  const char *reply_path;
  char *path;

  msg = dbus_message_new_method_call("org.bluez", 
                                     "/org/bluez", 
                                     "org.bluez.HealthManager",
                                     "CreateApplication");

  if (!msg) {
      printf(" network:dbus Can't allocate new method call\n");
      return NULL;
  }

  // append arguments

  dbus_message_iter_init_append(msg, &args);

  if ( !iter_append_dictionary(&args, DATA_TYPE_VALUE, 
                                          ROLE_VALUE,
                                          DESCRIPTION_VALUE, 
                                          CHANNEL_TYPE_VALUE) ) {
      printf(" network:dbus Can't append parameters\n");
      dbus_message_unref(msg);
      return NULL;
  }

  dbus_error_init(&err);

....
}

A DBus dict type needs a message iterator, which is properly initialised before it is used.

Once the message iterator is properly created, let's open it and add tuples to it.

static int iter_append_dictionary(DBusMessageIter *iter, 
                                  dbus_uint16_t dataType,
                                  const char *role,
                                  const char *description,
                                  const char *channelType)
{
  DBusMessageIter dict;

  dbus_message_iter_open_container(iter, DBUS_TYPE_ARRAY,
            DBUS_DICT_ENTRY_BEGIN_CHAR_AS_STRING
            DBUS_TYPE_STRING_AS_STRING DBUS_TYPE_VARIANT_AS_STRING
            DBUS_DICT_ENTRY_END_CHAR_AS_STRING, &dict);

  dict_append_entry(&dict, "DataType", DBUS_TYPE_UINT16, &dataType);

  dict_append_entry(&dict, "Role", DBUS_TYPE_STRING, &role);

  dict_append_entry(&dict, "Description", DBUS_TYPE_STRING, &description);

  dict_append_entry(&dict, "ChannelType", DBUS_TYPE_STRING, &channelType);

  dbus_message_iter_close_container(iter, &dict);
}

At first, you have to open the container and specify the data type of each tuple. In this case, the dictionary consists of tuples , , , and . Once the value data type for each tuple varies (uint16 or string), we declare it as a variant. Therefore, the dictionary data type definition is:

DBUS_DICT_ENTRY_BEGIN_CHAR_AS_STRING
DBUS_TYPE_STRING_AS_STRING DBUS_TYPE_VARIANT_AS_STRING
DBUS_DICT_ENTRY_END_CHAR_AS_STRING

Finally, you simply add the basic data type to message iterator (the dictionary itself).

static void append_variant(DBusMessageIter *iter, int type, void *val)
{
  DBusMessageIter value;
  char sig[2] = { type, '\0' };

  dbus_message_iter_open_container(iter, DBUS_TYPE_VARIANT, sig, &value);

  dbus_message_iter_append_basic(&value, type, val);

  dbus_message_iter_close_container(iter, &value);
}

static void dict_append_entry(DBusMessageIter *dict,
   const char *key, int type, void *val)
{
  DBusMessageIter entry;

  if (type == DBUS_TYPE_STRING) {
    const char *str = *((const char **) val);
    if (str == NULL)
      return;
  }

  dbus_message_iter_open_container(dict, DBUS_TYPE_DICT_ENTRY,
                                   NULL, &entry);

  dbus_message_iter_append_basic(&entry, DBUS_TYPE_STRING, &key);

  append_variant(&entry, type, val);

  dbus_message_iter_close_container(dict, &entry);
}

Let's use this stuff :P Anyway, it's a good tool and I need to put some ideas anywhere.

So, today's tip is how to compile your CUnit tests on Embedded platforms - in this case, on a N900 (ARM) with MeeGo installed on it.

You should download the CUnit source code from http://sourceforge.net/projects/cunit/ (I only tested versions 2.0.X and 2.1.X). The process is very simple: download the code, copy to your development environment, and build it (./bootstrap && make). However, things are not soooo easy as it seems :P

Probably, you'll face problems at initial steps.

If you have any problems on , execute the following command to change modification time/time:

find /path/to/files -exec touch {} \;

It seems to work.

IDE Integration 2nd edition is comming soon, including new PluThon Eclipse product. It comes with new and interesting features, such as ltrace integration. However, we know that Maemo community has a lot of valuable feedback and ideas that certainly improves PluThon and any other IDE Integration components (ESbox, PC Connectivity, etc.)

Please, visit PluThon 2nd edition web site, check how features you´d see implemented on PluThon and provide a feedback to eclipse-integration AT maemo DOT org. Your comments are welcomed!

Hi,

IDE Integration Beta 2 has been released, including Pluthon Beta 2 release :)

Since PluThon uses Internet Tablet environment as programming environment, most of programming tasks (except coding) are performed on your device. Then, launching/debugging are done directly on Internet Tablet.

Generally, we use distutils utilities for pymaemo to generate Debian packages on device. On this method, you need to create a setup.py script and insert a lot of information regarding to your project. You may face some problem during your first experience on debian package creation or even you may forget to insert some important information. Once your setup.py is properly created, you need to generate your debian package using pymaemo python interpreter.

PluThon also helps you to create Debian package from your project with distutils for maemo utilities. With helpfull graphical wizards, you can create Debian packages from your projects at a glance ;) For more information about this interesting feature, you can check it at PluThon User´s Help.

Try PluThon and give us your feedback!!

ESbox Beta 1 release comes with a very interesting feature: graphical installers for Scratchbox 1, Scratchbox (1 and 2) targets and Nokia binaries (which are mandatory for Fremantle, for example). ESbox also flashes your Internet Tablet with latest image.

For more information about these features, you can visit Forum Nokia Blog page.

Hi,

Maemo Eclipse Integration 2nd Edition Beta 1 was just released, including Maemo SDK Virtual Image :)

On a recent post on Forum Nokia blog, I described about how Maemo SDK VM can help you to properly configure your Maemo programming environment, specially on those cases that you have to configure a lot of machines for a Maemo programming workshop, for example.

In addition, if you want to customize your Maemo SDK VM for a specific case (for example, distribute an old Maemo SDK release), you can check here the requirements list we've considered to provide Maemo SDK VM version 0.10.