Moving from android to ios react-native - android

I have an app completed using Android and react-native and I am starting to work on the ios version with react-native. Are there going to be any new road blocks with this change? And is it most likely that I should be able to reuse most - if not all of my react-native code while working on the ios version, Cheers.

Well, the main purpose of react-native is to write "Almost" the same code which for both platforms. However, there are probably going to be several differences in the way, including:
StatusBar
It is probably going to be the first thing that you notice. In Android, you do not need to handle the status bar and the app automatically starts below the status bar, However in IOS, the app starts from the top of the screen, and you will probably see the time and battery in the middle of your header.
you probably need to give a paddingTop to your header or use, "StatusBar" Module from react-native to handle this issue.
https://facebook.github.io/react-native/releases/0.31/docs/statusbar.html
Shadow and Elevation
As you might have noticed, there are some shadow stylings, which do not have any effect on the shape and appearance of your components. In Android devices "Elevation" is used to make an illusion of 3d Effects on layers. However, in IOS you need to use shadow properties such as, shadow radius, shadow color and ... to make a good looking component.
https://facebook.github.io/react-native/docs/shadow-props.html
UI-UX Design
There are some structural differences between Android and IOS platforms, which will result in a slight (or sometimes major) UI-UX differences.
For example, there is no physical back button in iPhones. As a result, you cannot rely on a physical back button and you need to put a go back button on every page.
Additionally, generally speaking, IOS apps do not have a drawer, and you need to think about this.
Several modules are built specifically for one platform, such as datepickerios. The original picker in IOS platform is a smooth wheelpicker, and the datepicker is also different with android, so u have to have these modules in mind.
Moreover, if you installed any other npm modules, check their github page to see, if there is any special guide on linking and usage in different platforms
Ps. I think it is better to take a look at the app and check for possible bugs, then try to have on eye on API sections in the react-native web page for platform specific codes.

Yes you can reuse most of your js code. If you are using native libraries you will have to run "react-native link" to link with the native code.

Related

What does building each pixel mean in flutter terms

I have started learning flutter and reading about it and one thing that comes up, again and again, is that flutter owns every pixel on the screen or every pixel is controlled by flutter but I didn't fully understand what that really means.
Also, What is the opposite of that. I mean what if flutter does not own every pixel on the screen and how would that look like. Is there anything like that already?
I have no deeper knowledge of the topic as I am new to mobile development so maybe someone can explain in simple terms about what all the owning every pixel thing mean?
What that means is, the native world comes with built-in pre-styled components. But Flutter doesn't use them.
Flutter asks the native platform a "Canvas", and then recreate these native components by drawing by itself on that canvas.
The consequences are that Flutter is not bound by the restrictions of the platform. We can have Cupertino components on Android, or Material design before Android 4.0.0.
This also means that your typical Android debug tool won't work. If you activate Android's layout debugging on a Flutter app, you won't see much.

Dynamically alter App Icon on iOS and Android

I'm fairly new to Flutter but have found that it fits most of my design needs for iOS and Android. But, I've been unable to find a way to dynamically change the app icon.
In Swift, you were able to change the app icon from inside the actual app allowing for some pretty neat customization. A Medium article discussed this back when it first came out for iOS 10.3.
Does anybody know of any way to do this in Flutter, or will I need to make a custom package to do this?
https://medium.com/flutter-community/programatically-change-ios-app-icon-in-flutter-c9e84bc541a2
Maybe this would help. Here's a plugin too.
https://pub.dev/packages/flutter_dynamic_icon
I don't believe this is currently supported, and probably won't be by the flutter team although someone could theoretically write a plugin to do it. However, most of the configuration needs to be done natively anyways, so I don't know how much value the plugin would provide other than doing the call to setAlternateIconName.
What you should do is write the code directly in iOS as you would for a native iOS app, but expose a MethodChannel to the dart side which would allow you to control it from flutter.

Is it possible to develop mobile keyboard app in flutter

We want to develop mobile keyboard app - (Third party keyboard) that have some unique features (such translate on the keyboard).
We would like to know if there is a way to developed it once both for IOS and Android, with Flutter, or any other solution?
There's a long and a short answer to this. The short answer is basically no, it's not feasible at this time to do this.
The long answer is that it may be somewhat possible but with a fairly large amount of work for you to do. You're going to have to first create and appropriate project type in android and ios, and then import the dart code & set up the build. You may be able to start with a normal flutter application and modify the xcode/gradle builds to match the specifics for ios/android, but I'd guess that's somewhat unlikely. So you'll probably still have to maintain two separate projects, but which could import the same dart library for the UI.
Because Android and iOS use different APIs for their keyboards, you're going to need to write a Platform Plugin or at least method channels which communicate between your app and the native code, for each of iOS and Android. You'll also probably have to embed the flutter view yourself - see this example as I'd bet the normal FlutterApplication etc won't apply.
I'd guess that on android you could probably get this to work eventually with a lot of work (depending on how familiar you are with android, platform channels, and integrating libraries such as flutter's into the build); on iOS you might have luck but it's somewhat conceivable that iOS blocks certain features that flutter needs in the keyboard for performance or security reasons - just guessing from my experiences developing apps in native iOS although I haven't done a keyboard specifically.
That being said, if you do try this I'd be interested to hear the results, and if you were to go about it in a somewhat generic way that could be re-used it would be of great benefit to the flutter community!

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.

Porting iPhone App to Android platform

I am trying to get my iPhone App on Android platform as well. I was wondering if there is anyway I can directly port my iPhone App or Code to Android? Do I need to write whole App from the scratch for Android platform or is there anyway I can reduce my work? Thanks.
To the best of my knowledge there is no way to port apps between platforms, and there is no reason you would ever want to. Android and iPhone are two wildly varying platforms both with unique interfaces, api layers, design guidelines and all sorts. Where you would use a navigation bar in iPhone (for instance) with a logo/title in the centre, a back button on the left and other buttons on the right, you would use an action bar in Android with a logo/title on the left hand side and action buttons on the right, possibly with a drop down for extra buttons.
Obviously there are some concepts which are "shared", such as tabbed browsing (although this is being overtaken in android by the dashboard concept and other ways of navigating) you should never port between these two platforms. You should always start from scratch.
Same goes for cross platform frameworks... there is so much that's different and unique about the two platforms that you'd be writing so much platform specific code it wouldn't be worth trying to maintain just one code base.
I believe their isn't a program that ports it for you.
Android is written in Java, however, they also developed an NDK, that is based on C++.
So if you already wrote for the Iphone, then porting it to android with C++ (NDK) is probably easier for you then write it in Java.
You can use 3rd party tools to create apps that work in both. That's what Titanium and PhoneGap were aiming at. With the new changes to the SDK Agreement, those look like they're not really "legal" or at least violate the agreement.
However I am not 100% sure.

Categories

Resources