Hello Readers, CoolMonkTechie heartily welcomes you in A Short Note Series (Is The Awesome Layers of Apple iOS Architecture Important ?).
In this note series, we’ll learn about Apple iOS Architecture layers. The iOS is the operating system created by Apple Inc. for mobile devices. The iOS is used in many of the mobile devices for apple such as iPhone, iPod, iPad, etc.
So Let’s begin.
Overview
Is The Awesome Layers of Apple iOS Architecture Important? For Which purpose should we understand the Apple iOS Architecture Layers ?
Yes, It is important to understand the different layers of Apple iOS Architecture, because The Apple iOS Architecture is layered. It contains an intermediate layer between the applications and the hardware so they do not communicate directly. The lower layers in iOS provide the basic services, and the higher layers provide the user interface and sophisticated graphics.
The layered architecture of iOS is given:
Layers in AppleiOS Architecture
iOS is a layered architecture comprising 4 different layers:
1. Core OS
The Core OS layer holds the low-level features that most other technologies are built upon. It also interacts directly with the hardware. Most of the functionality provided by the three higher level layers are built upon the Core OS layer and its low-level features. The Core OS layer provides a handful of frameworks that your application can use directly, such as the Accelerate and the Security frameworks. These technologies include Core Bluetooth Framework, External Accessory Framework, Accelerate Framework, Security Service Framework, Local Authorisation Framework, etc.
2. Core Service Layer
This layer provides features such as block objects, Grand Central Dispatch, In-App Purchase, and iCloud Storage. Automatic Reference Counting (ARC) was introduced in this layer, which takes care of all the Memory Management. Core Services layer is also closely tied to the C-based Core Foundation-framework or Core Foundation.
3. Media Layer
A useful layer that provides multimedia services which you can use within your iPhone, and other iOS devices. The Media layer comprises Graphics, Audio, and video. This layer comprises Assets Library, Core Text, Core Graphics, OpenGL ES and OpenAL, AV Foundation and Core Media. This layer is responsible for any kinds of drawing, rendering 2D and 3D data, buffering video, Text layout, etc.
4. Cocoa Touch Layer
It is the topmost layer in the iOS architecture. This layer provides the abstraction of IOS, it is written in Objective–C. It is important, and it contains some key frameworks which are used by native applications. The UIKit framework is the most widely used. Foundation Kit Framework, MapKit, PushKit, EventKit are some other useful frameworks. It defines the basic application management and infrastructure, multitasking support, user interface management, multi-touch support, motion event, etc.
Conclusion
In this note series, we understood the different layers of Apple iOS architecture which is used in many of the apple mobile devices.
Thanks for reading! I hope you enjoyed and learned about Apple iOS architecture Concepts. Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
You can find Other articles of CoolmonkTechie as below link :
Hello Readers, CoolMonkTechie heartily welcomes you in this article.
In this article, we will learn how to secure Mobile application in React Native. We will discuss Security related areas and techniques to secure mobile application. React Native is a popular cross-platform JavaScript framework. Components of React Native apps are rendered in Native UI. In this article, we will focus on the security side of the framework. In this article, we will focus on the security side of the framework.
A famous quote about learning is :
” Develop a passion for learning. If you do, you will never cease to grow.”
So Let’s begin.
Analyzing React Native
React Native has an alternative approach for cross-platform development. Traditionally, Cordova-based frameworks used WebView to render the whole application. In contrast, React Native applications run the JS code in a JavaScript VM based on JavaScriptCore. The application uses native JavaScriptCore on iOS and JavaScriptCore libs are bundled on an APK on Android.
In React Native, the communication between Native and JavaScript code is handled by a JavaScript Bridge. The source JS files are compiled into one single bundle file known as entry file. In development mode, the file is bundled on a local server and fetched by the application. For production, the application logic is usually bundled in a single file, usually “index.android.bundle” or “index.ios.bundle“.
Similarly to Cordova, the bundle file is present in the assets folder and, as also happens with Cordova, we can assume React Native apps as containers that run JS code. This logic is implemented in the expo. Under certain limitations, Expo can run different business logic in a single application. At this moment, it’s fair to assume the entry-file as the core application logic.
Major Sections of Secure Mobile Application
Secure Mobile Application is divided into three sections :
Securing application to server connection
Securing local storage
Advanced integrity checks
1. Securing Application to Server Connection
Usually, smartphone apps communicate with the backend server via APIs. Insecure Communication is highlighted in the OWASP Mobile Top 10 at #3:
” Mobile applications frequently do not protect network traffic. They may use SSL/TLS during authentication but not elsewhere. This inconsistency leads to the risk of exposing data and session IDs to interception. The use of transport security does not mean the app has implemented it correctly. To detect basic flaws, observe the phone’s network traffic. More subtle flaws require inspecting the design of the application and the applications configuration. – M3-Insecure Communication.“
Starting from iOS 9 and Android Pie, SSL is required by default. We can enable cleartext traffic but it’s not recommended. To secure the connection further, we can pin our server certificates.
SSL Pinning in React Native
Apps are dependent on Certificate Authorities (CA) and Domain Name Servers (DNS) to validate domains for TLS. Unsafe certificates can be installed on a user device, thereby opening the device to a Man-in-the-Middle attack. SSL pinning can be used to mitigate this risk.
We use the fetch API or libraries like axios or frisbee to consume APIs in our React Native applications. However, these libraries don’t have support for SSL pinning. Let’s explore the available plugins:
react-native-ssl-pinning: this plugin uses OkHttp3 on Android and AFNetworking on iOS to provide SSL pinning and cookie handling. In this case, we will be using fetch from the library to consume APIs. For this library, we will have to bundle the certificates inside the app. Necessary error handling needs to be implemented in older apps to handle certificate expiry. The app needs to be updated with newer certificates before certificates expire. This library uses promises and supports multi-part form data.
react-native-pinch: this plugin is similar to react-native-ssl-pinning. We have to bundle certificates inside the app. This library supports both promises and callbacks.
To use HPKP (Http Public Key Pinning), we can consider these plugins:
react-native-cert-pinner: this plugin allows us to use public hashes to pin the server. Unlike the plugins above, we can use fetch and other utilities directly. The pinning occurs before native JS is run. Also, there is no requirement to define hashes in the request itself.
react-native-trustkit: this is a wrapper plugin for the iOS Trustkit library. This library is available for iOS only.
2. Securing Local Storage
Normally, we store data inside our application to achieve offline functionality. There are multiple ways to store persistent data in React Native. Async-storage, sqlite, pouchdb and realm are some of the methods to store data.
Insecure storage is highlighted at #2 in the OWASP Mobile Top 10:
” Insecure data storage vulnerabilities occur when development teams assume that users or malware will not have access to a mobile device’s filesystem and subsequent sensitive information in data-stores on the device. Filesystems are easily accessible. Organizations should expect a malicious user or malware to inspect sensitive data stores. Usage of poor encryption libraries is to be avoided. Rooting or jailbreaking a mobile device circumvents any encryption protections. When data is not protected properly, specialized tools are all that is needed to view application data. – M2-Insecure Data Storage. “
Let’s take a look at some plugins which add a layer of security to our application. Also, we will be exploring some plugins which use native security features Keychain and Keystore Access.
SQLite
SQLite is the most common way to store data. A very popular and open-source extension for SQLite encryption is SQLCipher. Data in SQLCipher is encrypted via 256 bit AES which can’t be read without a key. React Native has two libraries that provide SQLCipher:
react-native-sqlcipher-2 : this is a fork of react-native-sqlite-2. We can use pouchdb as an ORM provider with this library, so it’s an additional bonus.
react-native-sqlcipher-storage : this is a fork of react-native-sqlite-storage. The library has to be set up manually since it doesn’t seem to support react-native link. Interestingly, the library is based on the Cordova implementation.
Realm
Realm is a nice alternative database provider to React Native Apps. It’s much faster than SQLite and it has support for encryption by default. It uses the AES256 algorithm and the encrypted realm is verified using SHA-2 HMAC hash.
Keychain and Keystore Access
Both iOS and Android have native techniques to store secure data. Keychain services allows developers to store small chunks of data in an encrypted database. On Android, most plugins use the Android keystore system for API 23(Marshmallow) and above. For lower APIs, Facebook’s conceal provides the necessary crypto functions. Another alternative is to store encrypted data in shared preferences.
React Native has three libraries that provide secure storage along with biometric/face authentication:
React Native KeyChain: As the name implies, this plugin provides access to keychain/keystore. It uses Keychain (iOS), Keystore (Android 23+), and conceal. There is support for Biometric Auth. This plugin has multiple methods and options for both Android and iOS. However, it only allows the storage of the username & password.
React Native Sensitive Info: This plugin is similar to React Native Keychain. It uses Keychain (iOS) and shared preferences (Android) to store data. We can store multiple key-value pairs using this plugin.
RN Secure Storage: This plugin is similar to React Native Sensitive Info. It uses Keychain (iOS), Keystore (Android 23+), and Secure Preferences to store data. We can store multiple key-value pairs.
3. Advanced Integrity Checks
JailMonkey and SafetyNet
Rooted and jailbroken devices should be considered insecure by intent. Root privileges allow users to circumvent OS security features, spoof data, analyze algorithms, and access secured storage. As a rule of thumb, the execution of the app on a rooted device should be avoided.
JailMonkey allows React Native applications to detect root or jailbreak. Apart from that, it can detect if mock locations can be set using developer tools.
SafetyNet is an Android-only API for detecting rooted devices and boot loader unlocks.
react-native-google-safetynet is a wrapper plugin for SafetyNet’s attestation API. It can be used to verify the user’s device.
Additionally, we can use react-native-device-info to check if an app is running in an emulator.
Protecting the Application Logic
Earlier in the article, we mentioned how the application logic in entry-file is available in plain sight. In other words, a third-party can retrieve the code, reverse-engineer sensitive logic, or even tamper with the code to abuse the app (such as unlocking features or violating license agreements).
Protecting the application logic is a recommendation in the OWASP Mobile Top 10. Specifically, the main concerns include code tampering:
” Mobile code runs within an environment that is not under the control of the organization producing the code. At the same time, there are plenty of different ways of altering the environment in which that code runs. These changes allow an adversary to tinker with the code and modify it at will. — M8-Code Tampering. “
And reverse engineering:
” Generally, most applications are susceptible to reverse engineering due to the inherent nature of code. Most languages used to write apps today are rich in metadata that greatly aides a programmer in debugging the app. This same capability also greatly aides an attacker in understanding how the app works. — M9-Reverse Engineering.”
Let’s highlight two different strategies to address this risk.
Hermes
Facebook introduced Hermes with the react-native 0.60.1 release. Hermes is a new JavaScript Engine optimized for mobile apps. Currently, it is only available with Android and it’s usage is optional. Hermes can be used in the project with react-native 0.60.4 by changing the enableHermes flag in build.gradle file.
Its key benefits are improved start-up time, decreased memory usage, and smaller app size. One of the strategies that Hermes uses to achieve this is precompiling JavaScript to bytecode.
Let’s look at a real example. We assume that our entry-file is the one found below:
const {createDecipheriv, createCipheriv, randomBytes} = require('crypto');
const key = Buffer.from('60adba1cf391d89a3a71c72a615cbba8', 'hex');
const algorithm = 'aes-128-cbc';
const softwareVersion = '2.0';
module.exports.createKey = function(userId, expireDate) {
const payload = {
userId,
expireDate,
softwareVersion
};
const json = Buffer.from(JSON.stringify(payload), 'utf8');
const iv = randomBytes(16);
const cipher = createCipheriv(algorithm, key, iv);
let encoded = cipher.update(json);
encoded = Buffer.concat([encoded, cipher.final()]);
const joined = iv.toString('hex') + ';' + encoded.toString('hex');
return Buffer.from(joined, 'utf8').toString('base64');
}
module.exports.validateLicense = function(license, userId) {
const licenseFields = Buffer.from(license, 'base64').toString('utf8');
const fields = licenseFields.split(';');
const iv = Buffer.from(fields[0], 'hex');
const data = Buffer.from(fields[1], 'hex');
const decipher = createDecipheriv(algorithm, key, iv);
let decoded = decipher.update(data);
decoded = Buffer.concat([decoded, decipher.final()]);
const result = JSON.parse(decoded);
if (result.userId != userId) {
throw new Error('Wrong user');
}
if (new Date(result.expireDate) < new Date()) {
throw new Error('Expired license');
}
if (result.softwareVersion != softwareVersion) {
throw new Error('This license is not valid for this program version');
}
return result;
}
After Hermes compiles this file, the resulting bytecode can easily be decompiled using hbcdump and, among the decompiled code, we find some easy to read code look like:
So, while Hermes introduces a certain degree of complexity to the entry-file code, it doesn’t actually conceal the code nor do anything to prevent code tampering, which means that it won’t stop an attacker — let’s not forget that this is not even the purpose of Hermes.
And this leads us to an approach that obfuscates React Native’s JavaScript source code to effectively mitigate the risk of code tampering and reverse engineering: Jscrambler.
Jscrambler
Jscrambler provides a series of layers to protect JavaScript. Unlike most tools that only include (basic) obfuscation, Jscrambler provides three security layers:
Polymorphic JavaScript & HTML5 obfuscation
Code locks (domain, OS, browser, time frame)
Self-defending (anti-tampering & anti-debugging)
By protecting the source code of React Native apps with Jscrambler, the resulting code is highly obfuscated, as can be observed below:
On top of this obfuscation, there’s a Self-Defending layer that provides anti-debugging and anti-tampering capabilities and enables setting countermeasures like breaking the application, deleting cookies, or destroying the attacker’s environment.
That’s all about in this article.
Conclusion
In this article, We learned how to secure Mobile applications in React Native. We discussed about Mobile application security related areas and techniques for React Native . It provides an overview of techniques to help to secure the React Native application. It’s then crucial to create a threat model , and depending on the application’s use case, employ the required measures to ensure that the application is properly secured.
Thanks for reading ! I hope you enjoyed and learned about the Mobile Application Security concepts in React Native. Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe us on this blog and and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
If you have any comments, questions, or think I missed something, feel free to leave them below in the comment box.
Hello Readers, CoolMonkTechie heartily welcomes you in this article.
In this article, we will learn about the React Native 7 effective simple patterns which helps to improve our react native experience during development mode. We will discuss about react native 7 effective simple patterns one by one.
Keep most of components stupid
Rely on callbacks
Keep navigation stack away from views
Keep callbacks chained together
Keep reducers simple and declarative
Keep business logic out of Reducers
Keep platform-specific components to a minimum
A famous quote about Learning is :
” Tell me and I forget, teach me and I may remember, involve me and I learn. “
So Let’s begin.
Pattern 1 : Keep most of components stupid
This is true for any React application. Our views and components should rely on props and callbacks while Container (smart) components should rely on state.
We recommend using Redux, but in some applications we can get away using plain old setState. MobX is a great alternative too.
Pattern 2 : Rely on callbacks
When we learn how to code iOS apps in Swift, we taught to use the delegate pattern to decouple a view from its behavior. In React Native, the same effect can be achieved via callbacks.
Callbacks are simply Arrow Functions which can be passed to a component. The component has the responsibility to execute them, but doesn’t need to know what it’s actually doing.
Most component should not have any behavior. Expose simple callbacks, they are like the public API of our components. We should know when they’ll be executed by reading their names. If we are developing an e-commerce app, for example, names like onSelectProduct or onProductAddedToShoppingCart are very declarative.
When deciding whether to expose a callback or not, every time a component has some kind of user interaction, ask ourself this: ” Is this interaction only important for this particular component, or can it trigger changes in another part of the application? ” If the latter is our answer, then we should expose a callback.
Pattern 3 : Keep navigation stack away from views
For this particular application, we were able to migrate from React Native’s default Navigator, to NavigationExperimental, to React Navigation. Those changes involved a few lines of code.
The idea is simple: Screens and Views are not the same. Our views should not have any knowledge of the Navigation Stack while Screens (or Routes, depending on what name we prefer) must know how to navigate and how to communicate with the Navigation Bar / TabBar. With this approach, our screens will simply wrap the actual Views with navigation-aware things, For example:
As we can see, FavoritesView simply exposes an ‘onSelectFavorite’ callback and doesn’t care about what it actually does. FavoritesScreen uses that callback to tell the navigator to navigate to another screen. Therefore, this gives us the flexibility to replace the way our navigation stack works and provides a nice separation.
Pattern 4 : Keep callbacks chained together
A very common pattern is to inject behavior into callbacks within Higher order Components (that’s what Redux’s mapStateToProps actually does), but many people forget that a public callback may be used in another part of the app (an outer component, for example).
Every time one of our views exposes a callback which may be used in another part of our application (such as, mapStateToProps), first invoke the actual callback passed on props. This enables us to, for example, Navigate to a screen and also fetch some information to feed the next view.
Following the previous example, if FavoritesScreen told FavoritesView to navigate to the FavoriteScreen when selecting a Favorite, Redux would honor that, but also invoke some Redux actions.
As we may see, every realm knows how to handle its stuff: Screens know how to navigate, Connected Views know how to handle redux actions and Views are dumb, stateless and rely on their props.
Pattern 5 : Keep reducers simple and declarative
Any developer should be able to view your reducer’s code and understand what it’s doing. In most cases, having one function per action type can increase readability. For example:
const clear = (favoriteId) => state => ...
const fetching = (favoriteId) => state => ...
const finishFetching = (favoriteId, favorite) => state => ...
export default (state = {}, action) => {
switch (action.type) {
case 'CLEAR_FAVORITE':
return clear(action.favoriteId)(state);
case 'FETCHING_FAVORITE':
return fetching(action.favoriteId)(state);
case 'FINISH_FETCHING_FAVORITE':
return finishFetching(action.favoriteId, action.favorite)(state);
default:
return state;
}
}
Composing reducer functions with many one-line functions can give us greater flexibility and code reuse.
Pattern 6 : Keep business logic out of Reducers
Redux store is not part of business model, it’s a View Model. Treat it like such. Reducer should only impact the store with changes, and we need to be highly confident of them. The less knowledge Reducers have of own business rules, the simpler they’ll become.
It’s not the best approach, but a better one to put business logic in action creators, specially if we use a middleware like Thunk. Sagas and Epics are great too.
Pattern 7 :Keep platform-specific components to a minimum
Every platform has its own Design/UX language and in many cases we have to write different versions of a component. Remember that React Native’s aim is learn once, write anywhere, but first try not to rush into writing platform-specific components.
In many cases, simple Style-changes and conditional operators are enough. we’ve created a simple helper function called platformSpecific which allows me to set styles according to a platform.It’s a really simple function, but incredibly useful. For example :
In this article, We understood the React Native 7 effective simple patterns with the below summary :
Keep most of the components simple and dumb
Expose callback
Keep navigation stack separate from views
Keep callbacks chained together
Reducer code should be simple and declarative form
Application business logic should be separated from Reducer
Platform specific components should be used minimum. Use common components code for different platforms if possible.
Thanks for reading ! I hope you enjoyed and learned about the React Native 7 effective simple patterns. Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe us on this blog and and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
If you have any comments, questions, or think I missed something, feel free to leave them below in the comment box.
Hello Readers, CoolMonkTechie heartily welcomes you in this article.
In this article, we will learn about the React Native Foundation. We will discuss about react native core concepts through examples.
A famous quote about learning is :
” I am still learning. “
So Let’s begin.
What Is React Native ?
React Native is like React, but it uses native components instead of web components as building blocks. So to understand the basic structure of a React Native app, we need to understand some of the basic React concepts, like JSX, components, state, and props.
If we already know React, we still need to learn some React-Native-specific stuff, like the native components.
First of all, we need to import React to be able to use JSX, which will then be transformed to the native components of each platform.
On line 2, we import the Text and View components from react-native.
Then we find the HelloWorldApp function, which is a functional component and behaves in the same way as in React for the web. This function returns a View component with some styles and aText as its child.
The Text component allows us to render a text, while the View component renders a container. This container has several styles applied, let’s analyze what each one is doing.
The first style that we find is flex: 1, the flex prop will define how our items are going to “fill” over the available space along your main axis. Since we only have one container, it will take all the available space of the parent component. In this case, it is the only component, so it will take all the available screen space.
The following style is justifyContent: “center”. This align children of a container in the center of the container’s main axis and finally we have alignItems: “center”, which align children of a container in the center of the container’s cross axis.React Native ships with ES2015 support, so you can use this stuff without worrying about compatibility. import, from, class, and extends in the example above are all ES2015 features.
The other unusual thing in this code example is Hello world!.
This is JSX – a syntax for embedding XML within JavaScript. In React, this is reversed. JSX lets you write your markup language inside code. It looks like HTML on the web, except instead of web things like <div> or <span> you use React components. In this case, <text> is a Core Component that displays some text and View is like the <div> or <span>.
React Native Fundamentals
React Native runs on React, a popular open source library for building user interfaces with JavaScript. To make the most of React Native, it helps to understand React itself.
We’re going to cover the core concepts behind React native :
Components
JSX
props
state
Components
So HelloWorldApp example code is defining HelloWorldApp, a new Component. When we’re building a React Native app, we’ll be making new components a lot. Anything we see on the screen is some sort of component.
JSX
React and React Native use JSX, a syntax that lets we write elements inside JavaScript like so: <Text>Hello, I am your cat!</Text>.
Because JSX is JavaScript, we can use variables inside it. Here we are declaring a name for the cat, name, and embedding it with curly braces inside <Text>.
import React from 'react';
import { Text } from 'react-native';
const Cat = () => {
const name = "Maru";
return (
<Text>Hello, I am {name}!</Text>
);
}
export default Cat;
Because JSX is included in the React library, it won’t work if we don’t have import React from 'react' at the top of our file!
Props
Most components can be customized when they are created, with different parameters. These creation parameters are called props.
Our own components can also use props. This lets us make a single component that is used in many different places in our app, with slightly different properties in each place. Refer to props.{NAME} in our functional components or this.props.{NAME} in our class components. Here’s an example:
Using name as a prop lets us customize the Greeting component, so we can reuse that component for each of our greetings. This example also uses the Greeting component in JSX. The power to do this is what makes React so cool.
The other new thing going on here is the View component. A View is useful as a container for other components, to help control style and layout.
With props and the basic Text, Image, and View components, we can build a wide variety of static screens. To learn how to make our app change over time, we need to learn about State.
State
Unlike props that are read-only and should not be modified, the state allows React components to change their output over time in response to user actions, network responses and anything else. Here’s an example:
First of all, we need to import React to be able to use JSX, which will then be transformed to the native components of each platform.
On line 2, we import the StyleSheet , TouchableOpacity , Text and View components from react-native
In next line , we defines a new class App which extends from React Component .This block of code defines the components that represent the user interface.
After that, we initialize our app state variable count to 0 inside App class using state variable.
After that we create onPress() method where count is incremented by 1 and count value is set in setState() method.
After that Inside render() method that returns a react element , includes:
A return() that returns the result of layout and UI components.
A container View that supports the layout accessibility controls. It is a fundamental component for building the UI.
A TouchableOpacity wrapper is used to reduce the opacity of button. Here, onPress method is called using onPress props.
A React component Text for displaying text.
A property style used for styling the components using StyleSheet class.
A styles is used to design individual components.
After that, the StyleSheet class creates the style object that controls the layout and appearance of components. It is similar to Cascading Style Sheets (CSS) used on the Web.
That’s all about in this article.
Conclusion
In this article, We have discussed about React Native Foundations Concepts like Components,Props and State through example explanations. So we conclude that
Components : Everything is component in React Native.The way in which you create a new component.
Props : Most components can be customized when they are created, with different parameters. These creation parameters are called props.
State : State allows React components to change their output over time in response to user actions, network responses and anything else.
Thanks for reading ! I hope you enjoyed and learned about the React Native Foundation. Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe us on this blog and and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
If you have any comments, questions, or think I missed something, feel free to leave them below in the comment box.
Hello Readers, CoolMonkTechie heartily welcomes you in this article.
In this article, we will learn about the React Native Internal architecture. This article will discuss React Native internal work flow.
A famous quote about learning is :
” Try to learn something about everything and everything about something. “
So, Let’s Start.
Overview
” React Native is a framework which allows developers to build native apps using javascript.”
So What about Cordova Platform and why would anyone want to use React Native?
The Primary difference between React Native and Cordova based app is that
Cordova based apps run inside a Web View.
React Native apps renders using Native View.
React Native Application have direct access to all the native APIs and views offered by the underlying mobile OS. React Native Applications have the same feel and performance as that of a native application.
We can assume that React native might be compiling JS code into respective native code directly. But this would be really hard to achieve since Java and Objective C are strongly typed languages while Javascript is not!
React Native does something much more clever.Essentially React Native uses a set of React components, where each component represents the corresponding native views and components.
For example, a native TextInput will have a corresponding React Native component which can be directly imported into the JS code and used like any other React component. Hence, the developer will be writing the code just like for any other React Web app but the output will be a native application.
To understand this, let us take a look at the architecture and Threading model and how React Native works internally.
Architecture
React Native uses similar architecture for iOS and Android platform. There are three parts to React Native Platform :
1. Native Code/Modules
Most of the native code in case of iOS is written in Objective C or Swift, while in the case of Android it is written in Java. But for writing our React Native app, we would hardly ever need to write native code for iOS or Android.
2. JavaScript VM
The JS Virtual Machine that runs all our JavaScript code. On iOS/Android simulators and devices React Native uses JavaScriptCore, which is the JavaScript engine that powers Safari. JavaScriptCore is an open source JavaScript engine originally built for WebKit.
In case of iOS, React Native uses the JavaScriptCore provided by the iOS platform. It was first introduced in iOS 7 along with OS X Mavericks.
In case of Android, React Native bundles the JavaScriptCore along with the application. This increases the app size. Hence the Hello World application of RN would take around 3 to 4 megabytes for Android.
In case of Chrome debugging mode, the JavaScript code runs within Chrome itself (instead of the JavaScriptCore on the device) and communicates with native code via WebSocket. Here, it will use the V8 engine. This allows us to see a lot of information on the Chrome debugging tools like network requests, console logs, etc.
3. React Native Bridge
React Native bridge is a C++/Java bridge which is responsible for communication between the native and Javascript thread. A custom protocol is used for message passing.
Threading Models
When a React Native application is launched, it spawns up the following threading queues:
1. Main Thread (Native Queue)
Main thread gets spawned when application launches. It loads the app and starts the JS thread to execute the JavaScript code.
The Native thread also listens to the UI events like ‘press’, ‘touch’ etc. These events are then passed to the JS thread via RN Bridge.
Once the Javascript loads, the JS thread sends the information on what needs to be rendered onto the screen.This information is used by a shadow node thread to compute the layout.
The Shadow thread is basically like mathematical engine which finally decides on how to compute the view positions.
These instructions are then passed back to the main thread to render the view.
2. JavaScript Thread (JS Queue)
The Javascript Queue is the thread queue where main bundled JS thread runs.
The JS thread runs all the business logic, i.e., the code we write in React Native.
3. Custom Native Modules
Apart from the threads spawned by React Native, we can also spawn threads on the custom native modules to build to speed up the performance of the application.
For Example – Animations are handled in React Native by a separate native thread to offload the work from the JS thread.
That’s all about in this article.
Conclusion
In this article, We understood about React Native Internal Work Flow. We conclude that React Native work flow based on the threading models and process involved between different threads. We can separate React Native into three Parts :
React Native-Native Side
React Native -JS Side
React Native – Bridge
This is also called “3 Parts of React Native”.
Thanks for reading ! I hope you enjoyed and learned about Internal architecture,Threading Models and Process involved in React Native . Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe us on this blog and and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
If you have any comments, questions, or think I missed something, feel free to leave them below in the comment box.
Hello Readers, CoolMonkTechie heartily welcomes you in A Short Note Series(React Terminology Cheatsheet).
In this note series, we will learn about the commonly used React Terminology and definitions. This article will explain some common terminology from ReactJS.
So, Let’s begin.
Single-page Application – An application that loads a single HTML page and all the necessary assets (such as Javascript and CSS) required for the application to run.
ES6,ES2015,ES2016 – Most recent versions of the ECMAScript Language Specification standard, which is the javascript language is an implementation of.
Compiler – A Javascript compiler takes JavaScript code, transforms it and returns JavaScript code in a different format.
Bundlers – Bundlers takes JavaScript and CSS code written as separate modules and compile them together into a few files better optimized for the browser.
Package Managers – Package Managers are tools that allow you to manage dependencies in your project.
CDN – CDN stands for Content Delivery Network. CDNs deliver cached, static content from a network of servers across the globe.
Elements – React elements are the building blocks of React applications. An elements describes what you want to see on the screen.React elements are immutable.
JSX – Allows us to write HTML like syntax which gets transformed to lightweight Javascript objects.
Virtual DOM – A Javascript representation of the actual DOM.
React.Component – The way in which you create a new component.
render method – Describes what the UI will look like for the particular component.
ReactDOM.render – Renders a React component to a DOM node.
State – The internal data store (Object) of a component.
constructor (this.state) – The way in which you establish the initial state of a component.
setState – A helper method used for updating the state of a component and re-rendering the UI.
props – The data which is passed to the child component from the parent component.
propTypes – Allow you to control the presence or types of certain props passed to the child component.
defaultProps – Allows you set default props for your component.
props.children – Available on every component. It contains the content between the opening and closing tags of a component.
Component Lifecycle
componentDidMount – Fired before the component mounted.
componentWillUnmount – Fired after the component will unmount.
getDerivedStateFromProps – This method fired when the component mounts and whenever the props change. Used to update the state of a component when its props change.
Events
onClick
onSubmit
onChange
Controlled Component – An input form element whose value is controlled by React
Uncontrolled Component – An uncontrolled component works like form elements do outside of React.
Conclusion
In this note series, We understood about the React Terminology Cheatsheet List.
Thanks for reading ! I hope you enjoyed and learned about React Terminology. Reading is one thing, but the only way to master it is to do it yourself.
Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.
You can find Other articles of CoolmonkTechie as below link :
