React NativeAccessibility
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}’.
Accessibility
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}’.
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:
ActionSheetIOS
Methods #
Edit on GitHubExamples #
ActionSheetIOS
Methods #
Edit on GitHubExamples #
ActivityIndicatorIOS
Edit on GitHubProps #
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.
Edit on GitHubExamples #
ActivityIndicatorIOS
Edit on GitHubProps #
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.
Edit on GitHubExamples #
Alert
Launches an alert dialog with the specified title and message.
Optionally provide a list of buttons. Tapping any button will fire the +
Alert
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,
@@ -146,4 +146,4 @@ module.exports
\ No newline at end of file
+
\ No newline at end of file
diff --git a/docs/alertios.html b/docs/alertios.html
index 3e2979dcdb6..dc5da12b1c3 100644
--- a/docs/alertios.html
+++ b/docs/alertios.html
@@ -1,4 +1,4 @@
- Launches an alert dialog with the specified title and message. Optionally provide a list of buttons. Tapping any button will fire the
+ 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. Use this API for iOS-specific features, such as prompting the user to enter
some information. In other cases, especially to show static alerts, use
@@ -231,4 +231,4 @@ class PromptExample extends
\ No newline at end of file
+
\ No newline at end of file
diff --git a/docs/android-building-from-source.html b/docs/android-building-from-source.html
index e2234fe6879..708a5c51902 100644
--- a/docs/android-building-from-source.html
+++ b/docs/android-building-from-source.html
@@ -1,4 +1,4 @@
- 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. Assuming you have the Android SDK installed, run Make sure you have the following installed: Point Gradle to your Android SDK: either have 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. Assuming you have the Android SDK installed, run Make sure you have the following installed: Point Gradle to your Android SDK: either have Example: First, you need to install Alternatively, you can clone the repo to your Add This guide describes basic steps of the Android development environment setup that are required to run React Native android apps on an android emulator. We don't discuss developer tool configuration such as IDEs here. On Mac, if you have installed XCode, Git is already installed, otherwise run the following: 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 IMPORTANT: Make sure the On Mac, add this to your This guide describes basic steps of the Android development environment setup that are required to run React Native android apps on an android emulator. We don't discuss developer tool configuration such as IDEs here. On Mac, if you have installed XCode, Git is already installed, otherwise run the following: 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 IMPORTANT: Make sure the On Mac, add this to your On Linux, add this to your On Windows, go to NOTE: You need to restart the Command Prompt (Windows) / Terminal Emulator (Mac OS X, Linux) to apply the new Environment variables. React Native Android use gradle as a build system. We recommend to enable gradle daemon functionality which may result in up to 50% improvement in incremental build times for changes in java code. Learn here how to enable it for your platform. Genymotion is much easier to set up than stock Google emulators. However, it's only free for personal use. If you want to use the stock Google emulator, see below. We try our best to deliver buttery-smooth UI performance by default, but sometimes that just isn't possible. Remember, Android supports 10k+ different phones and is generalized to support software rendering: the framework architecture and need to generalize across many hardware targets unfortunately means you get less for free relative to iOS. But sometimes, there are things you can improve (and many times it's not native code's fault at all!). The first step for debugging this jank is to answer the fundamental question of where your time is being spent during each 16ms frame. For that, we'll be using a standard Android profiling tool called systrace. But first... Make sure that JS dev mode is OFF! You should see Systrace is a standard Android marker-based profiling tool (and is installed when you install the Android platform-tools package). Profiled code blocks are surrounded by markers start/end markers which are then visualized in a colorful chart format. Both the Android SDK and React Native framework provide standard markers that you can visualize. NOTE: Systrace support was added in react-native First, connect a device that exhibits the stuttering you want to investigate to your computer via USB and get it to the point right before the navigation/animation you want to profile. Run systrace as follows A quick breakdown of this command: Once the trace starts collecting, perform the animation or interaction you care about. At the end of the trace, systrace will give you a link to the trace which you can open in your browser. After opening the trace in your browser (preferably Chrome), you should see something like this: HINT: Use the WASD keys to strafe and zoom The first thing you should do is highlight the 16ms frame boundaries if you haven't already done that. Check this checkbox at the top right of the screen: You should see zebra stripes as in the screenshot above. If you don't, try profiling on a different device: Samsung has been known to have issues displaying vsyncs while the Nexus series is generally pretty reliable. Scroll until you see (part of) the name of your package. In this case, I was profiling On the left side, you'll see a set of threads which correspond to the timeline rows on the right. There are three/four threads we care about for our purposes: the UI thread (which has your package name or the name UI Thread), This is where standard android measure/layout/draw happens. The thread name on the right will be your package name (in my case book.adsmanager) or UI Thread. The events that you see on this thread should look something like this and have to do with This is where JS is executed. The thread name will be either This is where native module calls (e.g. the If you're using Android L (5.0) and up, you will also have a render thread in your application. This thread generates the actual OpenGL commands used to draw your UI. The thread name will be either A smooth animation should look something like the following: Each change in color is a frame -- remember that in order to display a frame, all our UI work needs to be done by the end of that 16ms period. Notice that no thread is working close to the frame boundary. An application rendering like this is rendering at 60FPS. If you noticed chop, however, you might see something like this: Notice that the JS thread is executing basically all the time, and across frame boundaries! This app is not rendering at 60FPS. In this case, the problem lies in JS. You might also see something like this: In this case, the UI and render threads are the ones that have work crossing frame boundaries. The UI that we're trying to render on each frame is requiring too much work to be done. In this case, the problem lies in the native views being rendered. At this point, you'll have some very helpful information to inform your next steps. If you identified a JS problem, look for clues in the specific JS that you're executing. In the scenario above, we see This doesn't seem right. Why is it being called so often? Are they actually different events? The answers to these questions will probably depend on your product code. And many times, you'll want to look into shouldComponentUpdate. TODO: Add more tools for profiling JS If you identified a native UI problem, there are usually two scenarios: In the first scenario, you'll see a trace that has the UI thread and/or Render Thread looking like this: Notice the long amount of time spent in To mitigate this, you should: If these don't help and you want to dig deeper into what the GPU is actually doing, you can check out Tracer for OpenGL ES. In the second scenario, you'll see something more like this: Notice that first the JS thread thinks for a bit, then you see some work done on the native modules thread, followed by an expensive traversal on the UI thread. There isn't an easy way to mitigate this unless you're able to postpone creating new UI until after the interaction, or you are able to simplify the UI you're creating. The react native team is working on a infrastructure level solution for this that will allow new UI to be created and configured off the main thread, allowing the interaction to continue smoothly. If you are confused or stuck, please post ask on Stack Overflow with the react-native tag. If you are unable to get a response there, or find an issue with a core component, please File a Github issue. We try our best to deliver buttery-smooth UI performance by default, but sometimes that just isn't possible. Remember, Android supports 10k+ different phones and is generalized to support software rendering: the framework architecture and need to generalize across many hardware targets unfortunately means you get less for free relative to iOS. But sometimes, there are things you can improve (and many times it's not native code's fault at all!). The first step for debugging this jank is to answer the fundamental question of where your time is being spent during each 16ms frame. For that, we'll be using a standard Android profiling tool called systrace. But first... Make sure that JS dev mode is OFF! You should see Systrace is a standard Android marker-based profiling tool (and is installed when you install the Android platform-tools package). Profiled code blocks are surrounded by markers start/end markers which are then visualized in a colorful chart format. Both the Android SDK and React Native framework provide standard markers that you can visualize. NOTE: Systrace support was added in react-native First, connect a device that exhibits the stuttering you want to investigate to your computer via USB and get it to the point right before the navigation/animation you want to profile. Run systrace as follows A quick breakdown of this command: Once the trace starts collecting, perform the animation or interaction you care about. At the end of the trace, systrace will give you a link to the trace which you can open in your browser. After opening the trace in your browser (preferably Chrome), you should see something like this: HINT: Use the WASD keys to strafe and zoom The first thing you should do is highlight the 16ms frame boundaries if you haven't already done that. Check this checkbox at the top right of the screen: You should see zebra stripes as in the screenshot above. If you don't, try profiling on a different device: Samsung has been known to have issues displaying vsyncs while the Nexus series is generally pretty reliable. Scroll until you see (part of) the name of your package. In this case, I was profiling On the left side, you'll see a set of threads which correspond to the timeline rows on the right. There are three/four threads we care about for our purposes: the UI thread (which has your package name or the name UI Thread), This is where standard android measure/layout/draw happens. The thread name on the right will be your package name (in my case book.adsmanager) or UI Thread. The events that you see on this thread should look something like this and have to do with This is where JS is executed. The thread name will be either This is where native module calls (e.g. the If you're using Android L (5.0) and up, you will also have a render thread in your application. This thread generates the actual OpenGL commands used to draw your UI. The thread name will be either A smooth animation should look something like the following: Each change in color is a frame -- remember that in order to display a frame, all our UI work needs to be done by the end of that 16ms period. Notice that no thread is working close to the frame boundary. An application rendering like this is rendering at 60FPS. If you noticed chop, however, you might see something like this: Notice that the JS thread is executing basically all the time, and across frame boundaries! This app is not rendering at 60FPS. In this case, the problem lies in JS. You might also see something like this: In this case, the UI and render threads are the ones that have work crossing frame boundaries. The UI that we're trying to render on each frame is requiring too much work to be done. In this case, the problem lies in the native views being rendered. At this point, you'll have some very helpful information to inform your next steps. If you identified a JS problem, look for clues in the specific JS that you're executing. In the scenario above, we see This doesn't seem right. Why is it being called so often? Are they actually different events? The answers to these questions will probably depend on your product code. And many times, you'll want to look into shouldComponentUpdate. TODO: Add more tools for profiling JS If you identified a native UI problem, there are usually two scenarios: In the first scenario, you'll see a trace that has the UI thread and/or Render Thread looking like this: Notice the long amount of time spent in To mitigate this, you should: If these don't help and you want to dig deeper into what the GPU is actually doing, you can check out Tracer for OpenGL ES. In the second scenario, you'll see something more like this: Notice that first the JS thread thinks for a bit, then you see some work done on the native modules thread, followed by an expensive traversal on the UI thread. There isn't an easy way to mitigate this unless you're able to postpone creating new UI until after the interaction, or you are able to simplify the UI you're creating. The react native team is working on a infrastructure level solution for this that will allow new UI to be created and configured off the main thread, allowing the interaction to continue smoothly. If you are confused or stuck, please post ask on Stack Overflow with the react-native tag. If you are unable to get a response there, or find an issue with a core component, please File a Github issue.AlertIOS
AlertIOS
Building React Native from source
Prerequisites #
android to open the Android SDK Manager.build.gradle)build.gradle)$ANDROID_SDK and $ANDROID_NDK defined, or create a local.properties file in the root of your react-native checkout with the following contents:Building React Native from source
Prerequisites #
android to open the Android SDK Manager.build.gradle)build.gradle)$ANDROID_SDK and $ANDROID_NDK defined, or create a local.properties file in the root of your react-native checkout with the following contents:Building the source #
1. Installing the fork #
react-native from your fork. For example, to install the master branch from the official repo, run the following:node_modules directory and run npm install inside the cloned repo.2. Adding gradle dependencies #
gradle-download-task as dependency in android/build.gradle:Android Setup
Install Git #
PATH environment variable. Install the Android SDK (unless you have it) #
brew install android-sdkDefine the ANDROID_HOME environment variable #
ANDROID_HOME environment variable points to your existing Android SDK:~/.bashrc, ~/.bash_profile or whatever your shell uses:Android Setup
Install Git #
PATH environment variable. Install the Android SDK (unless you have it) #
brew install android-sdkDefine the ANDROID_HOME environment variable #
ANDROID_HOME environment variable points to your existing Android SDK:~/.bashrc, ~/.bash_profile or whatever your shell uses:~/.bashrc, ~/.bash_profile or whatever your shell uses:Control Panel -> System and Security -> System -> Change settings -> Advanced -> Environment variables -> New Use gradle daemon #
Configure your SDK #
android); in the window that appears make sure you check:
Install Genymotion #
Alternative: Create a stock Google emulator #
android; in the window that appears make sure you check:android avd and click on Create...
Start...Profiling Android UI Performance
__DEV__ === false, development-level warning are OFF, performance optimizations are ON in your application logs (which you can view using adb logcat)Profiling with Systrace #
Collecting a trace #
v0.15. You will need to build with that version to collect a trace.time is the length of time the trace will be collected in secondssched, gfx, and view are the android SDK tags (collections of markers) we care about: sched gives you information about what's running on each core of your phone, gfx gives you graphics info such as frame boundaries, and view gives you information about measure, layout, and draw passes-a <your_package_name> enables app-specific markers, specifically the ones built into the React Native framework. your_package_name can be found in the AndroidManifest.xml of your app and looks like com.example.appReading the trace #
Enable VSync highlighting #
Find your process #
com.facebook.adsmanager, which shows up as book.adsmanager because of silly thread name limits in the kernel.mqt_js and mqt_native_modules. If you're running on Android 5+, we also care about the Render Thread.UI Thread #
Choreographer, traversals, and DispatchUI:
JS Thread #
mqt_js or <...> depending on how cooperative the kernel on your device is being. To identify it if it doesn't have a name, look for things like JSCall, Bridge.executeJSCall, etc:
Native Modules Thread #
UIManager) are executed. The thread name will be either mqt_native_modules or <...>. To identify it in the latter case, look for things like NativeCall, callJavaModuleMethod, and onBatchComplete:
Bonus: Render Thread #
RenderThread or <...>. To identify it in the latter case, look for things like DrawFrame and queueBuffer:
Identifying a culprit #
JS Issues #
RCTEventEmitter being called multiple times per frame. Here's a zoom-in of the JS thread from the trace above:
Native UI Issues #
Too much GPU work #
DrawFrame that crosses frame boundaries. This is time spent waiting for the GPU to drain its command buffer from the previous frame.renderToHardwareTextureAndroid for complex, static content that is being animated/transformed (e.g. the Navigator slide/alpha animations)needsOffscreenAlphaCompositing, which is disabled by default, as it greatly increases the per-frame load on the GPU in most cases.Creating new views on the UI thread #
Still stuck? #
Profiling Android UI Performance
__DEV__ === false, development-level warning are OFF, performance optimizations are ON in your application logs (which you can view using adb logcat)Profiling with Systrace #
Collecting a trace #
v0.15. You will need to build with that version to collect a trace.time is the length of time the trace will be collected in secondssched, gfx, and view are the android SDK tags (collections of markers) we care about: sched gives you information about what's running on each core of your phone, gfx gives you graphics info such as frame boundaries, and view gives you information about measure, layout, and draw passes-a <your_package_name> enables app-specific markers, specifically the ones built into the React Native framework. your_package_name can be found in the AndroidManifest.xml of your app and looks like com.example.appReading the trace #
Enable VSync highlighting #
Find your process #
com.facebook.adsmanager, which shows up as book.adsmanager because of silly thread name limits in the kernel.mqt_js and mqt_native_modules. If you're running on Android 5+, we also care about the Render Thread.UI Thread #
Choreographer, traversals, and DispatchUI:JS Thread #
mqt_js or <...> depending on how cooperative the kernel on your device is being. To identify it if it doesn't have a name, look for things like JSCall, Bridge.executeJSCall, etc:Native Modules Thread #
UIManager) are executed. The thread name will be either mqt_native_modules or <...>. To identify it in the latter case, look for things like NativeCall, callJavaModuleMethod, and onBatchComplete:Bonus: Render Thread #
RenderThread or <...>. To identify it in the latter case, look for things like DrawFrame and queueBuffer:Identifying a culprit #
JS Issues #
RCTEventEmitter being called multiple times per frame. Here's a zoom-in of the JS thread from the trace above:Native UI Issues #
Too much GPU work #
DrawFrame that crosses frame boundaries. This is time spent waiting for the GPU to drain its command buffer from the previous frame.renderToHardwareTextureAndroid for complex, static content that is being animated/transformed (e.g. the Navigator slide/alpha animations)needsOffscreenAlphaCompositing, which is disabled by default, as it greatly increases the per-frame load on the GPU in most cases.Creating new views on the UI thread #
Still stuck? #