diff --git a/blog/2016/03/24/introducing-hot-reloading.html b/blog/2016/03/24/introducing-hot-reloading.html new file mode 100644 index 00000000000..fefd234ad2b --- /dev/null +++ b/blog/2016/03/24/introducing-hot-reloading.html @@ -0,0 +1,90 @@ +Introducing Hot Reloading – React Native | A framework for building native apps using React
React Nativenext

Recent Posts

Introducing Hot Reloading

March 24, 2016 by Martín Bigio

React Native goal is to give you the best possible developer experience. A big part of it is the time it takes between you save a file and be able to see the changes. Our goal is to get this feedback loop to be under 1 second, even as your app grows.

We got close to this ideal via three main features:

  • Use JavaScript as the language doesn't have a long compilation cycle time.
  • Implement a tool called Packager that transforms es6/flow/jsx files into normal JavaScript that the VM can understand. It was designed as a server that keeps intermediate state in memory to enable fast incremental changes and uses multiple cores.
  • Build a feature called Live Reload that reloads the app on save.

At this point, the bottleneck for developers is no longer the time it takes to reload the app but losing the state of your app. A common scenario is to work on a feature that is multiple screens away from the launch screen. Every time you reload, you've got to click on the same path again and again to get back to your feature, making the cycle multiple-seconds long.

Hot Reloading #

The idea behind hot reloading is to keep the app running and to inject new versions of the files that you edited at runtime. This way, you don't lose any of your state which is especially useful if you are tweaking the UI.

A video is worth a thousand words. Check out the difference between Live Reload (current) and Hot Reload (new).

+ +

If you look closely, you can notice that it is possible to recover from a red box and you can also start importing modules that were not previously there without having to do a full reload.

Word of warning: because JavaScript is a very stateful language, hot reloading cannot be perfectly implemented. In practice, we found out that the current setup is working well for a large amount of usual use cases and a full reload is always available in case something gets messed up.

Hot reloading is available as of 0.22, you can enable it:

  • Open the developper menu
  • Tap on "Enable Hot Reloading"

Implementation in a nutshell #

Now that we've seen why we want it and how to use it, the fun part begins: how does it actually works.

Hot Reloading is built on top of a feature Hot Module Replacement, or HMR. It was first introduced by Webpack and we implemented it inside of React Native Packager. HMR makes the Packager watch for file changes and send HMR updates to a thin HMR runtime included on the app.

In a nutshell, the HMR update contains the new code of the JS modules that changed. When the runtime receives them, it replaces the old modules' code with the new one:

The HMR update contains a bit more than just the module's code we want to change because replacing it, it's not enough for the runtime to pick up the changes. The problem is that the module system may have already cached the exports of the module we want to update. For instance, say you have an app composed by these two modules:

// log.js +function log(message) { + const time = require('./time'); + console.log(`[${time()}] ${message}`); +} + +module.exports = log;
// time.js +function time() { + return new Date().getTime(); +} + +module.exports = time;

The module log, prints out the provided message including the current date provided by the module time.

When the app is bundled, React Native registers each module on the module system using the __d function. For this app, among many __d definitions, there will one for foo:

