The right choice of navigation is a basis of designing applications on React Native. It largely defines the project structure and the performance. At the moment, there are two types of navigation:
It is implemented using native elements on both iOS and Android and there are two libraries that do this:
The advantages of these navigation libraries are fast performance and ability to display platform-specific navigation elements.
You can get lost in numerous options here and even write your own version with the help of redux. However, the most popular and frequently used is still:
Running the application offline
Just like the "Mobile first" principle works well for the web, the "Offline first" principle dominates in mobile application development.
There are several ways to make your app offline-friendly with React Native:
1. Set the initial state of the application
In React, you can easily implement it in the reducers by specifying the initial state. Besides, you need to define what the user sees if there is no any data.
2. Use a local storage
In React Native, it is AsyncStorage. Here you can store the data that should be available in offline mode, for example, the auth token, so that there is no need to re-login when the user returns to the app next time. You can either set up an access to the repository yourself, or use the Redux Persist library.
3. Track the connection status using NetInfo
In this case, it is important to decide on how the application should behave when there is no network connection:
- the easiest way to notify the user is to show him an alert: react-native-dropdownalert - a plugin that implements an alert for displaying various kinds of notifications: not only about the connection loss, but also about new chat messages, notifications about any successfully or unsuccessfully completed actions.
- react-native-offline - a universal utility for dealing with the application in online/offline mode. Its major features: ability to check Internet access by pinging a specified site at a specified frequency (unlike NetInfo, which detects only network connectivity and doesn't care if Internet access is still available), ability to use this verification in the renderer for choosing the component, ability to add network status to the state, ability to block requests when there is no network in redux or sagas, ability to build and manage the requests queue when the connection is lost. In general, well, this is a library with a very rich functionality.
It is important to understand whether you need to process the user's requests to the server and put them in the queue, which will be dispatched to the server when connection is restored, or ignore all actions and block all requests. The second option is simpler. For the first one, you need to think how to organize the action queue, what to do if there are two similar requests, and how to process these requests on the server in case of conflicts with the current state.
The hardest part about dealing with notifications is to decide how your application should respond to them. Depending on the status of the application, there are 3 variants of notification processing:
1. The application is closed. This is the easiest variant, because when opening an application, all processes are usually started. However in this case (unlike the options below), we can process the notification only if the user has clicked on it, while other notifications are ignored.
2. The application is in the tray/minimized/inactive. In this case, we can process all incoming notifications and, for example, update the counter of new incoming ones without sending the request to the server.
3. The application is open. Here, we are likely to start taking into account the screen that the user is currently seeing. For example, when notifying about a new chat message, the possible options are: the user is on the chat page or on another page. In the first case, you can simply add a message to the chat, in the second - you need to update the counter of unread messages.
Since the notifications are created on the server, it is always possible to decide what data we need for a particular kind of notification. So, depending on the type of the received notification, you can process it differently: split into system and user notifications.