This example will only ever appear to say "Current state is: active" because
the app is only visible to the user when in the active state, and the null
state will happen only momentarily.
'use strict';var React =require('react-native');var{
diff --git a/docs/asyncstorage.html b/docs/asyncstorage.html
index 87aca01997e..490cd28fa9b 100644
--- a/docs/asyncstorage.html
+++ b/docs/asyncstorage.html
@@ -9,7 +9,7 @@ don't want to call this - use removeItem or multiRemove to clear only your
own keys instead.
When your entire codebase respects this convention, you're able to do interesting things like automatically packaging the assets that are being used in your app. Note that in the current form, nothing is enforced, but it will be in the future.
iOS saves multiple sizes for the same image in your Camera Roll, it is very important to pick the one that's as close as possible for performance reasons. You wouldn't want to use the full quality 3264x2448 image as source when displaying a 200x200 thumbnail. If there's an exact match, React Native will pick it, otherwise it's going to use the first one that's at least 50% bigger in order to avoid blur when resizing from a close size. All of this is done by default so you don't have to worry about writing the tedious (and error prone) code to do it yourself.
In React Native, one interesting decision is that the src attribute is named source and doesn't take a string but an object with an uri attribute.
<Image source={{uri:'something.jpg'}}/>
On the infrastructure side, the reason is that it allows to attach metadata to this object. For example if you are using require('image!icon'), then we add an isStatic attribute to flag it as a local file (don't rely on this fact, it's likely to change in the future!). This is also future proofing, for example we may want to support sprites at some point, instead of outputting {uri: ...}, we can output {uri: ..., crop: {left: 10, top: 50, width: 20, height: 40}} and transparently support spriting on all the existing call sites.
On the user side, this lets you annotate the object with useful attributes such as the dimension of the image in order to compute the size it's going to be displayed in. Feel free to use it as your data structure to store more information about your image.
When your entire codebase respects this convention, you're able to do interesting things like automatically packaging the assets that are being used in your app. Note that in the current form, nothing is enforced, but it will be in the future.
iOS saves multiple sizes for the same image in your Camera Roll, it is very important to pick the one that's as close as possible for performance reasons. You wouldn't want to use the full quality 3264x2448 image as source when displaying a 200x200 thumbnail. If there's an exact match, React Native will pick it, otherwise it's going to use the first one that's at least 50% bigger in order to avoid blur when resizing from a close size. All of this is done by default so you don't have to worry about writing the tedious (and error prone) code to do it yourself.
In React Native, one interesting decision is that the src attribute is named source and doesn't take a string but an object with an uri attribute.
<Image source={{uri:'something.jpg'}}/>
On the infrastructure side, the reason is that it allows to attach metadata to this object. For example if you are using require('image!icon'), then we add an isStatic attribute to flag it as a local file (don't rely on this fact, it's likely to change in the future!). This is also future proofing, for example we may want to support sprites at some point, instead of outputting {uri: ...}, we can output {uri: ..., crop: {left: 10, top: 50, width: 20, height: 40}} and transparently support spriting on all the existing call sites.
On the user side, this lets you annotate the object with useful attributes such as the dimension of the image in order to compute the size it's going to be displayed in. Feel free to use it as your data structure to store more information about your image.
NavigatorIOS uses "route" objects to identify child views, their props,
and navigation bar configuration. "push" and all the other navigation
operations expect routes to be like this:
This source code is licensed under the BSD-style license found in the
LICENSE file in the root directory of this source tree. An additional grant
-of patent rights can be found in the PATENTS file in the same directory.
'use strict';var React =require('react-native');var{
diff --git a/docs/textinput.html b/docs/textinput.html
index 26358a5b77b..8b781e73233 100644
--- a/docs/textinput.html
+++ b/docs/textinput.html
@@ -25,7 +25,7 @@ this true, but you will probably see flickering, dropped keystrokes,
and/or laggy typing, depending on how you process onChange events.
The Vibration API is exposed at VibrationIOS.vibrate(). On iOS, calling this
function will trigger a one second vibration. The vibration is asynchronous
so this method will return immediately.
There will be no effect on devices that do not support Vibration, eg. the iOS
-simulator.
'use strict';var React =require('react-native');var{
diff --git a/docs/view.html b/docs/view.html
index fac30555120..f760e2c68dd 100644
--- a/docs/view.html
+++ b/docs/view.html
@@ -34,7 +34,7 @@ for scrolling content when there are many subviews, most of which are
offscreen. For this property to be effective, it must be applied to a
view that contains many subviews that extend outside its bound. The
subviews must also have overflow: hidden, as should the containing view
-(or one of its superviews).
React Native