Develop Reference

Multiplatform app development with individual guis

I am currently planning the development of a multiplatform app, and I am not sure wich way to do it fits my requirements best, since all possibilties I could think of failed to satisfy me.
First I want to write an app for android, which should feel like a normal typical android app. So I want to use the standard actionbar and android design look and feel in my other gui elements. After finishing the android app I am planning on developing an ios app, which should have a different design, so i am going to redevelop the gui for this anyway.
But I don´t want to rewrite the other code wich represents the intelligence of the app, independent from the gui. I came up with the following possibilities:
1. Java GUI With native library
Here I abstract all the code of my app in a C++ library (since as far as I know ios supports the usage of c++ libraries too) and develop the gui android typically in java. The library would than have a function to start and would inform the gui about every change via callback functions.
Pro
I can reuse all the code that would be the same on both platforms. I just would implement the gui seperately
The design of the android gui is straightforward as I want it to be. It looks like typical android because it is typical android.
Cons
I dislike the usage of JNI very much. Especially the signature and names of the callback functions (calling java functions from c++) are not checked at compile time and require a lot of manual work. If I rename a function and forget to rework the native part I only notice this mistake at runtime.
2. Build the GUI on the native side
Here I had difficulties finding out what is possible, especially for 2.2
2.1 Use Qt
I have only a few first step experiences with Qt in general but as far as I understood i would have the following pros and cons:
Pro
Reuse most parts of the code for ios and Android. I would than redesign the gui for each platform to make them feel natural. I can´t evaluate how much qt may even assists me at doing that
Cons
I have to copy the android gui by using other qt widgets. This is more effort and I don´t know if one can replicate the android gui elements (like the actionbar) so that the user wouldn´t notice it.
2.2 Using the android framework from the native side
I dont know if this is possible at all, I wasn´t able to find this information. Can I use the class "NativeActivity" and use the android framework to build the gui and use e.g. the actionbar? If this is possible somehow it would have the pros from 1. and maybe wouldn´t have it cons?
Do you have any feedback to my ideas or maybe even new approaches I didn´t think of? How do other multiplatform apps like WhatsApp solve this problem? Do they have redundant code for each platform?
Thank you,
Tobi

I would say that it depends very much on your application requirements. By my opinion, a better solution is to develop a separate application for each platform using recommended SDK's for that platform, and implement in native C++ only the time consuming data processing algorithms.
Application runtime on mobile platforms is not so straightforward as on desktop platforms. You should take into account background and foreground processing, specific application life cycling, accessing system resources such as network, file system, etc. And all these issues do differ on iOS and Android.
Regarding possibilities that you listed.
Qt/QML is ok only in case two requirements are met:
1.1 Your application is a foregroud application without any background operations.
1.2 You purchase a commercial Qt license because only commercial Qt can be submitted to Apple iTunes app store (even GPL apps are under
question).
Using NDK Native Activities on Android with cross-platform C/C++ backend. Android NDK API offers much less API then Android Java SDK, so a lot of things you will have to implement or wrap manually. It is a hard road.
Mixing Java code and C/C++ using JNI gives you more of Android SDK API. But you should remember that an Android activity's life cycle is not somewhat that you're used to deal with when developing on C/C++.
Approach that we are using
We've been developing an application with a huge amount of cross platform functionality that should work on Windows/Linux/Mac OSx/Android/iOS. We're using the approach as follows.
Cross-platform core is written in pure C++.
We have adaptors to GUI interface for each platform.
On desktop we use Qt as it reaches all desktop platforms with minor adapting to each platform.
On iOS the GUI is built using iOS SDK with Objective-C and C++ core is linked as a Framework. Still, we had to patch our core in some way for iOS background requirements and so.
On Android we wrap our C++ core in a background process and build all the GUI using only Android Java SDK. Foreground GUI activities interact with the core via local sockets, so we don't need to bother with activities life cycling in our C++ core. But the adaptor is a litle bit complicated.
Nevertheless, both mobile platforms often require workarounds and adaptations in C++ core which add a number of #ifdef'ed branches in code for each platform.

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.

Python - Does Kivy implements activities in the Android apps?

As we all know, when developing an Android app in native Java, we use activities. I was wondering that, in developing Android apps in Python(with Kivy), does Kivy implements activities for the apps in itself or not? because I don't see any activity implementation on the sample codes.
If it doesn't implement activities, Do we lose performance or any functionality in the application compared to coding in native Java?

