Offline Applications and Occasionally Connected Applications

One of the main features of GeneXus Tilo is what we call Offline Applications.

Some time ago (around June or so) I told Gabriel (our Marketing Manager)  that we had been working on a feature no other tool has: automatically generating an “occasionally connected” architecture for Smart Devices applications. And I added, “more on this in a blog post I’ll write soon”.

For several months I had this pending action in my inbox ;) And yes, today I’ll explain why the architecture we are generating for our SD apps is unique.

What we mean by “Offline Applications”

This feature aims to solve two different scenarios:

1) “Occasionally connected” applications (e.g. Mobile Point of Sales apps)

From an architectural point of view it’s an application that uses data from a remote database or centralized system, but does not always have access to the it (e.g. because the app is used where there is no Internet connectivity).

When these apps cannot reach the remote database, they use a local database stored inside the device, and in some way (periodically, event driven, user action) synchronize their local data with the main database (by pushing any updates to the server and receiving any changes).

2) Full Offline applications: (e.g. Metro Application | Printed Guides apps )

These applications never use data from a remote server, they work with only a local database.

Why is GeneXus unique?

The second scenario is the easier one, but nevertheless I couldn’t find another tool that generates all the needed code. GeneXus automatically generates the sqlite database and the BL to access it in Android (Java) and iOS (Objective-C). But, as I said, this is a rather simple scenario and another tool with the same capability may be out there.

The first type of applications is where GeneXus adds even more value by automatically creating an Occasionally Connected Architecture. I’m pretty sure that GeneXus is the only programming language that generates all the code needed to implement such a complex scenario.

In 2004 Microsoft published a great article explaining what you should consider to create this kind of architecture. To be brief, it is not an easy task, even for an expert programmer. Let me enumerate what we generate for each app:

• The remote database (e.g. Oracle, DB2, Informix, MySQL, SQL Server) and all the server-side code (Data and Business logic layers) in your preferred language: Java, C#, Ruby.
• The client database (sqlite) and the client-side code to access it in Objective-C (iOS) and Java (Android).

But that’s just part of the story, we also provide:

• The Synchronization Process
• Send information from the Client to the Server
• Receive information from the Server
• A Service-Oriented approach to the sync process.
• Favoring asynchronous communications: we had to implement synchronous-like communication on top of an asynchronous infrastructure.
• Managing data send and data receive criteria: when to send or receive the data to and from the server.
• A “store and forward” mechanism to send information to the server. We store database transactions as “messages” in the device and arrange these messages in queues while the client is offline. When connectivity is reestablished the queued messages are sent to the server for processing.
• Consider that primary key and foreign key values on the server side can be different than in the client (due to autonumbering) for sync algorithms.
• A Synchronization API to programmatically query the state of the sync process (pending messages, synchronization errors, etc).
• Preloading mechanisms.
• Many apps need to have preloaded data to avoid downloading a lot of information on first launch. For example, in an app for an Event you could ship your application in advance with embedded information about the speakers, countries, locations and automatically sync information about conference sessions when it becomes available later.

We are still working in many areas but the hard work is done. We faced many problems, and learned a lot in the process. Luckily, those lessons have been applied to the generator, so that GeneXus users who need to build this kind of apps don’t need to trip over the sames problems (such as the particulars of sqlite transactions or memory constraints in Android).

The great thing about all this is that you just need to specify some model properties to generate an application with this functionality.

But, wait a second:

• Is it possible to have a hybrid application where some parts show online data while others use local data?  YES
• Who designs the schema of the local database?  GeneXus, automatically!
• Can I filter what information is sent to the clients? YES

You've probably already noticed that I’m very proud of what our team has achieved here. YES I AM. And as I said to Gabriel, I do think it’s a unique feature.

If you want further information, we cover all the functionality details here.

Happy New Year!

@gmilano