Development of an MDK based cross platform solution

This is a part of a blog series. In this blog I am describing the development of a MDK based solution to replace an existing cordova mobile solution. More options will follow after this blog.

To start the development of the mobile application, a configuration in the SCP Mobile Services cockpit needs to be created.

The wizard will guide the admin through the setup and help define configurations like:

• Backends for the mobile solution
• Security configurations

More configurations can be done later to fine tune the operations of the mobile solution.

Figure

The basic application with the correct data model can be generated with a couple steps by using the “MDK Base Project” template in the SAP Web IDE. As key feature offline will be enabled. The wizard fetches the metadata retrieved from the backend system and generates proxy classes. The Proxy classes are a key part of the SAP mobile SDKs . For each entity in the data model a class will be generated to give the developer fully typed mobile data model to build the mobile solution against.

Figure

Figure 5 shows the structure of the newly generated MDK application. Each folder contains several auto-generated files, and similar files created in future should be located in the respective folders. The name of the Actions, Images, and Pages folders describes the files contained. The Objects folder holds proxy classes, and Rules folder contains JavaScript files for implementation of business logic. So with a few clicks a mobile solution was generated which can authenticate against SAP mobile services and take data offline.

Figure 5: MDK Application Project Folder Structure

To start developing the UI a new UI-View must be created. In MDK this component is called a Page. Different types of pages in an MDK application are Form Cell Pages and Section Pages. For pages that create or modify a data object, the Form Cell Page is the suitable page type. This is useful for event admins creating a page of a new event and submitting it to the backend or modifying an existing event because of its specialisation in providing fields to enter data. The UI elements designed for this type of page also serve the purpose of entering and editing data. Different elements are, for example, the Date Picker, Duration Picker, Switch, and Simple Property. The second type is the Section Page and is suitable for displaying information. Two types of components, Compound and Static, exist for this kind of page. Compound elements display a collection of similar data objects, allowing the developer to determine a specific data query to display all objects of an entity set. However, the static type displays attributes of only one data object, which is passed on to the page during navigation. The first page to be implemented, displays a full list of events.

After a new page is created an object table element is dragged and dropped into the page to display the events. The developer can now bind the data in the object table properties. There are two given possibilities, QueryOptions and ReadLink to filter these data objects.

Figure

Query options enable the usage of OData queries like filter, select, expand, and sort. MDK allows the Query Options Expression Editor (Figure 7) to make querying data easier.

Figure 7: Query Options Expression Editor for Event Entitiy

The next step is to bind the attributes of an event object to the different fields of the object table.

The last step is to enable the search functionality by selecting “true” for the search- enabled part of the search section, as it shows on the right side of the above picture. The MDK search also can enable a barcode scanner as part of the search, so end users can use the information of a barcode to find the matching result. To activate this functionality, choosing the “true” value in the barcode scanner part of the search section is enough.

The next page to be described is the EventOverview page. After clicking on an event from the event list page, users are directed to this page. To start, an empty Section Page should be created like the previously implemented page. MDK automatically passes the interacted event object to the EventOverview page, enabling the usage of the object’s properties. Again, the right set of controls are dragged and dropped onto the page. Through the controls properties the controls are bound against the right data sets.

Figure 9: EventOverview Page in Web IDE

To add some business logic an MDK Rule in JavaScript is added. In the example here, a JS file is written to display the number of session in the user’s agenda and an event.

The code below is the function written in JavaScript file to retrieve and return the number of entities in the UserSessionAgendas.

 export default function UserSessionsCount(sectionProxy) {

 //The following currentEvent will retrieve the current

 // event record

 const currentEvent = sectionProxy.getPageProxy()

 .binding.EventID;

//The following expression will retrieve and return the

 //total count of the UserSessionAgendas for the given event

 return sectionProxy.count(

 ’/EventAppMDK/Services/EventAppMDK.service’,

 ’UserSessionAgendas’,

 ‘$filter=EventID eq ${currentEvent}‘).then((count) => {

 return count;

 });

  }

This method has a return value with the type of an integer, which can be used directly in the UI. So we can show the aggregated number of sessions in the view.

To add interaction to the application MDK Actions can be added. , a widespread action type allowing end-users to move from one page to another. This Action should be assigned to the object table created in the EventList page.

The second Action explained is an OData action to add an event’s session to the end user’s agenda. For adding a session to the UserSessionAgendas entity set, the created entity type should be used.

To finish the implementation of this action, it needs to be assigned like the previous action to a UI element, but this time to a button in the SessionOverview page.

The implementation of the MDK application is finalised with ten pages, 16 actions, and four rules. Screenshots of the pages can be found in the Appendix (A.2).

Summary

The MDK EventApp costs twenty-eight working days. In comparison with the 32 days for developing the Cordova version, this shorter development phase underlines the superiority of the initial development characteristic of MDK. The SAP developed tech stack of MDK not only saves time during the development environment setup but also reduces the maintenance cost of the application as features like logging and tracing, which can be used out of the box.

In the first launch time of the application, the OData offline store initialisation processes, as well as retrieving and storing data locally, took approximately 10 seconds for this relatively big application’s data model. The retrieved data from the application’s OData endpoint was compressed to a size of only 1.7 Mb. The application startup time, excluding the first launch, takes 3 seconds for loading the application and feeding offline stored data to the UI. Loading a screen while navigating from another one takes approximately 1 second in comparison to 3 seconds of its Cordova version.

The Cordova version is limited to capabilities of the web views, and this limitation is frequently bypassed by various plugins causing different incompatibilities and issues in addition to the existing security and performance concern of UI views. Nevertheless, further developments, improvements, and maintenances of the MDK technology, including its components and client applications, are supported and done by SAP, leaving only the development of a mobile application to SAP’s customers. This fact reduces the development costs and results in significant savings for maintenance, meaning a lower total cost of ownership. Additionally, MDK supports the implementation of different extensions to remove individual needs for specific components.

to stay tuned follow me Sami Lechner or at twitter

more details and help @ SAP Mobile