Building offline native apps with Gateway and LBO’s

[bradp]

I’m not sure if this approach has been done before, but when searching SCN for LBO it only returned 11 results for my search, and none of them covering the use of LBO’s in this scenario. So I thought I would share this approach that I have been using in native app development to enable offline functionality.

Over the past few months I have been using the Gateway productivity tools for Android native development as a means to get started with consuming Netweaver Gateway OData services. The tool is a great way to accelerate the development of native apps, however given that OData does not currently support offline capability (although apparently this will be possible soon, according to SAP) it is only really useful for online apps at this point in time. Which can be expensive on bandwidth if the same data needs to constantly be downloaded every time the user accesses the app. Although the OData SDK does currently have persistence capabilities, it seems rather basic and not suitable for more complex requirements. 

Initially I went down the path of creating MBO’s which consumed the Gateway REST services, which worked however performance didn’t seem great. Also it felt as if by doing this, I lost all the benefits of using the OData SDK.

I initially considered the idea of creating my own sql lite database in the app, but due to the manual effort required to do that on each mobile platform, I started exploring the idea of using Local Business Objects (LBO’s).

Local Business Objects are also created in the SAP Mobile SDK eclipse development environment, in a similar way to creating MBO’s except they are not bound to a backend datasource. This means that all attributes need to be created manually. Once created they do not need to be deployed to the SAP Mobile Platform as you would do with MBO's. The Object API code can be generated for the chosen platform: Android, iOS, Blackberry, etc. The code can then be copied into your IDE, whether it be eclipse or xcode and you can start using almost all of the features of the Object API,  excluding synchronization as they LBO’s are not deployed on the SAP Mobile Platform server and are purely used for persisting the data for offline capability.

I thought I would list what I thought are the advantages and disadvantages of using this approach:

Advantages

• Relational Database designed centrally and can be deployed to multiple mobile platforms such as Android, iOS etc.
• Easy to use Graphical Database design tool (SAP/Sybase Mobile SDK)
• Benefits of using the Object API excluding synchronization
• No need to deal directly with SQL statements in native code as Object API generates all the entity classes and query methods
• Easy generation of CRUD (Create, Read, Update and Delete) methods and any custom queries can also be easily defined in LBO in SAP Mobile SDK
• Benefits of encrypted UltraLite Database

• Can be used with or without SAP Mobile Platform

Disadvantages

• Requires manual coding to map from ODP Entities to Object API Entities
• Requires manual handling of delta query. This can be handled on the server side, by passing through a filter such as a last updated datetime stamp. Or alternatively using the OData Delta Query Support (Which I have not tried myself yet)
• May not strictly stick to REST principals
• Requires slightly manual means of dealing with links
• Requires manual method of dealing with pending operations

I am by no means saying that this is the ideal or even best way to deal with offline scenarios, but I am just putting it out there as an idea of a possible approach to it. In fact once SAP do introduce offline capability into the OData SDK this approach will most likely become redundant.

I would be interested to hear how others have dealt with offline scenarios in native apps while using Netweaver Gateway, as well as any criticism, recommendations or alternative approaches.