The popularity of React Native has gripped innovators and developers worldwide. We aren’t spared either. The past few months have steepened our learning curve. As a development team, we have felt it for sure. We learned and dug into React Native, to understand why it has become the “Poster Boy” of app development.

Any kind of knowledge gained, shouldn’t be kept close to one’s chest. Right?

So we recently conducted a Workshop, sharing our understanding with the entire team. The idea behind the workshop was to broadly explain React Native to our development, project management, and marketing teams. A more micro approach will be taken in the upcoming workshops.

People are becoming platform agnostic, and they simply want to explore exciting apps every day. Therefore, today an application needs to be developed rather quickly. A platform like React Native has helped businesses achieve this. But how?

React Native developers can use a single code base for both Android and iOS. This obviously makes life easier for them as there is no need to learn different languages or understand different platforms. Moreover, they can build applications using JavaScript, and provide the look and feel of Native.

No wonder top players like Facebook, Uber, Tesla, and Walmart are resorting to React Native for developing robust mobile apps.

Let’s discuss some of the key points raised during the workshop.

1. React Native Bridge

In general context, a bridge is used to exchange resources between two realms, say a village and a town.

If we talk about React Native, there is a bridge that connects two realms. One is Native which is written in Java, and Obj-C,  and the other one is the application which is written in JavaScript.

If we want to mix Native and React Native components, then there has to be a link for seamless communication. This bridge is that link. It won’t be an exaggeration if we say that this “Bridge” is the heart of React Native’s architecture.

When it comes to information flow, there is not much difference between React Native and React. Their design patterns are similar.

In React, the information is one directional. There is a hierarchy of components, meaning, each component is dependent on its parent and its internal state. Data is passed in a top-down manner, from parent to its children.

If there is an ancestor component that depends on the descendant’s state, then the descendant can update the ancestor using callbacks.

React Native uses the same concept, but only when an app is built purely within the framework, meaning, when there is no mixing with Native components. Therefore, the app can be driven using properties and callbacks.

But if we talk about a scenario when React Native and Native components are mixed, some cross-language mechanisms are required for communication. The bridge allows bidirectional and asynchronous communication between the two realms.

The realm which is written in JavaScript, sends asynchronous JSON messages, directing the Native realm to accomplish specific tasks, and vice-versa.

Communication on the native side

The bridge is built in C/C++ and thus can be run on multiple platforms. This is why the communication on the native side becomes rather easy.

Let’s take the example of the iOS realm, which is written in Obj-C. And what is Obj-C? It’s just an extension of the C language. So what does this imply? That the exchange of information between the bridge and iOS will be organic and smooth.

In the case of Android, Java/Kotlin Native Interface is used to interact with the bridge.

2. Achieving responsive designs with React Native

To achieve responsive designs, React Native style properties accept either percentage or independent pixel (dp) values. But there is a catch. Not all properties accept percentage as value. Properties like margin, border-width, border-radius, and many others fall under this category.

So developers can’t simply make an app responsive by coding everything in percentage.

Now let’s understand Density-Independent Pixels (dp)

Don’t confuse (dp) with the conventional screen pixels (px), to which web developers are more accustomed. The screen’s scale factor is the connecting link between the two. Here’s the equation:

px = dp * scaleFactor

As you can see, the scaleFactor depends on the screen’s pixel density, ie, the number of pixels per inch. So only if different screen sizes have the same number of pixels per inch (ppi), then React Native can scale dp values according to the screen size. But this is not how it works out there, in the smartphone market.

Most of the android phones have different ppi, even if their screen size is the same, or they come from the same manufacturer.

To cut the long story short, (dp) is not the foolproof solution for creating responsive UI with RN.

So what’s the solution, to achieve responsive designs with RN?

The idea is really simple! We need to provide correct (dp) values for different screens dynamically. It can be done emulating the percentage effect.

Two methods can be imported for making React Native views responsive for all devices, namely, widthPercentageToDP and heightPercentageToDP.

Both these methods accept a certain percentage, say 30%’, as an argument, and return the percentage of a screen’s actual width or height respectively in dp.

So if your style process includes these 2 methods, then correct Dp values can be raised for every single device.

3. Hot Reloading and Live Reloading

One of the highlights of React Native is live reloading. If we talk about native languages, to see the final output, you have to wait till the compilation is finished.

With React Native, modifications can be made to an app, without any recompilation. During development, JavaScript code gets loaded from the local server. When the app is released, the code is merged into the app along with other resources. This speeds up UI iterations.

There is another feature called Hot Reloading. It allows a react native developer to inject newer versions of files that they edit, while the app is running. This helps developers in receiving quick feedback on the changes made.

For now, we have used broad strokes to introduce React Native. There is so much more we have learned as a team. We will be sharing all that in the upcoming write-ups. Stay tuned.