Getting Started: Learn
Offline access means that mobile apps can function even when the device does not have network connectivity, and can maintain device data that is kept in sync with back end data sources.
This document contains an overview of how to build offline apps and includes the following sections:
Offline design considerations
When designing offline support into a client app, consider the following:
- Will users be able to log in to the client app when the device is offline? Offline log in lets the user continue to use the app even when they do not have a connection to the back end.
- Should the client app be able to store persistent data on the mobile device? Persistent data is available across executions of the app. Therefore, if the device is offline, it can still access the persistent data stored on the device.
- Do you require encryption of the persistent data on the mobile device? Encryption adds a level of security to help prevent unauthorized access to your data.
- Do you need to synchronize persistent data on the device with the back end? For example, when the device goes back online, should it synchronize its local data with the back end? Or, should the client app perform a sync on a predefined interval?
- If you are synchronizing data with the back end, how does the back end represent data? Your client app must be able to represent data in a format that is compatible with the format required by the back end.
- What are the endpoints on the app scope that you access to synchronize data? When using the Akula synchronization mechanism, a client app makes requests to, and receives responses from, and endpoints on an app scope.
Choosing your level of support for offline apps
As an app developer, you can decide on the level of offline support to build into your apps. Each app has its own unique requirements, and Akula provides several features that you can choose to use to support an offline app. Depending on your level of support, you will have to built functionality into the client app only, or into both a client app and an app scope running on the Akula Server.
Offline log in and log out
Authentication determines a user's identity. To authenticate a user when the mobile device is online, the client app calls a log in method, passing to the method the user's credentials, typically a username and password. The log in method on the client passes these credentials to an app scope running on the Akula Server for validation. If the credentials are valid, the Akula Server returns a session token and a log-in timeout value.
The Akula Server also returns permissions, and other authorization information, back to the client app after a successful online log in. This information is stored on the client and is available after an offline log in. You can use these permissions in your client app to control user access to offline or local resources.
For example, after a user has logged in successfully online, the user can log in to the client app when the device is offline by using the same credentials used for online log in. After a successful offline log in, the user can access local resources on the device based on the same security rules used for online access. When the device goes back online, the user must log in again before they can access server-side resources.
Offline log in support is built into the Akula client SDKs. The only work that you have to do in the client app is to call the log in method, and then decide how to interpret the permission information returned to the client on a successful log in.
The Akula client-side persistence mechanism lets you store data on a client device that persists across executions of the app. That means you can run the app and store information to the persistent data store. When you next run the app, that persistent data is available to be loaded back into the client app. The Akula client-side persistence mechanism supports CRUD (Create, Read, Update, Delete) operations on the persistent data store.
One of the advantages of the persistence mechanism is that you can write data to it or read data from it when the mobile device is offline. When the device goes back online, you can then decide to upload the data to the server, check the server to determine if there are any data updates, or perform other operations on your persisted data.
To add support for the persistence mechanism to you app, perform the following steps:
- Define the class that represents your persistent data. To work with the Akula persistence mechanism, a class must implement the AKModel interface (Android) or AKModel protocol (iOS).
- Build the schema that represents your persistent class in the Akula persistence mechanism. The schema defines information used by the persistence mechanism to represent data.
Initialize the persistence mechanism with the schema for each class that you want to persist.
- Create an instance of the AKPersistenceManager class in your client app. The AKPersistenceManager class define the methods that you use to perform CRUD operations on persistent data.
- Call methods of the AKPersistenceManager class to access persistent data.
Encrypted persistent data
If you want to secure and protect your enterprise data when it is on a mobile device, you can encrypt the persistent data store. Encryption prevents unauthorized users from reading your data.
Client access to the encrypted persistent data store is controlled by a passphrase. When a client app starts for the first time, the encrypted persistent data store has not yet been created. It is by unlocking the encrypted persistent data store for the first time, and by supplying a passphrase, that the encrypted persistent data store is created.
After the creation of the encrypted persistent data store, the app must use the same passphrase to unlock the encrypted persistent data store every time the app starts, or if the encrypted persistent data store is ever locked.
To add encryption to the persistent data store:
- Link the correct libraries with your Android or iOS client app. Akula provides libraries for unencrypted persistent data and encrypted persistent data.
- Use the AKEncryptionManager class to create and unlock the encrypted persistent data store.
The encrypted persistent data store can be unlocked, meaning that the client app can access it, or locked, meaning it is not accessible and any attempt to access it results in an error.
- Call methods of the AKPersistenceManager class to access the encrypted persistent data store, just as you do for unencrypted data.
Built on top of the persistence mechanism, the data synchronization mechanism lets you write data to the persistent data store on the client, modify the data, and then upload those changes to the Akula Server sometime later. The server then updates the back end data store with all of your changes. If any other client has modified data on the back end, the server returns those changes back to the client. You can use synchronization with an encrypted or unencrypted persistent data store.
While the Akula client SDKs has built-in support for synchronization, you are responsible for handling the server-side aspects of sync. There are many ways to handle data synchronization on the server and many issues to consider. For example, consider conflict resolution which can occur when two or more clients modify the same object. Or, consider how to determines which server-side data changes to send down to the client.
You must develop a custom module to handle the sync data sent up from the client. The module is responsible for updating any modified and new data objects in the back end data store, and for resolving any conflicts caused by multiple clients updating the same data.
To add synchronization to your app:
- To add data synchronization to your client app, you only have to add a call to the sync method of the AKPersistenceManager class. That method automatically uploads any changes to data in the persistent data store to the server since the last call to the sync method.
This document contains only an introduction to creating offline apps. For detailed information, see: