Do you recall the many occasions when you safely arrived, say, at the airport, but you forgot to message Mum on your safe arrival, before your departure — only to see several missed calls, expressing her concern? Don't you wish you could've avoided many of these basic, yet, sometimes, headache-inducing scenarios? Enter SafeTrackr: a lightweight, minimalist mobile app that lets you select your destination, your preferred contact(s), and, once the former are finalised, start tracking your journey, where a message will be sent to the recipient(s) upon arrival, without any further input on your end.

Initially, our team was lost with ideas, and we were even considering dabbling with AI at one point, which we then realised was, whilst exciting and novel, impractical given the time-frame. As per the requirements of this project, we had to implement at least 3 new frameworks/ languages; for this reason, we decided to delve into the world of native mobile applications (or 'apps') and pick up React Native as one of our three. Following this, we explored ways in which we could make our app unique to smartphones, such as using the array of device sensors on-the-go, where you usually could not perform this on laptops or PCs. In our findings, we found geolocation to be the most optimal for the purposes of learning and testing, as the data we were working with were just numbers, contrary to having to deal with photos from using the camera on the phone. Sure, we could've gone the extra mile and jumped the hurdle with getting to learn to interact and utilise the camera sensor. However, just like with AI, albeit to a lesser degree, it seemed like too much energy invested into a piece of tech that wouldn't give us a decent enough ROI, especially considering our time limitations, when we also desired to fully develop our app in all aspects, like back-end for example. It wasn't about going so deep into a niche, but rather diversifying our selected tech stack as much as possible and thoroughly developing it, to express ourselves as flexible and as adaptable as possible; specifics such as camera tech can be learned on the spot when needed, however we were squeezed for time and had yet to familiarise ourselves with 3 new pieces of tech, so it just wasn't a priority for us in that specific circumstance. Not to say going with camera tech, or microphone, or other sensors was an objectively wrong pick, just that we as a team personally felt it would've been optimal for us to go down our chosen route. After deciding on a geolocation-based application, we had several ideas, from a TripAdvisor-like app to a socialising app based on users who are in a locality. However, in the end, we were able to relate to not being able to notify our loved ones on arriving in many instances, and decided to go with a geofencing tracker app that would send SMS automatically upon triggering — here SafeTrackr was born!

In the end, we had manifested a fully functional, refined, yet plain app that provided the user the ability to start their journey which would automatically notify selected recipients on arrival, in the most frictionless way possible with what we could output in 3 weeks. A user could: select a contact(s) to notify, select the destination, either through draggable pointer on map or searchbar, select the radius size of the destination (e.g. large radius would be optimal for airport with multiple terminals), an option to save destinations and nickname them, ability to log in/ out, ability to start journey and the ability to send a ping with current location to the recipient at any point in the journey within the app. Overall, we were very happy with this outcome, as we had a user-friendly app that performed the task as desired, in an efficient way, and it refined aesthetically as well as functionally with added features.

We used: React Native, Expo, Android Studio, Java, Firebase Authentication, Firebase Realtime Database.

As explained above, we had a desire to build our app for smartphones, so we rolled with React Native, which was a modern, cross-platform framework to run mobile apps on (although, due to technological limitations, we decided to only pursue Android in the end). Expo was a framework built on React Native, which was very user friendly and made it easy to pick up the new technology; it also came with the expo app, which allowed us develop and run our app more smoothly. Near the end of our project, we decided to 'eject' out of expo, in order to be able to implement our advanced out texting tech, so this involved some Java code. During the majority of our project phase, we relied on using Android Studio's in-built emulator in order to test and run our app, as we encountered some major limitations when running on our own actual devices, such as background processes failing to run entirely, as well as the inconvenience of having to connect and manage an external advice, when the emulator came with none of this.

For the back-end, we have Firebase Authentication and Firebase Realtime Database. The former was used to authenticate user logins whilst the latter was used to hold user data, such as saved contacts and destinations. During spiking, we realised that keeping user data secure was a priority, and Firebase fulfilled this demand of ours quite conveniently as it's robust, secure, and scalable.

After 10 weeks of intense training on our bootcamp, it came to no one's surprise that this was not going to be an easy triumph for us. However, we were still surprised by the perplexing situations we caught ourselves at every step of the way, as going out on our own without support from our mentors and building an app, from planning to programming as we learnt the stack, was somewhat foreign for us — it was down to us now to prove the skills and knowledge we had gained from the bootcamp and to put it to work. One of the biggest hurdles we faced was deeply complex merge conflicts, especially in the last week of the project phase where we had almost all been working individually on branches, and there were some branches that were branched off branches to begin with! Some of these conflicts took days to resolve, however we walked away with strengthened understanding of git, as well as best practices when compartmentalising code into branches, such as branching with intent and after communicating that intent to fellow team members. Other struggles included: getting the emulator to run on some machines, especially as the code became more and more intricate; dealing with background processes on React Native, as background processes are naturally less apparent and more abstract than foreground processes, so this made debugging nightmarish initially, especially whilst learning the language that's being debugged itself; difficulty in trying to implement IOS functionality alongside Android, which seemed possible at first, but then turned out to be impossible due to IOS disallowing the sending of SMS in the background; in order to implement the automatic texting feature, we needed to eject out of Expo into a development build, which made programming a lot more challenging, and, likely due to a configuration fault, as there were several warnings in terminal when starting our app, our app started to take a performance toll on our machines, so much so that half of us were unable to run the app now, however we paired up and overcame that issue relatively quickly.