Hooks and It’s Intricacies.

Thus far the challenges for me regarding the capstone app in terms of React Native really revolve around hooks. More specifically, the useEffect hook. After getting familiar with it on the other screens I was working on, I am now working on a screen that is relatively complex in that it calls useEffect multiple times, with each useEffect relying on the data from the previous useEffect call. And within each, useEffect call, exists an async function. So, a little more involved than just a single easy peasy useEffect call.

After struggling a bit, I’m at the point where I can easily implement two useEffects on a screen page. But for some reason, the third useEffect I need is proving to be problematic. On load screen, for a brief second, it renders properly, but then reverts back to a blank screen. The app gives me a dash of hope, and then takes it away. Thankfully, the third useEffect isn’t a super important one and for now I can do away with it to revisit it later while I work on some back end connectivity stuff, but it’s really perplexing me.

Aside from that, the Expo Go development environment and the tooling around React Native continue to blow my mind. Seeing where the app is at is exciting, and though some of the team members are better at styling, it seems, on their portions, I’ve mainly just been focused on getting the plumbing working and communicating with other screens and the database, but I am pleased with the results. Given where the team and I are at in terms of deliverables, we’re pretty close to getting a lot of the pieces interconnected I feel, and it makes the possibility of pursuing stretch goals all the more feasible it seems. Notwithstanding more technical challenges of course.

The thing that has stood out to me the most in this capstone is that when I do have issues, and given the perhaps not so common issues that might arise, StackOverflow does a good job of bridging some knowledge gaps, but not 100%. There is still a bit of problem solving required to figure out some finer details, and how to implement it on my side for my issue, but the problem solving side has been very rewarding. It feels more like “real” programming versus just a fine narrow spec sheet for a class assignment that is so frequent in this program. All in all, this latest sprint has been pretty good.

Until next time,

Andrew Vo

Reacting to React Native

React Native is great when things come together, but it a slog trying to get reacquainted with things when things don’t come together. During this sprint, my deliverables were implementing a screen which dynamically populated with a users saved wish lists. On selecting a saved wish list, it would then lead to a screen which was a shopping list for said wish list, populating dynamically the screen with the items from that wish list. On the outset, it was clear I was going to have to utilize two different Firestore collections, given how our database was structured. This was easy enough conceptually, but implementing it proved to deliver a variety of challenges.

To preface this, it’s been a while since I had to deal with React, and React Native being a new framework experience for me, these challenges I chalk up to being par for the course for someone getting re-familiarized with React.

First Challenge:

Getting used to how React Native renders it’s components was simple enough initially, and truth be told, I was impressed with how easy they make it to render a FlatList component, which was what I used. The first challenge arose when trying to make that dynamically generated component navigate to a new screen when pressed. Normally (what I eventually learned in trying to get this to work), what happens is that you could use useNavigate() as a hook to navigate to a new screen, but only if in a functional component. My problem was that I wanted to do this in a Class component, which is a no go in React Native. After reading through a bunch of documentation, I discovered that natively, Navigation exists on any screen component, which I was on. After some trial and error passing props.navigation, I eventually got it to redirect to the desired screen after selecting the rendered component.

Second Challenge:

Having a redirect wasn’t sufficient, the component (wish list) selected had to store the list of products, and save it to Async Storage which would be picked up by the other page which we were redirected to. Initially, I tried using useEffect and doing a Firestore collection call within my onPress handler, of course forgetting the lesson I had just learned prior, that you can’t call hooks in a Class component, also forgetting that useEffect was also a hook.

After sitting with it for a while, I just realized I could do a Firestore collection call when I also do the the initial call for the list of wish lists. I could save that result in a variable and just pass it down as a prop into my class component. Which is what I did. There were also a few minor challenges during these two main challenges that were overcome, but in the end it all worked out. The main underlying theme with these challenges was trying to figure out if my logic was wrong, or if it was syntactical errors. Needless to say, I’m happy with the results, and learned(and relearned) a bunch about React & React Native.

Until next time,

Andrew Vo

Dev Environments and New Technologies

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

Kicking Off Capstone

So here I am, in the final leg of this CS degree. It feels a bit surreal, given how much grinding has been involved over the last few years, but it’s also very exciting. What started off as a small idea during my time in previous careers/entrepreneurial endeavors, has finally come to a point where it will become a reality. All those moments of thinking if I only had the knowledge or ability to program so I could solve this really annoying business problem, or develop a tool that would save my business some man hours or expenses have led me to a point where I can solve these problems now. It’s all very encouraging and in hindsight, the decision to pursue a formal degree, is one I’m very pleased with.

During this period of learning, I also came to discover that I’m not much of a front end guy. Not that I don’t like a responsive UI for a better UX, but I enjoy much more being a back-end type developer. It’s something that is more interesting to me overall. This bleeds into my decisions for project choices, and for this Capstone project in particular.

My team and I will be going with making a crowd sourced travel planner. The idea of having anything crowd sourced means that I’ll get to play with data, lots of it. There will be plenty of back-end work to be had with this type of project. It’s also one project where I’m looking forward to learning cross-platform technologies, aiming to get the project to work on different platforms, be it mobile or web.

Though CS344 Smallsh project is the one project I’m most proud of during this degree program, I aim to make this capstone project one that I will be equally proud of. It has a lot of potential to be an app that requires me to get as “full stack” as possible. And I look forward to the challenge.

Until next time,

Andrew Vo