The client required a web and mobile application which would provide admins with the access to review/approve data on a weekly basis, even when offline.

The apps should also provide the ability to create/update bookings and other information related to aircrafts, customers, employees.

A built-in intercom was to be provided to enable customer support.

Data such as weekly users, flight reports, engineer jobs, invoices & fuel receipts to be viewable on the applications

After the official introduction, the team got the ball rolling. The entire project was split into two as the client required both a web application as well as its mobile counterpart to support it with the end goal of ensuring efficiency of aviation services for both the admin as well as the user. 

One of the primary requirements of the client was the fast delivery of the Admin Panel that was to be implemented, so we chose React with Redux as the preferred tech stack as the framework is highly popular for web development and it is also user friendly. We used JSReport to generate flight reports to ensure accuracy while tracking. Considering the project was of a large-scale, TypeScript was used for its many cross-platform features as well as the other benefits it offers such as better readability, fast refactoring etc. Material UI was chosen as the component library for its compatibility with React. Redux Saga was adopted as the preferred middleware for its superior application management attributes alongside Redux Form which was the tool used for form management in the project.

With the technologies finalised and set in place, the project was divided into multiple milestones where new features were introduced, existing features were improved and QA testing was done to ensure perfection. The first milestone was to design a basic dashboard which could be used by the admin to view weekly data in the form of reports, generated by JSReports Once this was implemented, a feature to display weekly receipts was designed which would allow admins to log in and access data pertaining to weekly steps., which was followed by the implementation of a screen to place billing and fueling systems in, which would grant the admin information about the same for individual flights. The next feature in line was to add an engineer jobs review screen which would show the record of the engineers on payroll. Subsequently, flight report review screens and a screen to create and edit bookings for efficient information management was also implemented. Lastly, we designed a screen which would enable the admins to add or update flight information.

All of these features were also supposed to be translated in a mobile app to promote mobility and enable on-the-go management, hence we proceeded to work on the mobile version of the application simultaneously, which was previously broken down, so the first step was to get it back to form. The features of the mobile app were similar to the web dashboard but a different tech stack was needed to be kept in place to port them to handheld devices. We proceeded to use Flutter for this as per the client’s preference and for its booming popularity in the mobile app development industry while VS Code was the preferred source-code editor. We used SQLite as the database for the app as it had to store records while offline. The first step was to create a feature to access information like basic daily expenses and slight report UI with proper state management. Once this was done, the next step was to set up the sync process which would synchronize the existing information to the cloud. As we reached the next stint, Firebase and Codemagic were integrated for their enhanced application building attributes. The developers on the field worked on enhancing the UI and sync processes to improve the functioning of the application in tandem. Post this, an intercom was set up to enable customer support on-the-go and provisions were made for upgrades for both the Flutter and Firebase versions along with the complete refactoring of the weekly sync process.

As work on both the mobile and web applications progressed, it was time to get started on the Backend. After much consideration, Heroku was chosen as the suitable infrastructure for the deployment of both the server and database. A Heroku pipeline was created for the backend containing two apps. airops-backend-qa (used for testing features internally by GeekAants team) and airops-backend-staging (used actively by client users for their daily activities). It was also decided that the Backend would be built using the Dart framework- Aqueduct (v3.2.1 and Dart 2.7.2). After thorough research, Postgres was used as the database for storing business data while Redis In-Memory Cache was used for maintaining a record of the background choice.

As with the other two phases of the project, milestones were set by the team for the designing of the Backend. Initially, developers integrated a feature where an email with the password would be sent to the user on registration and properties were added for the user to add, update and delete information on the applications along with a provision to upload images through mobile using AWS S3. Post this, endpoints were added for the web to monitor the user’s weekly data and review/approve them. Next, the team worked on a feature to add the functionality of additional flight reports along with endpoints for creating bookings and accessing customer and aircraft information. As the client required an app that could run without much assistance, we also created a feature where notifications would be sent out to users every Sunday and Monday reminding them to fill out the previous week’s data. An additional feature was implemented in the form of a background job processor for exporting reports to Google Drive.

At the end of each sprint, extensive QA testing was done manually to ensure quality and to fix bugs before proceeding to the next step where it would be pushed to the master branch. Throughout the run of the project, we adopted a process of User Acceptance Testing where the client was kept in loop at the end of each sprint. Alongside QA testing, the client would also put the application under rigorous testing and would revert back with any bugs they would encounter which would be fixed by the GeekyAnts team before the next delivery.