Adding a route with android's route

Today I needed to add a route on the android shell but was greated with "Invalid Argument" failures, there is no "-h", no man page. So we will have to use the sourcecode.

First of all the code is in /system/core/toolbox/route.c

and it supports three types of argument..

• route add default dev DEVICE
• route add default gw IP dev DEVICE
• route add -net IP netmask NETMASK gw IP

Qt Quick vs. Android XML Layouts

In the last month and next couple of weeks we were/are developing a similiar application for Android, iPhone and the Desktop (using Qt and Quick) with native technologies. I will focus on Android and Qt as both are Open Source and we were developing them in a similiar fashion with one designer and one developer interacting with each other.

In both cases the application has a couple of views mainly consisting of a ListView of some sort and I will explain how this has been realized for Android and then with Qt Quick and provide some summary of what has worked well, what Qt Quick could learn from that. I have not worked with Qt Quick or Android prior to this project so I might have used the technology in the wrong way, and at your option you can either hold this against me or the technology.

We have started the project by doing the Android application. The model for my data is based on the abstract class called android.widget.BaseAdapter and I needed to implement a couple of functions. The first is the answer how many items I have, return an Object at the given position, an identifier for a position and finally a function that creates a View.

This function is called getView(int position, View convertView, ViewGroup parent) and the common usage is to check if convertView can be used to display the item at position and then modify (e.g. set the iccon, text, hide things on that view) otherwise we were using the LayoutInflater to create a View from one of the pre-defined layouts and set the items.

In Android one can describe Layouts in a XML Document, or use a still very basic Layout Designer (that will mess with the indenting of the XML), one unique feature is one can have different layouts for different properties, e.g. one can create a layout that will be only displayed if the application is in Landscape, uses Docomo as Operator and more. This is a very powerful system and we have only used it to have different layouts in portrait/landscape so far. The next important thing is one can ask the LayoutInflater to create the View for a given identifier, the next part is to find the items inside that view. Each View has a method called findViewById that is searching the children for that id.

One common pattern is to not call findViewById everytime one needs to access a widget but create a ViewHolder class with references to the Views and use View.setTag(Object tag) on the top View to set that ViewHolder on the View.

So how did the Designer and Developer interaction work here? First of all the Designer was responsible to create the View for the various parts of the UI and I was responsible for creating that BaseAdapter derived class, implement the getView method and set the right text/icon/visibility on the items of the layout based on the item that is to be displayed.

How did that work? In general it worked great, I could create a UI that worked, the Designer could make it look nice, the biggest problem (besides the basic UI editor, fighting with the RelativeLayout class) is that during redesigning a layout id's were dropped from the Widgets and I had to assist the Designer to identify the missing IDs and add them back to the Design to keep things working and display the right thing again.

The Quick project is still work in progress and a lot like the Android project, the Developer creates the code (or states and interaction) and the Designer makes it look good. Our ListView's are backed with classes based on QAbstractListModel (using setItemRoles to export the roles as QString) and the designer is forced to edit the files by hand right now.

The thing that really works better with Qt Quick is that the delegate (equivalent to the getView in Android) is in the hand of the Designer. This means that the Developer only needs to export the right strings for the roles from the model and the designer can use that to create the UI.

From my point of view the Qt Quick approach is really superior to Android's XML Layout system, with Qt Quick we could get started faster by having a full click dummy (create the ListModel and fill it with dummy data), allowing the designer to fill the UI with content from the first day of the project, and by having the delegate in the Designers hand we have no "losing" id's in the diff of an unformatted XML Stream. The only thing that has no proper equivalen in QML/Quick is basing the state on external properties, or with other words, I have not seen any documentation for some basic system/device properties.

First Steps with Qt's Quick

I am very excited by the Qt Quick technology and I have finally found a reason to use it and gain some experience with it and want to report from my first hours of exploring it. The first time I have seen Declarative UI was with Enlightenment and the Edje framework. I liked it so much that I registered Epicenter five years ago. The plan was to create a handheld framework using declarative UI.

Now Qt Quick is not just a copy cat of Edje but adds some nice improvements over it. The first one is the usage of Javascript instead of the C like language, better integration with Qt's Object Model (properties) and libraries/plugins. From my observation at Openmoko, our developers kept a set of C preprocessor macros around to do coming things with edje with Quick it seems to be better as one can import libraries and such.

The most common mistake I have made so far is dealing with the width/heigh of an Item. In my case I created an Item, placed a MouseArea (to deal with user input) of the size of the parent (anchors.fill: arent) in it and then also add some Text (as sibling). Now it appears possible that the Text is bigger than the parent item. For performance reasons no clipping is done by default so it renders just fine, just clicking doesn't work. Which is bringing me to my debug trick...

I place a Rectangle { anchors.fill: parent; color: 'blue' } inside my item and then I actually see where it is. Another nice thing would be an Xray view showing the border of each item, their id but only in black and white. My solutions for this problem so far (from my first hours of using it) is to either use a Row/Column which seems to get the widh/heigt updated based on its children, or in some cases place a width/height inside the Item itself.

This is bringing me to the biggest issue with the qmlviewer and also an idea on how to resolve it... In the last couple of month's I started to contribute to GNU Smalltalk and looking more into Self, Smalltalk-80 and such. The clever Xerox PARC people invented Model-View-Controller as part of Smalltalk-80, Qt adopted some parts of it with Qt4. In the meantime something called Morphic emerged. Morphich is a direct-manipulation User Interface. This means one is creating the UI inside a running UI by composing it from simple objects (just like Quick). In contrast to it one can inspect each element and interact with it, change it at runtime without restarting. This allows faster changes, and easier debugging in case something goes wrong. E.g. it easily answers the question of what is the width of that?

So for the immediate future I would like to see something like the WebKit inspector emerge for QML. This would allow to inspect the scene graph, change it from the console, has some simple hit testing to inspect one element, has the JavaScript Debugger and Profiler available, the timeline... and I am pretty sure to not be the first one to want it.

How to make sure your online business is failing and ways to fix it.

This is a more calm rant of a post I have done earlier today and removed. Everytime I have to use a proprietary online shop to buy something the thing is just of very poor quality. One example of last year is Best Western, their bookingsystem was so bad, I had to book the Room through Yahoo Travel.

So here is my top six of how you can make sure your online is failing (and how to fix it):

1. Make sure your webpage only works with Flash, Internet Explorer 5 with the right locale, a Java plugin to enter the CVC number of your credit card... It is not that JQuery or website testing frameworks like Selenium needs to be invented...
2. Make sure the user experience is bad, try to nest the content in as many frames as possible, make sure the user needs to scroll with at least two scrollbars. The easy solution is, test your content with 1024x768 and don't use frames...
3. Provide options on your purchase and then send long, very long boilerplate emails that the user needs to call your expensive hotline to pick another option. Provide fewer options, make sure the payment process is working for them, or use another good company for the payment.
4. Provide wrong errors codes. E.g. when a flight is fully booked, claim the credit card number or the postal address is wrong. Blame it on the credit card company, it is easy, unless the customer calls the credit card company...
5. Let the user enter his address multiple times, insist that he must have a landline number...
6. Have a hobby programmer decide that + is not a valid part of an email address...

GPRS issue resolved

Hi,

with some more debugging and fun with wireshark scripting and looking a pretty obvious issue has been resolved. Now GPRS for us is actually using IP, UDP, NS (some simple address and type of the messages), BSSGP (protocol between SGSN and BSS) and for actual data there is LLC at the end of the BSSGP. The LLC is part of the BSSGP payload as TLV (Tag, Length, Value).

I created a simple setup that worked. It involved getting the traffic from the BTS, relayed with a simple smalltalk script (I had to do some fixes to GNU Smalltalk), and then send it to another SGSN. With a small variation of sending the data through our proxy I made the nanoBTS crash.

From observations I found that the other SGSN is padding the FLOW-CONTROL-BVC-ACK and FLOW-CONTROL-MS-ACK packets to 28 bytes, but padding/not padding had no effect on the crash.

The next observation was (before I tried doing it manually) that I now have each packet twice, once coming from the SGSN and how it looks after our proxy, apparently the proxy truncated the UDP packets....

So what errors have happened?

1. The nanoBTS accesses random memory with short LLC frames and crashes, instead of crashing it should send a STATUS (I think BSSGP) returning our
2. The wireshark BSSGP dissector does not check the size of the LLC frame (I created a bug report with a patch)..
3. The proxy code was not reading the whole datagram and we had to increase the size, according to the spec the maximum size is 1600 byte for Framerelay... we now have a slightly bigger message...

Fun with GSM...

In the last couple of weeks I was traveling, searching a flat (a total failure so far), working on the Android Project, something else and of course GSM. I am having fun kicking another blackbox and try to figure out why it is catching fire and starts burning.

We assume this is related to GPRS (that got recently added to OpenBSC thanks to the sponsoring of On Waves) and something within the UDP messages we send. Now the GPRS protocol sandwhich can compete with the Whopper 7. We do have UDP, then NS, then BSSGP, then LLC and as the BTS is crashing it has failures handling UDP, NS or BSSGP. Of course we are using the excellent Wireshark and filter the packet dump for malformed but there is nothing that Wireshark is considering malformed... Now Wireshark allows to write dissectors, taps and more with LUA. So my next step was to write some LUA scripts to analyze a stream that makes the BTS crash and one not. The LUA Script can be found inside the OpenBSC git repository.

Today I tried to continue with the BSC/MSC split but there is quite some stuff to fix inside the code before this will become a reality, e.g. in the SMS code we have no place where we consider the task of sending SMS to a subscriber as "done". Also looking at the many places where we stop a "transaction" makes it highly likely that we do have leaks there...