Having an iOS and android background i struggled working with react native. i had no experience of working in this environment before and i worked with mobile development previously. i shifted to this new environment to develop the mindset of tech skills as a web developer. i was still understanding the mobile ecosystems rules like low memory usage and having battery of users, UI and others.
Nowadays, for many people with native background , its not difficult for them to decide the architecture of their app. these people have set some good options like MVP, MVVM and VIPER (mostly iOS). These people have the following goals in their mind:
- unrelating the supply from business logics
- developing testable applications
- structuring of the app in modules for defining responsibilities
There was no right way decided by google or apple for many years, but 2 years ago google described their take at Google I/O and published a detailed blog ( detailed blog post) about structuring of app according to them and added extensive frameworks to android to support them .
The logic behind this step was to separate screens into their native components, with UI, business logics, networks and storage, all in their own entities. Look at the following diagram:
Most decisions related to architecture comes from FED world as ract native is based on react. It can be difficult for the react native developers initially as the ecosystem is different and decomposed between the different solutions.
After viewing the architecture we come to know that the web is mostly aligned with Flux. The main goal behind this was to develop one directional and predictable flow of data for your app, so it gets easy to understand and debug.
Redux is the best known implementation of flux despite many other implementations .
the application state is kept in Playstore or other stores and any change in store changes the parts of app. Look at the picture below:
the components separate the actions, actions in return do something and update the store which changes the components in a good way. In above diagram differences and similarities can be seen.
let us view the differences and understand their existence and process parallel to them. I use android most of the time but in iOS the fragments can be switched to view controller and have feels like home.
Smart Components = Fragments
As in react native we speak about screens and in react we speak in terms of components. These components are the building units of all screens. A screen has many components and most of them are dumb , some are smart and are connected with the store or query needed by the data.
Some screens have smart components and access their own store with their business logics. for :
This example describes the addition of task screen in the to do list of the application. It contains many smart components like pick location which has its own state or store, user interface states and business logic storage and server API. This helps to develop each part even when there are different teams and have screen which is a dumb container.
The notion of composing your screen into different separate components is also present. Each smart component can be its own part in native. The screen is result of combination of several small components , each of them having its own logic and interactive environment. The logics or the states are taken out of different components, which takes us to the next step.
Actions + Store = ViewModel
This part of component is in charge of all the states of the components and logics related to business and presentation. Its the most important part as it helps in the implementation process. This is the main heart of the application.
By using Redux , we can dispatch the actions and have to wait till any change in store and we check the changes if they are appropriate or not. In each action we can request any network, ask queries related to storage and upgrade the stores. The object named store is global and not attached to any other component life-cycle.
Actions are similar to calling methods in appropriate view models. Store state is in the view model . Any change in the state disturbs the UI and gives benefits of reactivity.
Frameworks like RXjava and RXswift makes reactivity very simple.
Some differences noted are listed below:
The state is private in ViewModel in native, while in Redux the store is global. It has an advantage that when one component can effect another component the UI remains consistent.
Some disadvantages include the leakage of state to other components due to which it can be misused and rely on inside details that should be kept hidden . Also when one component is to be shown on the screen more than once , so updating that store can have issues and screens effect each other causing difficulty in debugging errors . To remove such issues we should decide what must be kept in the store an what not.
Async Storage ≠ Relational DB
Now here lies big differences.
In react we have to use key/value storage , in native we use relational DB solutions. Both approaches have their own advantages and disadvantages so people with DB background find it difficult to work with key/value storages and its hard for them in schema portion.
We can see that initially it seems like recat native was different from native development, but after viewing we came to know that many ideas are similar with small chnages.
While comparing the architectural patterns its seen that in the android trends and is called MVI which aims to bring the flux pattern to native development.
Also Redux is the most used library and most used state management , although there are others like Mobx which brings MVC back to the web.
For mobile developers with native knowledge should take start from react native path, as both have similar goals mainly SOLID principles of software engineering.
Implementation might have some differences ; some are more functional or reactive, some with boilerplate, but mainly they have same goals.