Develop Reference

How to use Kotlin with React Native in Android Studio?

I want to make an android app using Kotlin for the back end and Android Studio. For the front end, I understand that React Native would be a powerful choice, however I cannot figure out how to add ReactN to my Kotlin project.
I also tried creating a project in ReactN and then adding Kotlin: installed nodejs, npm and create-react-native-app, made the project. Then I tried opening it in Android Studio, but I wasn't getting any options to actually compile and run the project. So another question would be: can you work on ReactN projects in Android Studio or not?
If you could give me some resources on how exactly to do this, or if you can walk me through it step by step, it would be very helpful. I want to mention that I've never developed for Android or Web before (I'm mentioning about Web because I cannot rely on any Reactjs knowledge from Web dev).

React Native is whole framework, for front and back end, and have nothing to do with Kotlin (well, some Kotlin snippets may be integrated into RN app, thats all). RN projects are in fact multiplatform web/js based apps and Kotlin is used for writing pure Android apps, so this isn't a front/back end separation in here, these are just different approaches to development. Mixing both, while possible, makes no sense in most cases

How to migrate a multi-platform app in React Native?

I’ve started to dig into integrating React Native in existing apps, and I mean real industrialized apps (iOS and Android version of a same app) that we wish to refactor with as much RN as we can for bringing code bases together (there is also an existing web version).
We are pretty convinced that including multiple RCTRootView sharing the same bridge is the best approach for us, starting from the basic content views (where sharing code bases is easier and more profitable) and iterating to turn more and more parts of app in RN (Animation, Navigation, …).
But when we’ve investigated this approach, several questions popped out, both technical and organizational.
First of all, although we don’t want to be iOS-first or Android-first, the Android platform doesn’t seem to have the same maturity of the iOS platform for this kind of work. We faced some problems like:
The ReactRootView doesn’t follow the React lifecycle, unlike iOS’s RCTRootView, there is no API to update props : https://github.com/facebook/react-native/issues/6303
It’s impossible to include a ReactRootView inside a native scrollview. This limitation exists from the day one of the Android release (see https://github.com/facebook/react-native/issues/9022)
The following is not really a “problem” but it adds some doubts about the Android support.
The iOS part of the integrating doc clearly mentions that it’s possible to init a view using an existing bridge (initWithBridge, the API is explicit too).
On Android, the same doc mentions that multiple views can share the same ReactInstanceManager, but if you expose 2 components in your bundle and use it, you have to call twice startReactApplication and you’ll see 2 lines in Chrome console
Running application "XXX" with appParams
Running application "YYY" with appParams
Sounds not very optimized to me… Did I really create 2 entire “RN apps” here ?
That being said, we are looking for feedbacks and answers :
About the Android platform, is it reasonable to synchronize the refactor on both platforms or we’d better turn the iOS app into RN and then the Android one ?
How far can we go in RN views displayed simultaneously ? 10, 20 views at a time ?
Our app is “data-oriented”. Is it a good idea to move the data-fetching in a Redux app in the RN world first ? I guess we have to expose data and notify store updates to the native world: what is the most efficient way to do this ? (Native modules makes the communication in the other side easy, native toward RN, but they seem not helpful for this purpose).
Also, how to organize the VCS ? Is moving the 4 code bases (iOS, Android, Web and the RN bundle) in a mono-repository a necessary move ?

Using Sensors on Android with React Native

I'm trying out React Native right now, and I'm wondering if it is possible to use the sensors (Accelerometer, Gyroscope, etc.) on Android, for I know it is possible on iOS.
This repo seems to have most resources involving React Native, but I cannot find one that specifically refers to using the sensors on Android.
https://github.com/jondot/awesome-react-native

I just wrote a package for Android:
https://github.com/kprimice/react-native-sensor-manager

To answer your question as to whether it's possible... yes, everything that is native is also possible with react native. You just might have to roll your own solution, especially now because react-native (especially for android) is so young.
I always check https://react.parts/native to see what components the community has created. I recommend this as your first stop as well.
I found this iOS only package there...
https://github.com/pwmckenna/react-native-motion-manager

React Native & Android?

I'm contemplating on using React Native for a new web app. Is it possible to ship both iOS and Android apps using it?
I know that it's on the roadmap, but it's unclear to me whether it's going to be a separate open-source project (e.g., React Android vs React Native), or just one (e.g., React Native).

TLDR: Most likely you can. But it depends on your use cases.
You can aim for about 80~99+% code reuse (depending on how much Android/iOS native views/modules you use eg. Do you have custom graphics code or low-level TCP networking code; Those can only be done in native code; And expose as API to your JS code. The amount of the platform-specific JS code is actually minimal. Plus you can also use platform check like if (Platform.OS === 'android'){} to solve that) of code reuse, which is pretty nice. Dropbox and other companies have done similar projects: using c++ to build a 'shared' component between iOS and Android project, while implementing most of the UI code in native iOS(Objective-c or swift) and Android(java). But now you are doing C++ with Java and Objective-C or Swift, more language to master, more complexity and more brain juice went down the drain. And it probably took some super tough gymnastic move to make different native code work in both iOS and Android, plus debugging...
React Native just makes it a lot easier to write almost everything in JavaScript. But there is a catch, only about 80% of the JS code could be shared. In the foreseeable future, you still need to write 'platform-specific' JS code for Android and iOS versions.
That's why FB said they aim for 'Learn once, code anywhere' instead of 'run' everywhere.
But it's still very nice other than code reuse(80+% code reuse is still a big improvement comparing to maintaining 2 entirely different versions: Android and iOS ya?)
Cmd +R to refresh the app is a GREAT boost for development speed. Waiting for a big project to compile just makes you felt you were dying inside.
Declarative UI you get for free, because of using React. This is another great plus! As you don't need to 'dig' into your specific UI code that often anymore. Data changed? Just 'flush' it and UI just update accordingly. No brain juice wasted.
I just ported my not so complicated Android React Native App to iOS. And it took me 3 days. The request for and iOS version for the App came as a rather abrupt and unplanned move. So could definitely be even faster had I built the Android with a plan for iOS too. Huge win:)
Another great benefit is able to do hot code push without going through the hellish 1 week app store review process. So no more, "YAY, our app is approved. Let's release. Oh Shiiit. Critical bug and our app keeps crashing(that's gonna keep happening for at least a week before your fix is live). And you have to beg Apple to speed up the process". This is possible because the major part of the code base would be written in JS and with tools like AppHub or CodePush, you could almost instantly deploy code to your users. This is conditionally allowed by Apple.
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code, and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.
Lastly, as an open-source project, project longevity tends to be a concern. Not an issue for React Native. Internally used by(FB Ads Manager) and backed by FB(a dozen FB Engineers?) by Facebook, with close to 500 contributors and 25k Stars, React Native is full of life. Seeing is believing :) (https://github.com/facebook/react-native)
EDIT 1
I realized that I am apparently a bit biased and only talked about the good stuff about React Native. So do checkout https://productpains.com/product/react-native/ and Github issues to have a full picture. It's definitely not silver bullet. That being said, it satisfies most of my use case and I couldn't see me use native iOS or Android anytime soon.
EDIT 2
The Facebook F8 conference app released by Facebook (duh..) is 100% open source and they have a really nice tutorial to show you how you could have both iOS and Android native experience(90% as good as native ?), and at the same time, achieved 85% code re-use. check it out --> https://makeitopen.com
EDIT 3
You may also want to checkout Flutter and its pros & cons :)