__d('log', function() { + ... // module's code +});

This invocation wraps each module's code into an anonymous function which we generally refer to as the factory function. The module system runtime keeps track of each module's factory function, whether it has already been executed, and the result of such execution (exports). When a module is required, the module system either provides the already cached exports or executes the module's factory function for the first time and saves the result.

So say you start your app and require log. At this point, neither log nor time's factory functions have been executed so no exports have been cached. Then, the user modifies time to return the date in MM/DD:

// time.js +function bar() { + var date = new Date(); + return `${date.getMonth() + 1}/${date.getDate()}`; +} + +module.exports = bar;

The Packager will send time's new code to the runtime (step 1), and when log gets eventually required the exported function gets executed it will do so with time's changes (step 2):

Now say the code of log requires time as a top level require:

const time = require('./time'); // top level require + +// log.js +function log(message) { + console.log(`[${time()}] ${message}`); +} + +module.exports = log;

When log is required, the runtime will cache its exports and time's one. (step 1). Then, when time is modified, the HMR process cannot simply finish after replacing time's code. If it did, when log gets executed, it would do so with a cached copy of time (old code).

For log to pick up time changes, we'll need to clear its cached exports because one of the modules it depends on was hot swapped (step 3). Finally, when log gets required again, its factory function will get executed requiring time and getting its new code.

HMR API #

HMR in React Native extends the module system by introducing the hot object. This API is based on Webpack's one. The hot object exposes a function called accept which allows you to define a callback that will be executed when the module needs to be hot swapped. For instance, if we would change time's code as follows, every time we save time, we'll see “time changed” in the console:

// time.js +function time() { + ... // new code +} + +module.hot.accept(() => { + console.log('time changed'); +}); + +module.exports = time;

Note that only in rare cases you would need to use this API manually. Hot Reloading should work out of the box for the most common use cases.

HMR Runtime #

As we've seen before, sometimes it's not enough only accepting the HMR update because a module that uses the one being hot swapped may have been already executed and its imports cached. For instance, suppose the dependency tree for the movies app example had a top-level MovieRouter that depended on the MovieSearch and MovieScreen views, which depended on the log and time modules from the previous examples:

If the user access the movies' search view but not the other one, all the modules but MovieScreen would have cached exports. If a change is made to module time, the runtime will have to clear the exports of log for it to pick up time's changes. The process wouldn't finish there: the runtime will repeat this process recursively up until all the parents have been accepted. So, it'll grab the modules that depend on log and try to accept them. For MovieScreen it can bail, as it hasn't been required yet. For MovieSearch, it will have to clear its exports and process its parents recursively. Finally, it will do the same thing for MovieRouter and finish there as no modules depends on it.

In order to walk the dependency tree, the runtime receives the inverse dependency tree from the Packager on the HMR update. For this example the runtime will receive a JSON object like this one:

{ + modules: [ + { + name: 'time', + code: /* time's new code */ + } + ], + inverseDependencies: { + MovieRouter: [], + MovieScreen: ['MovieRouter'], + MovieSearch: ['MovieRouter'], + log: ['MovieScreen', 'MovieSearch'], + time: ['log'], + } +}

React Components #

React components are a bit harder to get to work with Hot Reloading. The problem is that we can't simply replace the old code with the new one as we'd loose the component's state. For React web applications, Dan Abramov implemented a babel transform that uses Webpack's HMR API to solve this issue. In a nutshell, his solution works by creating a proxy for every single React component on transform time. The proxies hold the component's state and delegate the lifecycle methods to the actual components, which are the ones we hot reload:

Besides creating the proxy component, the transform also defines the accept function with a piece of code to force React to re-render the component. This way, we can hot reload rendering code without losing any of the app's state.

The default transformer that comes with React Native uses the babel-preset-react-native, which is configured to use react-transform the same way you'd use it on a React web project that uses Webpack.

Redux Stores #

To enable Hot Reloading on Redux stores you will just need to use the HMR API similarly to what you'd do on a web project that uses Webpack:

// configureStore.js +import { createStore, applyMiddleware, compose } from 'redux'; +import thunk from 'redux-thunk'; +import reducer from '../reducers'; + +export default function configureStore(initialState) { + const store = createStore( + reducer, + initialState, + applyMiddleware(thunk), + ); + + if (module.hot) { + module.hot.accept(() => { + const nextRootReducer = require('../reducers/index').default; + store.replaceReducer(nextRootReducer); + }); + } + + return store; +};

When you change a reducer, the code to accept that reducer will be sent to the client. Then the client will realize that the reducer doesn't know how to accept itself, so it will look for all the modules that refer it and try to accept them. Eventually, the flow will get to the single store, the configureStore module, which will accept the HMR update.

Conclusion #

If you are interested in helping making hot reloading better, I encourage you to read Dan Abramov's post around the future of hot reloading and to contribute. For example, Johny Days is going to make it work with multiple connected clients. We're relying on you all to maintain and improve this feature.

With React Native, we have the opportunity to rethink the way we build apps in order to make it a great developer experience. Hot reloading is only one piece of the puzzle, what other crazy hacks can we do to make it better?

\ No newline at end of file diff --git a/blog/index.html b/blog/index.html new file mode 100644 index 00000000000..7c19ce32585 --- /dev/null +++ b/blog/index.html @@ -0,0 +1,90 @@ +Blog – React Native | A framework for building native apps using React
React Nativenext

Recent Posts

Introducing Hot Reloading

March 24, 2016 by Martín Bigio

React Native goal is to give you the best possible developer experience. A big part of it is the time it takes between you save a file and be able to see the changes. Our goal is to get this feedback loop to be under 1 second, even as your app grows.

We got close to this ideal via three main features:

  • Use JavaScript as the language doesn't have a long compilation cycle time.
  • Implement a tool called Packager that transforms es6/flow/jsx files into normal JavaScript that the VM can understand. It was designed as a server that keeps intermediate state in memory to enable fast incremental changes and uses multiple cores.
  • Build a feature called Live Reload that reloads the app on save.

At this point, the bottleneck for developers is no longer the time it takes to reload the app but losing the state of your app. A common scenario is to work on a feature that is multiple screens away from the launch screen. Every time you reload, you've got to click on the same path again and again to get back to your feature, making the cycle multiple-seconds long.

Hot Reloading #

The idea behind hot reloading is to keep the app running and to inject new versions of the files that you edited at runtime. This way, you don't lose any of your state which is especially useful if you are tweaking the UI.

A video is worth a thousand words. Check out the difference between Live Reload (current) and Hot Reload (new).

+ +

If you look closely, you can notice that it is possible to recover from a red box and you can also start importing modules that were not previously there without having to do a full reload.

Word of warning: because JavaScript is a very stateful language, hot reloading cannot be perfectly implemented. In practice, we found out that the current setup is working well for a large amount of usual use cases and a full reload is always available in case something gets messed up.

Hot reloading is available as of 0.22, you can enable it:

  • Open the developper menu
  • Tap on "Enable Hot Reloading"

Implementation in a nutshell #

Now that we've seen why we want it and how to use it, the fun part begins: how does it actually works.

Hot Reloading is built on top of a feature Hot Module Replacement, or HMR. It was first introduced by Webpack and we implemented it inside of React Native Packager. HMR makes the Packager watch for file changes and send HMR updates to a thin HMR runtime included on the app.

In a nutshell, the HMR update contains the new code of the JS modules that changed. When the runtime receives them, it replaces the old modules' code with the new one:

The HMR update contains a bit more than just the module's code we want to change because replacing it, it's not enough for the runtime to pick up the changes. The problem is that the module system may have already cached the exports of the module we want to update. For instance, say you have an app composed by these two modules:

// log.js +function log(message) { + const time = require('./time'); + console.log(`[${time()}] ${message}`); +} + +module.exports = log;
// time.js +function time() { + return new Date().getTime(); +} + +module.exports = time;

The module log, prints out the provided message including the current date provided by the module time.

When the app is bundled, React Native registers each module on the module system using the __d function. For this app, among many __d definitions, there will one for foo:

__d('log', function() { + ... // module's code +});

This invocation wraps each module's code into an anonymous function which we generally refer to as the factory function. The module system runtime keeps track of each module's factory function, whether it has already been executed, and the result of such execution (exports). When a module is required, the module system either provides the already cached exports or executes the module's factory function for the first time and saves the result.

So say you start your app and require log. At this point, neither log nor time's factory functions have been executed so no exports have been cached. Then, the user modifies time to return the date in MM/DD:

// time.js +function bar() { + var date = new Date(); + return `${date.getMonth() + 1}/${date.getDate()}`; +} + +module.exports = bar;

The Packager will send time's new code to the runtime (step 1), and when log gets eventually required the exported function gets executed it will do so with time's changes (step 2):

Now say the code of log requires time as a top level require:

const time = require('./time'); // top level require + +// log.js +function log(message) { + console.log(`[${time()}] ${message}`); +} + +module.exports = log;

When log is required, the runtime will cache its exports and time's one. (step 1). Then, when time is modified, the HMR process cannot simply finish after replacing time's code. If it did, when log gets executed, it would do so with a cached copy of time (old code).

For log to pick up time changes, we'll need to clear its cached exports because one of the modules it depends on was hot swapped (step 3). Finally, when log gets required again, its factory function will get executed requiring time and getting its new code.

HMR API #

HMR in React Native extends the module system by introducing the hot object. This API is based on Webpack's one. The hot object exposes a function called accept which allows you to define a callback that will be executed when the module needs to be hot swapped. For instance, if we would change time's code as follows, every time we save time, we'll see “time changed” in the console:

// time.js +function time() { + ... // new code +} + +module.hot.accept(() => { + console.log('time changed'); +}); + +module.exports = time;

Note that only in rare cases you would need to use this API manually. Hot Reloading should work out of the box for the most common use cases.

HMR Runtime #

As we've seen before, sometimes it's not enough only accepting the HMR update because a module that uses the one being hot swapped may have been already executed and its imports cached. For instance, suppose the dependency tree for the movies app example had a top-level MovieRouter that depended on the MovieSearch and MovieScreen views, which depended on the log and time modules from the previous examples:

If the user access the movies' search view but not the other one, all the modules but MovieScreen would have cached exports. If a change is made to module time, the runtime will have to clear the exports of log for it to pick up time's changes. The process wouldn't finish there: the runtime will repeat this process recursively up until all the parents have been accepted. So, it'll grab the modules that depend on log and try to accept them. For MovieScreen it can bail, as it hasn't been required yet. For MovieSearch, it will have to clear its exports and process its parents recursively. Finally, it will do the same thing for MovieRouter and finish there as no modules depends on it.

In order to walk the dependency tree, the runtime receives the inverse dependency tree from the Packager on the HMR update. For this example the runtime will receive a JSON object like this one:

{ + modules: [ + { + name: 'time', + code: /* time's new code */ + } + ], + inverseDependencies: { + MovieRouter: [], + MovieScreen: ['MovieRouter'], + MovieSearch: ['MovieRouter'], + log: ['MovieScreen', 'MovieSearch'], + time: ['log'], + } +}

React Components #

React components are a bit harder to get to work with Hot Reloading. The problem is that we can't simply replace the old code with the new one as we'd loose the component's state. For React web applications, Dan Abramov implemented a babel transform that uses Webpack's HMR API to solve this issue. In a nutshell, his solution works by creating a proxy for every single React component on transform time. The proxies hold the component's state and delegate the lifecycle methods to the actual components, which are the ones we hot reload:

Besides creating the proxy component, the transform also defines the accept function with a piece of code to force React to re-render the component. This way, we can hot reload rendering code without losing any of the app's state.

The default transformer that comes with React Native uses the babel-preset-react-native, which is configured to use react-transform the same way you'd use it on a React web project that uses Webpack.

Redux Stores #

To enable Hot Reloading on Redux stores you will just need to use the HMR API similarly to what you'd do on a web project that uses Webpack:

// configureStore.js +import { createStore, applyMiddleware, compose } from 'redux'; +import thunk from 'redux-thunk'; +import reducer from '../reducers'; + +export default function configureStore(initialState) { + const store = createStore( + reducer, + initialState, + applyMiddleware(thunk), + ); + + if (module.hot) { + module.hot.accept(() => { + const nextRootReducer = require('../reducers/index').default; + store.replaceReducer(nextRootReducer); + }); + } + + return store; +};

When you change a reducer, the code to accept that reducer will be sent to the client. Then the client will realize that the reducer doesn't know how to accept itself, so it will look for all the modules that refer it and try to accept them. Eventually, the flow will get to the single store, the configureStore module, which will accept the HMR update.

Conclusion #

If you are interested in helping making hot reloading better, I encourage you to read Dan Abramov's post around the future of hot reloading and to contribute. For example, Johny Days is going to make it work with multiple connected clients. We're relying on you all to maintain and improve this feature.

With React Native, we have the opportunity to rethink the way we build apps in order to make it a great developer experience. Hot reloading is only one piece of the puzzle, what other crazy hacks can we do to make it better?

\ No newline at end of file diff --git a/releases/next/docs/accessibility.html b/releases/next/docs/accessibility.html index 547d42d8364..0ad5f4a3681 100644 --- a/releases/next/docs/accessibility.html +++ b/releases/next/docs/accessibility.html @@ -1,4 +1,4 @@ -Accessibility – React Native | A framework for building native apps using React
React Nativenext

Quick Start

Guides

Guides (iOS)

Guides (Android)

components

apis

Polyfills

Accessibility #

Edit on GitHub

Native App Accessibility (iOS and Android) #

Both iOS and Android provide APIs for making apps accessible to people with disabilities. In addition, both platforms provide bundled assistive technologies, like the screen readers VoiceOver (iOS) and TalkBack (Android) for the visually impaired. Similarly, in React Native we have included APIs designed to provide developers with support for making apps more accessible. Take note, iOS and Android differ slightly in their approaches, and thus the React Native implementations may vary by platform.

Making Apps Accessible #

Accessibility properties #

accessible (iOS, Android) #

When true, indicates that the view is an accessibility element. When a view is an accessibility element, it groups its children into a single selectable component. By default, all touchable elements are accessible.

On Android, ‘accessible={true}’ property for a react-native View will be translated into native ‘focusable={true}’.

<View accessible={true}> +Accessibility – React Native | A framework for building native apps using React
React Nativenext

Quick Start

Community Resources

Guides

Guides (iOS)

Guides (Android)

components

apis

Polyfills

Accessibility #

Edit on GitHub

Native App Accessibility (iOS and Android) #

Both iOS and Android provide APIs for making apps accessible to people with disabilities. In addition, both platforms provide bundled assistive technologies, like the screen readers VoiceOver (iOS) and TalkBack (Android) for the visually impaired. Similarly, in React Native we have included APIs designed to provide developers with support for making apps more accessible. Take note, iOS and Android differ slightly in their approaches, and thus the React Native implementations may vary by platform.

Making Apps Accessible #

Accessibility properties #

accessible (iOS, Android) #

When true, indicates that the view is an accessibility element. When a view is an accessibility element, it groups its children into a single selectable component. By default, all touchable elements are accessible.

On Android, ‘accessible={true}’ property for a react-native View will be translated into native ‘focusable={true}’.

<View accessible={true}> <Text>text one</Text> <Text>text two</Text> </View>

In the above example, we can't get accessibility focus separately on 'text one' and 'text two'. Instead we get focus on a parent view with 'accessible' property.

accessibilityLabel (iOS, Android) #

When a view is marked as accessible, it is a good practice to set an accessibilityLabel on the view, so that people who use VoiceOver know what element they have selected. VoiceOver will read this string when a user selects the associated element.

To use, set the accessibilityLabel property to a custom string on your View:

<TouchableOpacity accessible={true} accessibilityLabel={'Tap me!'} onPress={this._onPress}> diff --git a/releases/next/docs/actionsheetios.html b/releases/next/docs/actionsheetios.html index fe65e9dea26..2b23af0bf7b 100644 --- a/releases/next/docs/actionsheetios.html +++ b/releases/next/docs/actionsheetios.html @@ -1,4 +1,4 @@ -ActionSheetIOS – React Native | A framework for building native apps using React
React Nativenext

Quick Start

Guides

Guides (iOS)

Guides (Android)

components

apis

Polyfills

ActionSheetIOS #

Edit on GitHub

Methods #

static showActionSheetWithOptions(options: Object, callback: Function) #

static showShareActionSheetWithOptions(options: Object, failureCallback: Function, successCallback: Function) #

Display the iOS share sheet. The options object should contain +ActionSheetIOS – React Native | A framework for building native apps using React

React Nativenext

Quick Start

Community Resources

Guides

Guides (iOS)

Guides (Android)

components

apis

Polyfills

ActionSheetIOS #

Edit on GitHub

Methods #

static showActionSheetWithOptions(options: Object, callback: Function) #

static showShareActionSheetWithOptions(options: Object, failureCallback: Function, successCallback: Function) #

Display the iOS share sheet. The options object should contain one or both of:

  • message (string) - a message to share
  • url (string) - a URL to share

NOTE: if url points to a local file, or is a base64-encoded uri, the file it points to will be loaded and shared directly. In this way, you can share images, videos, PDF files, etc.

Examples #

Edit on GitHub
'use strict'; diff --git a/releases/next/docs/activityindicatorios.html b/releases/next/docs/activityindicatorios.html index 593c9ef04bf..57d8a674946 100644 --- a/releases/next/docs/activityindicatorios.html +++ b/releases/next/docs/activityindicatorios.html @@ -1,4 +1,4 @@ -ActivityIndicatorIOS – React Native | A framework for building native apps using React
React Nativenext

Quick Start

Guides

Guides (iOS)

Guides (Android)

components

apis

Polyfills

ActivityIndicatorIOS #

Edit on GitHub

Props #

View props... #

animating bool #

Whether to show the indicator (true, the default) or hide it (false).

color string #

The foreground color of the spinner (default is gray).

hidesWhenStopped bool #

Whether the indicator should hide when not animating (true by default).

onLayout function #

Invoked on mount and layout changes with

{nativeEvent: { layout: {x, y, width, height}}}.

size enum('small', 'large') #

Size of the indicator. Small has a height of 20, large has a height of 36.

Examples #

Edit on GitHub
'use strict'; +ActivityIndicatorIOS – React Native | A framework for building native apps using React
React Nativenext

Quick Start

Community Resources

Guides

Guides (iOS)

Guides (Android)

components

apis

Polyfills

ActivityIndicatorIOS #

Edit on GitHub

Props #

View props... #

animating bool #

Whether to show the indicator (true, the default) or hide it (false).

color string #

The foreground color of the spinner (default is gray).

hidesWhenStopped bool #

Whether the indicator should hide when not animating (true by default).

onLayout function #

Invoked on mount and layout changes with

{nativeEvent: { layout: {x, y, width, height}}}.

size enum('small', 'large') #

Size of the indicator. Small has a height of 20, large has a height of 36.

Examples #

Edit on GitHub
'use strict'; var React = require('react-native'); var { diff --git a/releases/next/docs/alert.html b/releases/next/docs/alert.html index fdbeb102c94..63420f1e6a1 100644 --- a/releases/next/docs/alert.html +++ b/releases/next/docs/alert.html @@ -1,4 +1,4 @@ -Alert – React Native | A framework for building native apps using React
React Nativenext

Quick Start

Guides

Guides (iOS)

Guides (Android)

components

apis

Polyfills

Alert #

Edit on GitHub

Launches an alert dialog with the specified title and message.

Optionally provide a list of buttons. Tapping any button will fire the +Alert – React Native | A framework for building native apps using React

React Nativenext

Quick Start

Community Resources

Guides

Guides (iOS)

Guides (Android)

components

apis

Polyfills

Alert #

Edit on GitHub

Launches an alert dialog with the specified title and message.

Optionally provide a list of buttons. Tapping any button will fire the respective onPress callback and dismiss the alert. By default, the only button will be an 'OK' button.

This is an API that works both on iOS and Android and can show static alerts. To show an alert that prompts the user to enter some information, diff --git a/releases/next/docs/alertios.html b/releases/next/docs/alertios.html index cf98d955a34..7906925b4de 100644 --- a/releases/next/docs/alertios.html +++ b/releases/next/docs/alertios.html @@ -1,4 +1,4 @@ -AlertIOS – React Native | A framework for building native apps using React

React Nativenext

Quick Start

Guides

Guides (iOS)

Guides (Android)

components

apis

Polyfills

AlertIOS #

Edit on GitHub

The AlertsIOS utility provides two functions: alert and prompt. All +AlertIOS – React Native | A framework for building native apps using React

React Nativenext

Quick Start

Community Resources

Guides

Guides (iOS)

Guides (Android)

components

apis

Polyfills

AlertIOS #

Edit on GitHub

The AlertsIOS utility provides two functions: alert and prompt. All functionality available through AlertIOS.alert is also available in the cross-platform Alert.alert, which we recommend you use if you don't need iOS-specific functionality.

AlertIOS.prompt allows you to prompt the user for input inside of an diff --git a/releases/next/docs/android-building-from-source.html b/releases/next/docs/android-building-from-source.html index f5fe3d9691b..2aac3283027 100644 --- a/releases/next/docs/android-building-from-source.html +++ b/releases/next/docs/android-building-from-source.html @@ -1,4 +1,4 @@ -Building React Native from source – React Native | A framework for building native apps using React

React Nativenext

Quick Start

Guides

Guides (iOS)

Guides (Android)

components

apis

Polyfills

Building React Native from source #

Edit on GitHub

You will need to build React Native from source if you want to work on a new feature/bug fix, try out the latest features which are not released yet, or maintain your own fork with patches that cannot be merged to the core.

Prerequisites #

Assuming you have the Android SDK installed, run android to open the Android SDK Manager.

Make sure you have the following installed:

  1. Android SDK version 23 (compileSdkVersion in build.gradle)
  2. SDK build tools version 23.0.1 (buildToolsVersion in build.gradle)
  3. Android Support Repository >= 17 (for Android Support Library)
  4. Android NDK (download & extraction instructions here)

Point Gradle to your Android SDK: either have $ANDROID_SDK and $ANDROID_NDK defined, or create a local.properties file in the root of your react-native checkout with the following contents:

sdk.dir=absolute_path_to_android_sdk +Building React Native from source – React Native | A framework for building native apps using React
React Nativenext

Quick Start

Community Resources

Guides

Guides (iOS)

Guides (Android)

components

apis

Polyfills

Building React Native from source #

Edit on GitHub

You will need to build React Native from source if you want to work on a new feature/bug fix, try out the latest features which are not released yet, or maintain your own fork with patches that cannot be merged to the core.

Prerequisites #

Assuming you have the Android SDK installed, run android to open the Android SDK Manager.

Make sure you have the following installed:

  1. Android SDK version 23 (compileSdkVersion in build.gradle)
  2. SDK build tools version 23.0.1 (buildToolsVersion in build.gradle)
  3. Android Support Repository >= 17 (for Android Support Library)
  4. Android NDK (download & extraction instructions here)

Point Gradle to your Android SDK: either have $ANDROID_SDK and $ANDROID_NDK defined, or create a local.properties file in the root of your react-native checkout with the following contents:

sdk.dir=absolute_path_to_android_sdk ndk.dir=absolute_path_to_android_ndk

Example:

sdk.dir=/Users/your_unix_name/android-sdk-macosx ndk.dir=/Users/your_unix_name/android-ndk/android-ndk-r10e

Building the source #

1. Installing the fork #

First, you need to install react-native from your fork. For example, to install the master branch from the official repo, run the following:

npm install --save github:facebook/react-native#master

Alternatively, you can clone the repo to your node_modules directory and run npm install inside the cloned repo.

2. Adding gradle dependencies #

Add gradle-download-task as dependency in android/build.gradle:

... dependencies { diff --git a/releases/next/docs/android-setup.html b/releases/next/docs/android-setup.html index f46686cdc88..f30a3219787 100644 --- a/releases/next/docs/android-setup.html +++ b/releases/next/docs/android-setup.html @@ -1,4 +1,4 @@ -Android Setup – React Native | A framework for building native apps using React
React Nativenext

Quick Start

Guides

Guides (iOS)

Guides (Android)

components

apis

Polyfills

Android Setup #

Edit on GitHub

This guide describes basic steps of the Android development environment setup that are required to run React Native android apps on an android emulator.

Install Git #

  • On Mac, if you have installed XCode, Git is already installed, otherwise run the following:

    brew install git

  • On Linux, install Git via your package manager.

  • On Windows, download and install Git for Windows. During the setup process, choose "Run Git from Windows Command Prompt", which will add Git to your PATH environment variable.

Install the Android SDK (unless you already have it) #

  1. Install the latest JDK
  2. Install the Android SDK:

Define the ANDROID_HOME environment variable #

IMPORTANT: Make sure the ANDROID_HOME environment variable points to your existing Android SDK: