After having our Capstone Project specs given to us, my team and I set forth figuring out the project plan. Going through the requirements, I was pretty content with what we had put forth as a plan. It all seems very actionable, and some early potential blockers were identified to make mental note of. After everyone got up to speed on the way ahead, it was now time to get to the actual development of the project itself.
First order of business was to set up my dev environment. I haven’t used React Native before, and so setting up my VS Code to handle React Native snippets and debugging tools was the very first step. This wasn’t difficult at all. Second step was setting up the tools for test deployments of our app. I’ve taken the Mobile course at OSU, and I remember Flutter being really annoying to set up in terms of the emulator etc. A fear of mine was that the emulator would also be heavy on my system, as it was in Mobile. I didn’t much enjoy developing on a laptop that struggled when the Android Emulator kicked in. Much to my pleasant surprise, there is a service called Expo, and it is absolutely brilliant. It allows me to test my app, right on my phone, and all I need to do is start my app in VS Code, scan the QR Code given, and it takes me to a dev environment on my phone, launching my app on my iPhone. The fact that I can develop in Windows, and run the app on my iPhone impressed me so much with what Expo has done.
This whole process was not without it’s challenges however. I came to discover that my way of launching the app on my dev laptop wasn’t playing nice with how the Expo app on my iPhone would like to detect said environment. Long story short, the instance wasn’t loading on my phone. This is where documentation and StackOverflow came to save the day. I was able to discover that a new feature in the latest NodeJS release was nonexistent in the version I was running. And furthermore, the way my wifi and routers were set up, I would have to set up a tunnel, implemented with a specific launch command in terminal. After learning about these two things, and making the relevant changes, voila, the app loaded on my phone.
After setting up my dev environment, it was time to get into actually building the app itself. A teammate had already created the baseline structure for one of our screens, and so I took the opportunity to flesh it out some more, and getting familiar with React Native. This is where another pleasant surprise came to light. I came to discover that React Native, though obviously similar to React itself, was also very easy to grasp, especially if you have prior React knowledge, which I do. In hindsight, the teams decision to go with React Native as our framework, and not using Flutter like some of us did in Mobile, is one that I think the team will be very happy with. I know for myself I am pleased with what I am seeing with React Native thus far and am looking forward to putting it through its paces.
As for what’s next, well, a team meeting is coming up in the next few minutes, and I’ll keep you all posted come the next blog. Thanks for reading.
Andrew Vo
