Within our new mobile development workflow, we noticed that we were encountering many of the same problems we had faced during the development of our web application. On top of these issues, some mobile-specific problems were also identified:
When we initially started developing the application, we relied on a few engineers who were familiar with React Native to perform the testing. This testing was undertaken on engineers' own machines and devices with the aid of mobile device simulators. While this worked for us to begin with, we soon realised that it was not scalable. If we wanted to test on a wider variety of devices and have the ability for other members of the Phlo team to test our application, we would need to find a solution that allowed us to reduce the manual overhead while still being able to test our changes frequently.
Much the same as we did when we faced this problem with the web app, we sought a solution that would allow us to rapidly create a way to test our changes that pointed to an isolated testing environment. After weighing up our options we decided to go with generating an Android APK. Using an APK would allow anyone in the team with an Android device to install the application and run through the changes to verify they all work. Now we had a solution identified, we just needed to figure out how to slot it in with our other processes.
Building on our existing build pipeline in Azure DevOps, we looked for a way to generate an easy to install APK. For this to be a success we needed to:
The first step was generating the APK, we looked to fastlane to help us achieve this as we already had fastlane handling the bundling and deploying of our app to the Google Play Store for internal testing. To do this we created a new release pipeline in Azure DevOps, as with the previous PR environments we just had to ensure this was configured as having a Pull Request trigger. As we had an existing configuration in place we simply needed to add a new lane to our fastlane configuration. In this lane we specified a gradle assemble task for a build type of “staging”, this allowed us to generate an APK that pointed at our testing environments. Using a build type of “staging” ensured the APK couldn’t accidentally be released to the Play Store. Once we had finished configuring this new lane, we just had to add a task to our release pipeline which handled triggering the building of our APK.
Now we had our APK generated, we wanted it to be easily available for download, we looked at the technologies we already use and decided that hosting in a Storage Bucket in GCP would be the easiest to implement and provide us the flexibility we required. Adding some more tasks to the release pipeline we ensured the Google Cloud tools were installed and then ran a command to authenticate using a service account, we were then ready to send our APK over. We wanted to keep the APKs separated so created a folder in our bucket using the PR ID, this was conveniently available to us as a pipeline variable so we then ran a gsutil cp command to copy the file over.
The APK was now generated and hosted in a GCP bucket but it’s still an inconvenience to have to manually type out a long URL just to download it. We decided the best way to streamline this process would be to add a QR code to the PR. Our first step was finding a library to assist with generating the QR code, we decided upon qrcode to handle this as it provided a handy command-line syntax. Once the QR library was installed on our pipeline, we just had to pass in the URL to our APK and the QR code was created. After running another gsutil copy command we had our QR code hosted on GCP and had our URL for the generated image. Finally, we posted a comment to the PR, embedding the image in the comment so that whenever someone visited the PR they had an easy way of quickly downloading and installing the APK.
After scanning our QR code and installing the APK we were really pleased with how it had all turned out, however, we did notice one thing that was missing, deep linking. As the PR environment that the APK linked to had a dynamic URL, we hadn’t added this host to our Android Manifest file. We did some research and found that injecting build values into the manifest was the best way to achieve this, we declared some variables in our gradle build file and referenced these in the manifest. Our final step was adding a gradle properties file as part of the pipeline, here we set our deep linking URLs using the aforementioned PR ID available to us as a pipeline variable to create the dynamic PR environment URL. Once this was added and the pipeline was re-run we could scan our QR code and install the APK with a full native experience, this made testing much easier for us as we could jump directly into our app from the set password emails we send out at the point of registration.
Once we released the functionality we instantly noticed an uptick in participation in our reviews, as it was easier to test on a real device we could get better and more in-depth feedback and received it much quicker than we had been before. We are still in the early days of our React Native development, but having these processes in place from the beginning is giving us the confidence in our work to keep us moving at the fast pace we are accustomed to here.
We also hope that making the app easier to test will not only improve our development and reviewing of PRs but also give us a wider audience among the team, testing is no longer restricted to a set number of engineers but instead now anyone with an Android device has a quick and easy way to begin testing. The wide variety of skills and expertise we have at Phlo now means that the wider team has the opportunity to offer feedback and suggestions at earlier stages of development, this is leading us to creating a better app for our patients which is always a primary focus for us.
There’s no better time to become part of the Phlo community. Take control of your medication management and join the 1,000s of patients we’ve helped safely manage their medication.
Join us on
