Overview
The airline sector is required to reduce CO2 emissions to 2005 levels by 2050. Fuel Matrix had developed an algorithm to help operators to optimise fuel loads – resulting in substantial savings in both operational costs and CO2 emissions.
The implementation and delivery of the Fuel Matrix algorithm was managed by 4DConcepts who designed a generic data driven form creation and submission application and database to meet the needs of the form process in Fuel Matrix.
The Problem
4DConcepts had the idea to turn this into a mobile application and had the capability to create the backend web services and databases but needed technical help in creating the app UI for iOS and this is where DrupalCentric came in.
The Challenge
App Interface
We were tasked with building the application interface dynamically, which isn’t as straightforward as it sounds. On the one hand, there was no need for complicated algorithms or unknown libraries. On the other hand, we had to thoroughly plan the structure of the client’s interaction with the server.
Project Management
The project kicked off with the general idea and a one page project description. The back-end service and API for mobile clients was created by the client. This gave us the foundation to work from to start preparing the changes and readjustments in our work processes.
Offline Access
The app had to incorporate the ability to work offline without any internet connection, retaining important data for future use.
The Solution
Work Processes
Our process of work was a set of iterations including the implementation – development of the API’s, integration to the mobile client at this stage – revealing inaccuracies or finding better approaches for particular elements of the business logic, then discussions of issues with the team, API amendments, once again integration on the client’s side and so on.
Offline Access
We also needed to make the app accessible for users without an internet connection. It was crucial for us to evaluate the whole system to distinguish those modules which were able to work separately from the server and to implement them in the appropriate way.
Agile Workflow
Naturally with this style of work you cannot avoid mistakes or misunderstandings, but the professional approach of all members of the team proved to be effective as we gradually implemented features. In the meantime we were adapting our system to the technical requirements and features list, which was expanding in parallel with the growth in our understanding of how the final product should look.
In the process of the development of the iOS app we used the following technology stack – native iOS SDK, UIKIT for general tasks and implementing UX and UX, CoreData+Magical Record for creation of the model and data storage, Alamofire – library for the work with the network and integrative APIs. Also we used a few extensions for standard classes during the creation of the required features. In fact, we had two key elements – static content, which is identical when displaying the start screens and receiving basic elements from server; and dynamical content, that is the prevailing part of what users see and communicate with.
We have a set of various components that can be used and based on the response from the server we built the UI/UX from these elements and the general chain of interactions, among them – data entry, switching between pages, calculations and upload of data to the server. All of this being unique for each user.
Our solution works in the same way as big constructor kit, it was developed once and we can use predefined blocks for building different complex interfaces with no need for changes to the existing client. It’s all about the content from the server. Naturally, this is not a magic wand, that can do everything, but a preliminary planned set of functionality that can be combined based on business logic.
The Result
We created not only the application for the interaction between the server and client but also full documentation of protocols, model description, API specifications and a demo of how the app works. This documentation enables anyone to easily grasp the apps functionality (for instance, when developing Android client), as well as develop the product further based on the clear structure.
Of course, in an ideal scenario such documentation would already at the outset of the project. The structure of the app uses only live systems, that are developing, are flexible and adaptive to technology, changes and expectations of the end users.