Simply put, you can use Activities (starting them using pyjnius), but not really define them, at least, it's not usually the way one work with kivy.
Kivy doesn't adjust its way of working for targetted platform, it uses its own systems, and make them work there. For what i know the advantages of separating Activities on android is just a way to make your code more neatly organized, and doesn't imply performance changes. It can allow you to start your app in various ways (from a share, for example) but you can do that with p4a/buildozer too, by dispatching messages about the intent, if you need to. With kivy, you'll organise your code like you would do for any python project, using modules.

Kivy is a great tool for developing Android Apps. The best advantage of using Kivy is that it is cross platform and the same project can be used to publish apps on mutti-platforms.
However , it has some performance related disadvantages(as do most cross-platform tools like unity , cocos etc). If you're developing only for Android , I'd suggest taking a look into development tools which use Java. This will help create a smaller APK file which in turn helps in better user retention.
I guess you are real loyal fan of Python, but I have to tell you about its advantage and disadvantage.
Advantages
Pure python and its almightiness is in your hand.
Relatively simple to deploy with buildozer without any need to dive too deep into the details of particular platform.
You can run your app on desktop also, so there is no need to install some extra emulators/VMs to get it work
Disadvantages
Not that much information in Internet, even on stackoverflow
Pretty messy documentation
No obvious way to test the application
Not obvious machanisms of placing widgets, especially in built in layouts, which causes situations like: you want place widget in the center of it's parent, but kivy places it anywhere but not where you want it to be.
Official examples are quite ugly, so you may get false vision of how your application could look like.

How to reuse existing Qt code under Android?

I have an application that was developed using Qt. This application currently runs on many different platforms.
Now, I am looking for ways to reuse this code under Android. I noticed that there is a Qt library for Android available. However, I haven't come across any article that discusses the migration topic.
I am wondering if there is a way to reuse or reorganize our existing code such that the same code base can be used on Android as well as other platforms.

Try to comile your app with qt5.1.1 for Android. Eventually it will run, but i am pretty sure you will have to redesign your UI, otherwise you get "Desktop-like" App for Android, which for example results in a horrible small scrollbar on high-res screens. Generally Android can run QtGui and QtQuick. There are also QGestureRecognizer available for grabbing native gestures. QSesor (and subclasses as QGyroscope, QOrientationSensor,....) for reading mobile typical sensors. While QtQuick eventually is a better fit, QtGui is still working fine.

Android Cross-Platforming

I want to know more about Cross-Platform. I'm currently working on my thesis and decided to make an Android Application but not all target users uses Android device. So, We've come up with an idea to Cross-Platform the android application.
I have read the same topic but it didn't get to me too well. iOS / Android cross platform development. I want to know if there is another way than using the frameworks discussed in the link.
I want know what is the best/shortest way to cross platform a Android Application?

Cross Platform tools are in my opinion not a good idea at all. Android is Java, and iOS is Objective C. Android can use NDK to use a C/C++ library so theoretically if you did most of your code in C/C+ it could be used on both sides. I think two natives is more in order. Study NDK to see what could run on both devices. Lets say you built your app as a C++ Library except for UI interactions. Then in theory the library should work on both sides. C/C++ a lot easier on iOS than android however.
Also it really depends on the dependencies your app will have. Lets say you want to use a library but its only available in Java or C++ how does this effect your decision.
You might also consider designing your app so that it just captures data on the devices and the actual processing of the data takes place in a web service.

Another way is use Mobile Web HTML5 Framework like Phonegapp, Sencha touch and more.
Although web technologies don’t perform as well as native, but it is a useful thing that you can try.
See Choosing Mobile Web HTML5 Framework and http://operationproject.com/2011/adventures-in-html5-part-one/

Android application are apk files that are basically zip file that contains dex/odex files and all other resources that you may wish to add.But I think you can use any coding language to develop as long as you have IDE that converts your code to apk and dex .And most important of all your programming language must support corresponding api or must have something similar to cross compile.The reason Google used Java for Android was they felt it is convenient to do it(read it during case Google v/s Oracle)
Personally I feel cross-platform is good since it increases the developers base and understanding of the System (here Android).And I think the same analogy would go with other Systems as well.