Final App Design
Month 3 Reflection
This semester, we were tasked with developing a mobile application to support the goal of Turtle Up, a non-profit organization seeking to raise money in order to create awareness for sea turtles in Ghana. Originally, we were instructed to develop only the Android application and Team 13 was assigned the iOS application, but our first thought was to find a way to combine our code base in order to get more brains and take the product even further than our client, Dr. Corinne Brion, anticipated. Throughout the semester, that decision has shown itself to be valuable time and time again, and the application is in the status it is in because of it.
To begin the semester, the first major decision towards a finished product was choosing a technology stack that was suitable for mobile applications and supported real-time data ingestion. The reason real time data ingestion was essential was because the original goal of this project was to receive data from physical tracking devices and display the data within the application. This led to our first real road bump, and it couldn’t have happened at a better time. After our initial meeting with the client, we set a meeting date with the Engineering team working on the tracking devices and learned that the devices were not ready for production deployment. This spurred conversion with our client, and the agreed upon consensus was that the two development teams would work together to deliver Turtle Up with a working POC (proof of concept) that would allow the organization to see how they could expect the app to work once the tracking devices were ready for field deployment. With all of these factors in mind, and our desire to combine groups with Team 13 in order to cross-collaborate, after some research we landed on React Native, Go, and Firebase as our technology stack serving as our frontend, backend, and database respectively. We also decided on leveraging some sort of script or cron job that would ping our Firebase with data to simulate object tracking. Once we had decided on a technology stack and a method of simulating the production user experience, the remainder of Month 1 was spent establishing regular opportunities to communicate and collaborate with Team 13 as well as devising a MVP (minimum viable product) that we hoped to achieve by the end of Month 2 development. Once we had agreed on a regular SCRUM style meeting with Team 13, we were able to brainstorm and divide up a product backlog that separated features between the two teams (in accordance with conversations with Professor Lacie Stiffler) while supporting the same goal. Month 1 was very research heavy in order to find tools that could be leveraged to accomplish our eventual goal of a working prototype, and after iterations of collaborative work, we were well on the way to delivering said prototype.
Moving into actual development, which took place in Months 2 and 3, there were numerous wins that carried us closer to the end goal discussed above and numerous losses that created a need to adapt and change directions. From the lens of design, leaving Month 1 we were very confident in our technology decisions and the ability to leverage a number of tools, especially Expo Go and the Firebase SDK. Very early on into development, we realized that these two specific tools were going to be a much greater challenge to work with than anticipated. For example, Firebase makes it very easy to implement login functionality, but it did not play well with Google SSO. Another example would be wanting to set a uniform map element for our map page rather than using the native element, which was not supported by Expo Go and requires a development build. Out of all of our design decisions, those two tools proved to be the most challenging, but they were not the only ones. Google Cloud Console had a bit of a learning curve at first, but after some time familiarizing ourselves with it we were able to deploy our cloud functionality to support our application. Other challenges included persistence across sessions. Initially, we implemented “@react-native-async-storage/async-storage” as recommended by Expo, which even provided initialization code in the logs. However, despite multiple debugging sessions, this approach consistently failed. The persistence library provided by Firebase proved incompatible with async storage in the Expo framework. We pivoted to using Expo’s SecureStore library instead. While SecureStore provides encryption and secure key-value storage on the device—a little excessive for our limited sensitive data requirements, but it effectively solved our persistence issues. We stored both user profile information and authentication tokens in SecureStore to maintain state across app sessions. Token refreshment posed another challenge. Firebase automatically refreshes tokens every hour, which would force users to log out after that period. Despite researching solutions for extending token refreshment, we discovered Google no longer supports this functionality. So, we implemented manual token tracking and refreshment in our codebase to maintain user sessions.
Despite all these challenges, there were many notable wins this semester that will be of great interest to Dr. Corinne Brion and Turtle Up. Notably, we implemented a complete concept of the user shopping experience with Stripe integrated, structured and hardened the Go backend for secure usage by the physical tracking devices, handled multiple forms of user authentication (normal and Google SSO) that persists across sessions, designed an interactive map page that shows current turtle locations as well as historical temporal data, and dynamically pulled Turtle Up content (podcast and blog) for users to access within the application. Throughout Month 2, we worked our hardest to set the stage for the features described above in our pursuit of the MVP, and in Month 3 we were able to hammer out loose ends and add layers of sophistication to make the application more “production” ready. Working in tandem with Team 13, we were able to accomplish our goals for our MVP at the conclusion of Month 2 and deliver a level of nuance to our application in Month 3 that we believe encapsulates the requests of our client.
Retrospective
This semester was full of learning, there was never a moment where there was not something to learn that could help us with meeting our goals. The biggest lessons we learned as a team is the importance of adaptability while maintaining clear focus on the goal and how to professionally collaborate and communicate with other developers and a customer. Without adaptability, progress would have been stalled by the previously mentioned challenges, especially the ones with our design choices. Though frustrating that something we anticipated being a solution out of the box did not work as we hoped in the context of our mobile application, we persevered and found alternative methods that allowed us to avoid having to make any design changes months into development. Looking back, there are design changes that would have potentially been of great service to us, which teaches us to not get too attached to one way of implementation. Even still, the lesson in adapting to meet the needs of the problems we were faced with due to design was a great one that will carry well into the future. In terms of project management and software development life cycle, one of the biggest takeaways is the necessity for clear communication. Without communication, it is impossible to know the status of other’s work, assist where help is needed, and keep a clear heading.
This semester in particular was much harder than the Fall semester in terms of maintaining healthy and regular practices of inner-team communication. As we moved through Month 2 and 3, life very much got in the way of our team communication. Though we were still meeting regularly with Team 13, it got difficult to find an extended period of time where we as a group could meet. Whether it be job interviews, startup projects, engagements, etc. there were a number of things that we had to work diligently to fight against and make time to discuss our progress and work as a team. Outside of inner team communication and meetings, there were moments where discussions with our client left us more confused than reassured by our progress. However, this was actually a huge learning experience as it challenged us to not only ask more questions but also professionally back our work. Namely, there were instances where the client was giving the impression that they wanted to change direction and we had to work on how to best understand where they were coming from while also standing firm on our work and communicating what we had done.
All in all, this semester gave us the opportunity to grow as rising engineers and professionals. Looking back on the semester, the one area that we would go back and make a change would be more intentional collaboration as Team 12. Though we worked well with Team 13 and with one another, there were definitely times where we were operating as a remote team. This is becoming more common in the modern workplace, but it would have been more beneficial to us as a team to meet in person and for an intentional amount of time. Other than collaboration, we would say that we would spend more time learning the requirements of our client to better understand their needs and the long-term goals for the application. That being said, we feel confident that we met the needs of our client and Turtle Up as a whole. Overall, this semester has been full of learning and we are eager to take the skills developed within the context of CPS 491 and apply them to solving real world problems.