Enterprise Approach to Mobile Applications, Part 3: App Components Interaction

NB: in the following article, we shall assume that we have previously selected cross-platform approach to the development of mobile apps.

Logical Data Flow

When using your corporate mobile application, users interact with different parts of the corporate infrastructure:

• During the login stage, the app sends a request to the corporate mobile servers, which access their own data repository. Upon processing the login request, the response goes back to the application and has to be interpreted in a proper way.
• When the user is interacting with an app, all requests from the app are sent to the app backend.
• Interaction with the push notification service is carried out via a separate channel based on the platform-specific technologies.

This brings us to a deeper level.

Conceptual Diagram

Prior to accessing app functions, a user should go through the authentication process. If the user has correctly entered his username (“jsnow”) and password (“Kn0wsN0th1ng”), the system should be able to determine that the user is indeed Jon Snow. For this purpose, we can use OAuth or any similar technologies.

The server side is usually based on Web API. A common practice is to use one server to rule them both mobile and web applications. This may cause conflicts unless you split web methods for your apps. Thus, web methods, which are visible for the mobile client, should be invisible to the web client, and vice versa.

Besides that, other corporate services may be deployed on customer’s side, such as security services, registration of mobile devices, notifications service, etc. Interaction with them is carried out by means of so-called reusable libraries.

Reusable components

The web and mobile applications can differ a lot! However, considering the aforementioned mechanisms and common infrastructure, some of the components can be reused. This allows minimizing the amount of code, required to invoke the same corporate services from different projects.

The reusable components should always be implemented simultaneously for all platforms. Normally, they require only two operations: integration and configuration. Let’s go through the most popular ones:

• Platform Assurance helps to check if a device is registered in the corporate network and is suitable for the application deployment.
• Version Check ensures that the application is up-to-date. If a newer optional or mandatory update is ready to be deployed, users need to have an option to download this update now or later.
• Maintenance Check is used to receive the availability status update from the app backend and to check if no technical maintenance is carried out.
• Single-Sign-On provides convenient login into the application if a user has already authenticated in the same domain (i.e., the user has successfully entered their login and password in any other corporate application).
• Push Notification Service helps users of a mobile application to stay engaged, with notifications being commonly initiated from app backend or web-application.
• Site Analytics gathers pageflow and user activity statistics (similar to a website analytics). In this case, you need to confirm implementation of the analytics services with the customer in advance.

Now that we are almost ready to assemble our app, we need to make sure that we can track app versions.

Version control

Sharing software modules via floppy discs is always fun. However, modern culture of team development implies newer approaches and standards. Nowadays, in order to track changes in the source code, you’ll need to utilize a Version Control System (VCS).

Moreover, project management methodology has a great impact on the development processes. If your project is Scrum-based, you’ll have to consider how to supply updates or modifications to all previous product versions.

Considering what we said above, the following branching scheme is used in the source code repository:

• Develop is used to assemble internal versions;
• Master is used for assembling versions for the customer.

All developers have their own individual tasks, which are placed in a temporary branch in the “Features” folder. When the task is complete, this branch can be moved to the “Develop” branch.

From there, the source code is moved to the “Master” branch. This allows to automatically track all changes from the previous version, delivered to the customer.

“Releases” folder serves for storage of the already delivered versions of the code.

“Fixes” folder is an equivalent to the “Features” folder, containing temporary branches for fixing defects that are discovered in the already delivered versions of an application.

The only thing left before sending the application to your end users is to test it in various environments.

Testing in Different Environments

The isolated testing environments imitate the company’s infrastructure. However, they can neither influence the infrastructure nor contain real customers’ data.

Below you may find a typical list of the testing environments:

• Dev – is used by developers for their own needs;
• QA – for the developers to conduct their part of testing;
• Staging – for the QA-engineers, working on the customer’s side;
• Loading – for load testing;
• Prod – real world testing.

Testing in multi-layer environments allows detecting and quickly fixing all possible defects, ensuring delivery of reliable and bug-free applications to the end users.

Application Deployment

There are multiple ways to deploy applications to users’ handheld devices. E.g., a developer can assemble an app package and then install it onto the mobile phone. Naturally, this approach is not suitable for app deployment on a scale of the whole enterprise.

In order to assemble applications, a dedicated build server is allocated (e.g., based on Jenkins), with platform-specific and customizable tasks.

Each task consists of the following stages:

• receive an app source code;
• modify app configuration files depending on the selected settings;
• assemble an application;
• sign an application with a certificate;
• send a notification to a project manager with the results.

When, after the rigorous testing, the application is ready to hit production, it is uploaded to the enterprise application center (if available) and can be published in the corresponding services (App Store, Play Market, etc).

We hope you enjoyed our small set of articles on enterprise approach to mobile applications development.

You may still have other questions that were not covered in our blog. Feel free to contact our experts in mobile software development. We are always happy to assist you with all your questions or inquiries!