Making of Parking Spots🔎- Lessons from creating a React Native app

This article takes a brief look into my first ever React Native (or RN for short) project. I’ll explain the overall architecture of the app, some of the design choices I made, and the issues I encountered. The app is meant for finding cost-free 24-hour parking spots in Helsinki, and you can read the background story in my previous post, if you haven’t done so already.

All of the code is open source, so if you want to check it out for yourself, the links are included at the bottom of this article.

Ready. Set. Park. 🚥

The overall architecture

Client

The client, i.e. the Android app, is built with RN. The app is built for Android version 4.1 and up because RN does not support any Android versions older than 4.1 (Jelly Bean).

Main features of the client are:

• Shows the spots nearest to user first

• Open the chosen spot in Google Maps and navigate there

• I18n support, currently supports English and Finnish languages

• Shows ads via Google AdMob

The app does not use any state management libraries (e.g Redux) because I didn’t see much value in using them for such a small project. The data is fetched from the AWS backend using Apollo GraphQL client.

Now because the app is built using RN, I could in theory have pretty easy iOS support but testing the app on iOS emulator requires a MacOS computer and an Apple Developer Program license, neither of which I have… Sorry, Apple users! 😬 (Though if you are interested in porting the app to iOS, hit me up!)

Backend

The backend is built on top of Amazon’s “serverless” services. It uses API Gateway as a bridge between the client and the Lambda function, which is the GraphQL API. The API queries Amazon’s own NoSQL database, DynamoDB.

More info on how the API was built can be found in my previous article: How to: Easy Serverless AWS GraphQL API

The original data

The data comes from a community-made Google Maps My Map layer, which I exported as a .KML file and then parsed the needed data to the database. The layer and its data were released on a CC-4.0 license.

The city of Helsinki is planning to release an open API for parking data, but the project is behind schedule. When (and if 👀) it will be released, I’ll of course update the app to use the newest and most accurate data :)

Design of the app

The app mimics Google’s own Material Design components and design language but is actually composed of different component libraries that just look similar. In total there are about 10 different component libraries used across the app.

During development, I had a hard time finding a good all-purpose Material Design component library. Eventually, I found a pretty extensive library called ‘react-native-material-ui’. It has a large array of components but the only downside is that the documentation of the components leaves a lot to be desired, as some components didn’t have documentation at all, so I had to look at the source code to find out how the components worked.

Had I been developing for iOS at the same time, I would have tried to find component libraries that offer Material Design and Cupertino looks from the same package. Now some of the libraries I used only offer Material Design looks and were sometimes untested on iOS devices.

Overcoming a mountain of bugs and issues

When I developed the app itself, I ran into numerous RN bugs. Some were as innocent as the development version of the app crashing when taking a screenshot on my Oneplus phone:

While others were more serious, like when generating the signed production .APK file, RN decided that it wanted to add unnecessary permissions to the app:

Then there was the time when geolocation didn’t want to work with high accuracy mode turned on:

So, I think you get the point: RN is buggy, so don’t be surprised when everything doesn’t go as planned.

The important thing to remember is that at the time of publishing this article, RN is on version 0.50. The framework is still relatively young and being actively developed, which for me is reason enough to forgive some of the bigger bugs in the framework.

Aside from RN itself, there were also a few bugs with other popular RN libraries I used, mainly AirBnb’s react-native-maps. Some of the bugs were relatively easy to iron out with a bit of Googling, while some were a bit harder to tackle. But such is the life of a developer. 🐛

All in all, no bug was a complete showstopper. For every bug I encountered, there were a couple of Github issue pages open and a bugfix on the works with a temporary solution for the time being.

React Native vs. Native Native

While developing the app was at times buggy to say the least, I still do feel like using RN is the way to go compared to native development. The sheer ease of use, maintaining one code base for both Android and iOS, large community support, and the whole React architecture are a huge plus for me!

Of course, there is no one true god here, and RN is not always the answer. Some major trade-offs for using RN in my eyes are:

• Optimization, RN and RN components tend not to be as optimized as full native code.

• The occasional bug or two, as described in the previous chapter.

• Dependency management, because there are no perfect all-in-one options for getting that sleek Material Design (or Cupertino!) look, you’ll most likely have to use more than a few different component libraries to achieve same effects compared to Native code components.

• You’ll write a lot more Javascript than Java, hmm… is this a trade-off? 😜

Still all things considered, I think if you already know React, you should definitely try out RN.

On some occasions native development is necessary but for majority of the time — RN will do just fine — especially for simplistic utility apps 🚀.

🔗 Links 🔗

Now, as a final credit, I do have to thank the company I work for, Valuemotive, for having an awesome system in place to encourage hobby projects like this one by sponsoring them on a monthly basis! ❤️