App Anatomy

Overview of the application building blocks

Each app contains the following building blocks:

  • Business objects

  • Tasks

  • Views

  • Components

  • Services

  • Translations

  • Resources

  • Libraries

  • Backend Service

The data consumed from the app can be defined as a set of business object. Each business object has unique name and members

Each business object represents a piece of data, which the app will use. The business object is stored as database table and can be accessed by from the app either by using a lightweight ORM (object relational management) style API or raw sql queries.

While the backend apps read and write the business object directly into the Platform's database , the mobile apps will write and read business objects in the on-device database. The changes in the local on-device database will be automatically sent to the backend, where the can be "merged". This synchronization process happens automatically without a need for the mobile developer to write more code.

The user experience of the app is organized in User Interface tasks or simply tasks. Each task has unique id and set of steps. Each step has associated view (e.g. UI screen ) and can navigate to other step. The navigation path between two steps is defined by a route. A route has unique id and source and target steps. A single view can be reused by in more than one tasks.

A view is a combination of TypeScript class and UI composition defined as html that describes a reusable piece of user interface ( screen ). Dynamics Mobile user interface description is based on Framework7 for the mobile apps and Bootstrap and custom controls for backend aps.

Views can be used in Tasks steps to compose the actual flow of the user experience. The fact that the views can be reused across the tasks allows the developer to easily provide consistent UI across the various application functional areas.

The components are very similar to views - they are combination of TypeScript class and html defining reusable piece of user interface. However, the components are meant to be reused in views, only. A good example of a component is a bottom status bar, showing consistent information across the varios app screens.

The services are classes, which implements logic executed behind the scene and usually used in Views and Components. The difference between a "standard" class and Service class is that the Service class instance will be automatically injected into the views, components and classes which depend on it. See also the Dependency Injection section for more info.

Translations

The app may contain translation files, which specifies set of keys and values for each of the supported languages. The application build process replaces the unique string resources keys across the app files to produce a fully translated app.

Resources

Besides views, components and services, the app can have additional resources like images, CSS, text, JSON and xml files and others.

The success of Node.js lately has something to do with the vast amount of third party NPM modules available as open source packages. Dynamics Mobile SDK allows the developer to include any NPM in their apps, where the stability and licensing of the included NPM lays in the hands of the developer.

The app may contain one special class called BackendService. The BackendService class allows the developer to create code which is run on the server in response to the occurrence of specific system wide events like a predefined interval , external REST API call and others.

Last updated

Dynamics Mobile provided by Mobile Affairs Ltd. | 1712 Sofia, Bulgaria, Alexander Malinov 51 | sales@dynamicsmobile.com