Table of Contents
For the last 3 months I’ve been working on a very interesting project to create a mobile application.
This application had to be able to handle multiple types of instruments, with the instruments being counted as one instrument in the background, in order to make it easier to work with them.
These instruments are designed to test material composition, especially moisture. The instrument is mainly used to measure the moisture content of soil and concrete. The quality of concrete is important in countries where population density is very high and the quality of buildings is vital, e.g. India. In these countries, the moisture content of concrete is defined by law.
The instrument itself consists of two parts.
- The communication module, which acts as a bridge between the application and the measuring instrument.
- The measuring instrument, which is inserted into the different materials.
How is concrete quality measured?
The client contacted us with the intention of updating their old and outdated applications. The previous solution was two separate applications for two measuring instruments. Since having multiple applications for multiple modules didn’t appeal to us, we decided to bring everything under one umbrella and have one application to control all the instruments.
We received detailed technical documentation with the instruments, describing how to control them via Bluetooth connection. In addition, we received the source code of the previous applications.
- First two weeks
Our first important step was to understand and implement the functionality of the instrumentation in the form of a POC (proof of concept). We then outlined how the measurement process should be built and used this to create the design of the first prototype.
- Second three weeks
After several iterations with the client, we had the design and started to build it. By the end of the second two weeks, the app was capable of running stably on Android and iOS, showing that we had quickly reached the first milestone and presented it to the client. That’s when I felt the project was on track.
- Third two weeks
Based on the feedback from the client, we were making good progress, but there was one point that scared me a little. According to the point, after each measurement, we should disconnect from the instrument. I was reluctant to accept this at the time, as we don’t disconnect from a speaker after every piece of music. That’s when I learned the most important lesson of the project for me. If you are working with an instrument that has a CE certificate, it more than likely describes how to handle the connection. Well, this point was left out at the beginning of the project, so the structure of the code itself didn’t allow for it. So we were forced to make some changes to the way the application worked.
- Fourth three weeks
In the last three weeks, we made design and logical changes, which we concluded with an all-encompassing test.
Challenges and goals
- Create an application that can handle multiple instruments via Bluetooth, regardless of the type of instrument.
- Create an application that is easy and self-explanatory to use.
- To store all measurement data on the instrument, which can be exported to excel sheets.
Solutions
The application was built in React-Native in a hybrid form, which was hosted in a mono repository.
By hybrid form, I mean that we implemented the communication with the instruments in a platform specific way. In Java for Android and Swift for iOS, we managed these APIs via JSI (Javascript Interface). We implemented the management of the instruments in an abstract way, by which I mean that there is a main class in which the basic operations with the instruments are defined. However, there are some operations that depend on the instrument, so we defined these functions as abstract and then added this class to the instrument classes.
Devices
├── DeviceAbstractionLayer.java|swift
├── Device1.java|swift
└── Device2.java|swift
We used Realm database to store the data, which proved to be perfect for this use.
In retrospect, we could have done this in C++, as it would have allowed for more code sharing. But I will keep this in mind in the following.
Lessons
I learned a lot of new things from this project.
From a technical point of view, it was a very interesting project, because I could learn how to communicate effectively with external tools, and how to do it in a platform language.
From a project management point of view, apart from how important communication is and why everything needs to be written down, I learned why I should look for CE certification when working with hardware.
Conclusion
Overall, I gained a lot of new experience from the project, which I will be able to use in the future, both in the project management part and in the technical part.
I have tried to extract the most interesting details of the project life, I hope you find them useful.
See you in the next one,
Best wishes!