Category Archives: Mobile Development

Synchronization With Interval Tree Clocks

Sync ProblemsI’ve been working with mobile devices for a long time, and inevitably the most painful piece of the development process is getting data to be consistent across all replicas.
For years, I’ve been trying to find a consistent means of taking care of this in a way which is OS and repository agnostic for all replicas. It isn’t 100% clear to me why this isn’t a solved problem, but I have a feeling there are several contributing factors:

  1. Internecine conflict between all relevant parties.
  2. Rapidly changing means and standards for data storage and transmission.
  3. Figuring out causal relationships between data on different replicas is really, really difficult.

It seems to me that number 1 and 2 having become somewhat better lately because of ubiquitous JavaScript.  I’m not saying it’s trivial, but you can make an app that works just about everywhere now if you write it in HTML and JavaScript.

When dealing with data, browser based apps are still likely to be a problem with large data sets and long periods without connectivity, but it might be worth exploring the possibilities again.

To this end, I’ve been looking at solving the causal problem with Interval Tree Clocks (ITCs) lately.  They are interesting in the way that licking battery terminals is interesting.  They are painfully tedious, but if you can stick with it, you may eventually power a solution (or be brain damaged).

For a long time, I think the standard way to handle the problem of causal relationships has been vector clocks, but they have well documented limitations around space usage which do not apply to Interval Tree Clocks.

Also, you can make pretty diagrams with ITCs.

ITC Node Diagram

So I’ve been trying to rewrite the ITC algorithm in C#.  This may seem ironic since I just told you that JavaScript seems to be one solution to some of the industry’s synchronization problems, but the reality is, I’m much better at exploring ideas with type safe code.

I’ve gotten most of the C# working, and I’ve created tests.  My intent is to use those to safely port the C# over to JavaScript.

You can check the code out here.

If you prefer Java, Erlang or c, there is a repository from the original designers of the algorithm here.  A word of warning: if you try to use that repository to follow along with my code, it will be very difficult.  Conceptually, the code is somewhat similar to what I have written, but my implementation is almost entirely different.

Mobility is a Mess

Lately, I’ve been trying to learn mobile development for both professional and open source coding.  The irony is that I’ve been doing mobile development for 8 years.  Unfortunately, mobile enterprise data acquisition has been tied closely to Windows CE/Windows Mobile for a long time.

Recently Microsoft created chaos in the market by abandoning support for Windows CE in Visual Studio 2010.  They also decided not to release any new version of .NET Compact Framework as a development platform.  When they realized how stupid this was, there appeared to be some sort of internal mess as MS tried to make up lost ground with the vendors that had sold bazillions of Windows CE units for them in the past.  After stumbling over themselves for a while, they’ve consolidated their embedded offering with their handheld offering to create Windows Embedded CE and pulled together some sort of backward compatible offering called Windows Embedded Handheld (at least that’s what they are calling it this week). At this point, I really don’t care very much.  I get the feeling that the market has been burned and will be going to Android.

Motorola Solutions is coming out with its first Android offerings now, and this means a lot of choices are ahead for the company I work for.  Should we attempt to write Java when we have never deployed a line of Java code in the past?  Should we use an offering like Mono for Android?   What if we want to offer applications in iOS as well?  Should we learn Objective C too?

Motorola Solutions is offering Rho Elements to allow developers to create out of the browser applications on their devices using JavaScript and HTML, but they are asking users to pay a steep per device license fee.  It seems like such an obvious losing strategy, I have no idea why they have even considered it.  Perhaps they aren’t aware of this widely used tool called PhoneGap that does (by all appearances) the exact same thing … for free.  Oh, and PhoneGap is affiliated with Adobe so PhoneGap gets first class support in DreamWeaver, and a high probability of continued adoption from the community.

PhoneGap seems like the obvious choice in this scenario, but there are a couple of other tools to consider.  Appcelerator is really starting to make a name in the mobile market by doing much the same thing as PhoneGap.  The difference between them appears to be that Appcelerator actually has a per-developer license fee associated with it, compiles to native code (making it speedier), leaks a lot of memory if not handled correctly and has relatively horrible documentation.  Also, it uses JavaScript only.  I haven’t figured out how the UI is created yet without HTML.  I don’t really feel like forcing our designer to use another IDE, or paying for the additional license for that matter.

The last option I’ve seriously considered is Mono for Android.  Any of the options in this article could probably fill an entire blog post with pros and cons, but Mono in particular is an interesting beast to me because I’ve come from a .NET background.  The main problem with Mono is that it is such a niche technology and is pretty much owned by Xamarin.  Although Xamarin has some very smart people running it, the company is less than a year old and I haven’t seen wide adoption of their technologies.  In the development blogs I read, there is rarely discussion of them at all.  It just feels like a big risk at this point.  The $800 per developer (to get both iOS and Android) is negligible relative to the potential development losses.

On the other hand, JavaScript and HTML, are free and being adopted by everybody.  In case you’ve been living under a rock for the past few years, JS isn’t a toy language anymore.  There are plenty of serious frameworks aimed at creating professional, maintainable code in JavaScript.  Windows 8 is favoring JS and HTML as the primary mode of delivering windows out-of-the-browser apps.  Adobe is killing off mobile Flash in favor of JS and HTML, Google uses little else, and Microsoft probably will not be offering a Silverlight version after (the current) v5.

How can you really go wrong?  If PhoneGap miraculously disappears, you can (obviously) run your app’s hardware agnostic code in the browser.  You can consider Rho Elements if you have to port your code as quickly as possible, or you can reuse your business logic in Appcelerator.  You can even reuse your client side business logic on the server if you like (using Node.JS).

Of course, the mobile development community changes so quickly that I could be laughing ruefully at this post next year.

A New Application Effort from VeeCollective (and Me)

My friends at VeeCollective proposed that we begin work together on something fresh and sparkly.  We all feel the need to rumble in the mobile dev bandwagon.

It seems though that the most difficult part of writing something that smells like rainbows is, in fact, to think of something fresh and lively.

At first, we felt certain that we should develop a real estate app.  We wanted to create code that would allow us to circle a spot on a map and find all the desperate souls trapped there in potential foreclosures.  Their tormented need would bubble up through iOS and Android portals everywhere to help our users take advantage of their misfortunes.

But then we decided, no … too Dante.  What we needed was something that would make people happy on both ends of the interface.  To that end, we decide on building Six Degrees … or Integrity … or ….  Turns out the second most difficult part of creating this app is thinking of something to call it.

The idea is to open source an app that is a little bit like DropBox in that it would provide users with their information anywhere.  The major difference is that the application would integrate directly with other apps that provide the information, reach in and (at user discretion) change the structure of the information to be consistent across platforms and applications.

So for instance, if you had a task hierarchy set up in Outlook, the app would replicate that structure in iCloud or Google or Remember the Milk or whatever app somebody feels like writing an interface for.  The intent is to write the application backbone in a way that encourages other open source (or private) developers to create their own application interfaces.

Oh, and did I mention we want to write the synchronization to be full mesh?  No central repository that forces users to pay for storage.

Oh yeah, and we would like to provide a complete indexing of the content, so that in our spiffy hierarchical interface, when looking at a contact (for instance) the most relevant, related data would bubble up and cling to that contact with little gossamer threads.

I’d say we’ve got our work cut out for us.