What did we experience while making a mobile app with react-native?
Firefly helps supercharge your drive time with extra income opportunities for rideshare drivers. That’s why we are developing a new app with new features and a new design to help our drivers.
Frankly, we had excited while we were switching from react.js to react-native because we were not experienced with a mobile lifecycle (react-native) :)
Key responsibilities of our app;
- Payment Summary Tracking
- Location Tracking
- Service Scheduling
- Onboarding Customer Process
What is React-Native?
React Native is a mobile app development framework that enables the development of multi-platform Android and iOS apps using native UI elements. It is based on the JavaScriptCore runtime and Babel transformers. With this setup RN supports new JavaScript (ES6+) features, e.g. arrow functions, async/await etc.
Those who are curious and beginning to learn about React may want to know the difference between React and React Native.
ReactJS is a JavaScript library that supports both front-end web and server running for building user interfaces and web applications.
React Native lets you build native mobile apps for different platforms (iOS, Android, and Windows Mobile) that compile native app components and let you use ReactJS in JavaScript to build your components. We can say that you write a single line of code with React Native and you will get 2 different outputs for both android and ios.
What Have We Learned / What are the Differences?
At first, since every phone size and operating system is different, we got a lot of feedback from the QA :) and we made design calculations to cover every phone and adapted them, we don’t have such a problem anymore :). More width, height, padding, margin, etc. we used for Of course, since not every code works on both sides, we wrote different codes depending on the platform by choosing the operating system with the Platform feature provided by react-native. We had a very plain and simple structure. Reading the Documentation was enough for almost everything, so we come up with a nice project without too much fuss.
In some cases, it was necessary to use mobile-specific lifecycles, for example, useFocusedEffect, normally while writing a web application with react.js, useEffect works even when coming back to the page, but this is not always the case on mobile, especially if we keep different pages in a stack and switch between them, the component does not unmount and We were able to handle this situation using useFocusedEffect. Researching and decoding such situations taught us both the mobile lifecycle and react-native.
In general, we did not touch the native sides much, of course, it is necessary to add the configurations for the system permissions on the native sides because we use it from the phone itself.
One of the topics that excited us was OCR (Optical Character Recognition). We solved this case with a library that uses google’s ML(Machine Learning) kit (React Native Mlkit OCR). The biggest reason we chose this package was to move forward and continue with google’s solutions.
There were differences from the web during the deployment phase, of course, we explained below :)
Core Tech Stacks;
Framework: React Native & TypeScript
Navigation: React Navigation
Forms: React Hook Form & Joi
Data Fetching: SWR
Internationalization: i18n
Animations: React Native ReAnimated
App Storage: Async Storage
Push Notification: Firebase
OCR: React Native Mlkit OCR
Unit Testing: React Native Testing Library
Our Folder Structure;
driver-app/
├─ src/
│ ├─ __mock__/
│ ├─ assets/
│ ├─ components/
│ ├─ containers/
│ ├─ hooks/
│ ├─ navigators/
│ ├─ screens/
│ ├─ themes/
│ ├─ translations/
│ ├─ types/
│ ├─ utils/
Deployment Process;
We are using App Center to automate our release process. We created 3 variants as dev, stage, and prod to separate environments. to create variants/schemas, android and ios have separate steps to follow. We used react-native-config and created .env files for each variant/schema to control the variables such as app name, version, API URLs and with this setup, Qa can select the schema/variant which he/she wants to build. Thanks to App center, all builds(apk, aab, or IPA, etc.) can download and test simultaneously without waiting for some kind of store approval. App Center makes it possible to test every task independently from other tasks and continue development without blocking others.
### A task’s life cycle can be seen as below from a deployment perspective: — Development
— PR opened
— QA triggers the build process on the App center via variant/schema selection
— App center notifies relevant team members(Testers, Developers etc.) as it ends
— Download and test the app (App center can test your app at every build if you set up an automated test by the way)
— If some bug has been found on the test we can go back to the development step and iterate the process
— Merge to the master At the end, we can use the master branch to send the app to the store. Just remember to choose prod variant/schema and connect App Center to store.
We tried to explain the processes basically. We hope it was a useful article for you :)
If you have a question, you can send a message to me on LinkedIn.
