You can use MDriven as the back end for a mobile client when you need the client to read and write application data and run application actions; this page is for developers choosing between a connected mobile app and an offline-capable mobile app.
Example 1: Connected mobile app using a REST back end
Use MDriven Turnkey REST services when a native mobile app needs to work with data and actions defined in your application model.
When you expose a ViewModel interface as a REST service, the mobile client can use it as its back-end interface instead of receiving a rendered view.
For example, a payment app can use a ViewModel-backed service to show a payment request, submit an action that starts the request, and retrieve the resulting status. The mobile client only needs the data and actions that the ViewModel exposes.
| Mobile-client need | Back-end responsibility | Example |
|---|---|---|
| Read data | Expose the required ViewModel information through REST. | The app retrieves the current state of a payment request. |
| Change data or start work | Expose an action through the ViewModel interface. | The app submits a request-to-pay action. |
| Check a result | Provide an endpoint for the relevant status information. | The app retrieves payment status by using the request reference. |
Mobile Money integration example
The MOMO integration example shows MDriven consuming RESTful APIs from an external Mobile Money system. Its service collection includes authentication, request-to-pay, transaction-status inquiry, account-balance inquiry, and user-information inquiry.
A mobile app back end can use the same integration pattern when the app must initiate a payment and later show its status:
- Authenticate with the external API using the required subscription key and API user/API key credentials.
- Send the request-to-pay operation from the MDriven application.
- Store or present the request reference needed for the status inquiry.
- Query transaction status before presenting the completed result to the mobile user.
Example 2: Offline-capable mobile app with a separate local model
Use a separate local model when users must keep working without a network connection. This pattern is relevant for users in locations where radio, Wi-Fi, or WCDMA connectivity is unavailable, such as underground construction sites or shielded rooms.
For example, a field worker can create or update planning data on the device while offline. The local model persists that data locally. When connectivity returns, the local application and the server-based application are separate parts of the solution; synchronization can use REST APIs and JSON information trees based on ViewModels.
Choose the architecture deliberately
| Situation | Architecture | Concrete example |
|---|---|---|
| Users normally have connectivity and need current server data | Connected mobile client with a ViewModel-backed REST interface | A payment app starts a request-to-pay operation and checks its transaction status. |
| Users must work where connectivity is unavailable | Separate local model with local persistence, then REST-based synchronization | A field worker records planning data underground and synchronizes changes when connected. |
Do not treat offline synchronization as automatic. Model the local application and the server application as separate parts, then define the data exchanged between them through REST APIs.
Related device-client options
You can also display part or all of a server system in a device app by using Cordova. HTML5 capabilities can provide device features such as position access. A device app may not be necessary when a browser-based experience meets the requirement.