In this multi-part tutorial, you will discover how to seamlessly integrate your Salesforce data into an OutSystems mobile application. You will learn to incorporate the Salesforce connector, authenticate with Salesforce, pull data from Salesforce’s servers, and cache the data for use in your mobile application.
In part one, Authenticate with Salesforce, you added the Salesforce connector to your OutSystems mobile project and authenticated using your Salesforce credentials. In part two, you will cache Salesforce user data to the device for use in both online and offline modes. The video in this tutorial guides you through the following steps:
- Create a local user entity for mobile storage.
- Return authenticated user data to the client.
- Synchronize local user with server user.
- Present cached user data on the client.
Watch the video for the full step-by-step process or read along for an abridged description of the video’s content.
1. Create a Local User Entity for Mobile Storage
For mobile OutSystems projects, we recommend maintaining a disparate, offline database that acts as a cache for server data. You then have a database that stores data relevant to the authenticated user and little else. This strategy has two major benefits:
- It reduces the number of network requests and bandwidth consumed, thereby sparing network usage and battery.
- It enables "offline" mode, and offline mode permits users to continue receiving value from the application even when disconnected or located in areas of poor network reception.
To begin, create a UserLocal entry that mimics some (or all) of your User entity’s attributes. In this tutorial, we copied the Name, Username, and Email attributes from the server User entity to our local version, thereby reducing our application’s data requirements. In many cases, your mobile application may not require complete duplicates of server entities to provide an excellent experience.
2. Return Authenticated User Data to the Client
User data, such as email and username, rarely change. So we will provide this data just once during the Login server action. While this approach will fail to update local information until the user logs out and re-authenticates, it will satisfy most cases. And in the unlikely event that our choice fails to give the correct username or email, it will not result in a poor user experience.
To complete this step, add an output parameter to your Login action that returns the authenticated User entity to the client.
3. Synchronize Local User with Server User
This next step is simple, but critical. During the local DoLogin action, you need to cache the user data returned from your modified Login action. To begin, clear the local database of all UserLocal entries; we do this under the assumption that each login (even when occurring on the same device) may represent an entirely new user.
Next, assign the necessary attributes to a new UserLocal entity. In our example, we assign the username, display name, and email to the UserLocal copy. To finalize this step, save the entity to the local database with a CreateUserLocal action.
4. Present Cached User Data on the Client
With cached data prepared, all that’s left is to present the data to the user. In the UserInfo block’s preparation, use an aggregator to retrieve all UserLocal entities. The query results in one record, so it requires no filter. Replace the “Username” expression with the username attribute found in the results, and publish your changes.
As stated earlier, you must re-authenticate to see the changes reflected in your user interface. After logging back in, you will see your actual user name in the sliding menu.
In the next part of this tutorial, you will retrieve and cache the user’s Salesforce access token.