Protocol Buffers In Android Databases

I've got a self contained structure that I want to store in each row in a database.
Rather than normalising everything out into tables, I want to have the flexibility to add fields and relations, without having to perform database migrations for each client.

So I've stored my structure in a Protocol buffer. Since this structure is simply plucked out of a parent protobuf then this is simple.

I've reused the Base64 trick as storing a byte array didn't seem to work.

Base 64 Encoding Protocol Buffers

I need to fit a message inside a strict 1024 byte envelope. I've not had this kind of restriction since working on embedded devices back in the late 80's and early 90's.

I have warmed to XML having learnt hard lessons about changing on the wire formats for messages, between version skewed participants. So XML has been great for server side in banking where much of our data is already in XML and JVMs have 4Gb of physical RAM. On the transaction side of banking, XML parsing speed has always been dwarfed by RDBS transaction times. These statements are not so true on the market data side.

I'm back in the mobile device world and XML is too verbose. There are already mechanisms for reducing the size, for example WBXML, aimed at old WAP browsers. However WBXML required much hand crafting of code pages and analysis of occurrences for new message types. I shiver at the thought of all the hand coded parsers I've seen.

I had read about the Google protobuf library, and decided it was trying to address the exact problem I had, which is mainly about space. I therefore needed in binary encoding.

The downside is that the web is my wire, so I have to character encode the binary.
I'm using the Apache Commons Codec libraries for this.

I couldn't use the latest Apache Codec on android, as it appears to have a repackaged version that exists already.

11-27 15:48:42.551: DEBUG/dalvikvm(479): DexOpt: 'Lorg/apache/commons/codec/binary/Base64;' has an earlier definition; blocking out

I also could not get the Base64OutputStream and Base64InputStream to create content correctly.
Since my input content is never more than 1024 bytes, I'm using the Base64 class.

A great feature are the Base65.URL_SAFE and Base64.NO_WRAP flags which give me exactly what I need to be able to use my encoded string as a HTTP parameter.

Perfect.

Use SL4J To Isolate Code From Customers And Test Frameworks

If you're writing libraries that other people will use and you use logging, then you may have a problem.

There are so many logging frameworks out there, you're bound to have customers who use different logging libraries.

I use SL4J to solve this issue. It is the 'Simple Logging Facade For Java' and has a plugin jar for each target logging environment. This allows your library to play nicely with the logging system in the target environment without you knowing what it is.

JPA Field Names Break Encapsulation

I've made this mistake a couple of times.

When writing JPA queries I must remember to use the private field name not the bean property name.

This is annoying and leads to mistakes writing setters. I usually prefix field names with and underscore "_" or "m" (depending on the convention in the code base). If I don't do this I sometimes end up assigning the field to itself in the setter.

This detail has to be exposed to the JPA. So I tend to name the field without a prefix in JPA persistent classes.

I suppose I could always do query by example or some JPA annotation to hide the difference.

Android Icons SVG to PNG

Inkscape I love you. It was a real pleasure to work with shapes instead of pixels for making icons.
Gimp, you were great too, if only to nicely resample and render my SVG into little Icon sized PNG.

Here are some references.

h1. Android Branding

http://www.android.com/branding.html
Can be used, reproduced, and modified freely in marketing communications. Our standard color value for print is PMS 376C. Our online hex color is #A4C639.
When using the Android Robot or any modification of it, proper attribution is required under the terms of the Creative Commons Attribution license.
http://code.google.com/policies.html#attribution

h1. UI Design

http://developer.android.com/guide/practices/ui_guidelines/index.html

h3. Icon Design

http://developer.android.com/guide/practices/ui_guidelines/icon_design.html#menuapx

h3. Icon Sizes

http://developer.android.com/guide/practices/ui_guidelines/icon_design.html#screens-table

Icon Type Standard Asset Sizes (in Pixels), for Generalized Screen Densities
           (ldpi)       (mdpi)          (hdpi)
Launcher   36 x 36 px 48 x 48 px 72 x 72 px
Menu       36 x 36 px 48 x 48 px 72 x 72 px
Status Bar 24 x 24 px   32 x 32 px      48 x 48 px
Tab        24 x 24 px   32 x 32 px      48 x 48 px
Dialog     24 x 24 px   32 x 32 px      48 x 48 px
List View  24 x 24 px   32 x 32 px      48 x 48 px

MVP With No GUI Editor Sucks

I'm looking back at my old boiler plate servlets now, and thinking, they were a lot easier to write than this MVP stuff!

I imagine the pattern grew up as part of building a GUI designer. You need to be able to layout the views without them being wired up to their presenters. The two phase construction of the presenters allows this.

1) Normal class construction phase
2) Wiring phase, where the views are wired to their presenters and will start delivering interactions.

In Dolphin Smalltalk, you layout presenters (only slightly counter intuitive) they show using their default view. You can change the view they use if you wish.

Without this GUI designer, I have an extra chore of mapping my view classes to named items in the webpage. This is tedious and without the visual reference I'm getting a little lost.

The next time I attempt this, I'll try and work it into some JSP designer. I've never had great experiences with them.

Lame Mobile Experience

Couldn't use the rich text editor.

Most Valuable Pattern

I first came across the Model View Presenter pattern in Dolphin Smalltalk. Of all the patterns I've learnt over the years it remains enigmatic, beautiful and In my opinion misunderstood. Last night I implemented the MVP pattern again on a home brew project and I was struck again by the following elegant that can result, after your rewire your head.

Rewiring your head is painful and unnerving, but it's clearly something that Andy and Blair did when writing Dolphin Smalltalk. I remember the child like fascination as I traced through the very small amounts of code, wondering where the code that did anything was. When you check back and see the small collection of components. You begin to realise that it's the different composition of these components and the same pattern repeated down and down like a fractal that give rise to complex emergent properties.

What I mean by this, is that Models can themselves contain MVP patterns, as can Views and Presenters. Indeed in Dolphin Views can even act as their own default Presenters.

There's a problem though. The pattern is so loose, so decoupled so self similar and holonic that it's very easy to get lost. This isn't such a problem in Dolphin which has a great GUI designer, because the view hierarchy gives you a visual reference to which layer you're dealing with.

This being the second or third time that I've had a crack at making a simple MVP framework for the Web, and the second or third time I've tried to do it test first, I realised that that M, V & P are names for spaces that you need to fill in yourself. Having Interfaces or class hierarchies is a hindrance. The secret stars of the show, outlined in the original Taligent paper are to my mind Commands, Selections, Notifications and Interactions (or Interactors as the paper has them).

Commands, Selections, Notifications and Interactions are easy to unit test using mock objects. However Presenters appear to be largely about wiring.

I want to write some more about the circular feedback around from input view, through presenter to model and back to view.

I also want to write about the asynchronous nature of the different event or action types in MVP.

Back to the code it's too good to leave this long