It doesn't make sense to have a single codebase if you want a truly native experience. At the moment we have things like NavigatorIOS in React Native which provides an iOS-style UI for navigating between app screens, but if we were to just start using that on Android it wouldn't feel like a true Android app.
Therefore I'd expect to see a NavigatorAndroid component or similar when the time comes, and the same for various other components that behave differently between the platforms.
One benefit that you would get is that any application logic - maybe a store, or your backend interactions - could be written in a JavaScript file and then included by both iOS and Android.
So while you won't get that write-once run-everywhere developer experience from React Native I would expect to see a solution that gives first-class UI on both platforms while encouraging as much reuse as possible. I personally also hope to see strong build tools to help develop and ship on multiple platforms.

React Native for Android has just been released, Android folder will be creating along side with iOS folder upon creating a new project.

Just another tip as NavigatorIOS was mentioned. Facebook are not really maintaining the code for NavigatorIOS. Instead they are focusing on Navigator.

Yes. We're running it in production with about 5m registered users.
Some things are a little behind iOS but catching up quickly. It's a good wagon to be on.

React Native is designed so that you can deploy to both iOS and Android. There is a caveat, of course.
React Native has supported iOS for much longer, coming to Android only recently. So, there are some differences in terms of what is supported on each platform.
For example, if you place borders on Text, they will show up on iOS, but not on Android. In order to overcome this, you need to place a View around the Text, and apply a border to that. Luckily, React Native makes it easy to integrate separate stylesheets for each platform (or even platform-specific styling on a single stylesheet).
Support for Android is continuously evolving, so it will only be a matter of time before React Native for Android is on par with iOS. Nevertheless, this shouldn't deter you. In my experience, it's a great way to quickly develop for both platforms, and it does save some headaches.

you don't need to maintenance separate code base for android & ios. Actually you can use same code base for build android & ios. I recommend to read the react-native documentation(according to react-native version you are using) before using any inbuilt component in your code.
Eg:- TextInput component onKeyPress function supports for ios only.
if ur are using external lib check these lib support for both ios and android.
Anyway you have to configure external lib separately(install) both android and ios.
hope this will helpful.

Titanium compatibility with Android

Will Titanium work properly on all android sdk versions (1.5, 1.6, 2.0, 2.1, 2.2).....

Based on the research I've done, yes, I believe so. I'd recommend trying it out.

Yes it is.
But be warned that while Titanium has its strengths, it also has its weaknesses (ie; memory).
If you're working on a project for a client or are just starting your journey into mobile development, I would recommend learning how to code a native application. At least that gives you some options if you run into troubles. I've been burned a couple of times.

Titanium works with all android SDKs .You just have to make some changes to make it work with all SDKs. Titanium works with sdk 2.1 and below without any changes. But in order to make it work with 2.2 and above you have to add a symbolic link of adb file which is in
platform-tools(source) folder to tools(target).

Occasionally the platform-level support for a particular feature is different between the iOS and Android. For instance, the underlying audio support is significantly better on iOS; many features are simply missing on Android (we eventually patched them ourselves).
In addition, the way that the underlying platform's primitives are wrapped differs, so that code that is correct Javascript will result in incorrect Java on Android. An example we came across was related to the treatment of null and undefined when used with the Ti.App.Properties.setXXX functions. This issues are becoming fewer and farther between, as mentioned, but there are still issues not just related to UI.
I suggest you make a point of continuously developing and testing on both platforms; you'll find incompatibilities (mostly related to leaky abstractions) and their workarounds more easily that way.

Well it works great for the cross platform Execution.
The Only problem is that when user want to compare the iphone version & Android Version by developing same code.
iphone is excellent as per its gesture supports & fine UI works.While Android is still improving the terms.
So you should firstly check your terms and requirement then Go a head with Titanium. OtherWise
Appcelerator consistently working around all the native support as well as common features.
you need to find the possibilities in proposal for the Framework.it will be great approach & future perception as well.