Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I develop an app for both iOS and Android, and I'm loon'ing for the best way to share code between this two platforms.
What I would like to do is creating all the View (UI part) in native but share the code for the logic (controller + model).
With all I found, 3 things seems to be quite good :
1) C++ --> Build library file Using c++ For the logic so I'll be able To use the .dll files in the 2 platforms
2) Azure mobile apps services. Is it possible to habe all the logic in a webservice? The issue is that if I dont have acces to internet, my app will be unaivalable, right?
3) I hear a lot about React native used by Facebook, but it seems to be used to create the UI, but I prever create it in native. Can I use react only for logic?
It seems like you have three options:
1. C++
You can't just have a compiled .dll and expect it to work for iOS and Android. They both have to be compiled in different architectures and it has to be a static library on iOS.
Dropbox's done it this way, and they've put up a lot of notes and example code, and code you can use so you can take a look.
Pros
• Pretty straightforward after you manage to set it up
• No additional layer of dependencies, bugs, etc (like in case of Xamarin/React Native)
Cons
• Setting it up and using it needs a lot of extra work: you need to setup additional compile steps and write wrappers for both platforms.
• Some other challenges you're surely going to meet when trying to compile the same code for two different architectures
Here's a SO post on how to do it in detail...
2. Xamarin
This option seems to extreme to use in this case. You're forced to use C# and introduce another layer of dependencies and bugs. You said you don't want to use another language for UI so I wouldn't recommend it.
3. React Native
Now this is a viable option. You can write scripts in JS and use them in native code in both Android and iOS.
Here's an article on how to share code with code examples...
Unfortunately it uses React Native for UI, but you can easily call React Native functions from native code.
There are a lot of downfalls to using this, including the fact that the calls are asynchronous as they're executed on another thread, so you would have to implement some kind of callback system for functions that return something.
Pros
• Seems to be easy to set up and write
Cons
• You'd have to implement a native callback for every function that returns something
• Using it has a lot of downfalls that the document describes:
• As events can be sent from anywhere, they can introduce
spaghetti-style dependencies into your project.
• Events share namespace, which means that you may encounter some name
collisions. Collisions will not be detected statically, what makes
them hard to debug.
• If you use several instances of the same React Native component and
you want to distinguish them from the perspective of your event,
you'll likely need to introduce some kind of identifiers and pass them
along with events (you can use the native view's reactTag as an
identifier).
Conclusion
I think I'd go with C++, mainly because a big company (Dropbox) tried it and succeeded and actually uses it in production. You could try React Native as an experiment, it would make a great study case!
I'd say that putting the "core" logic into a separate library is a sensible approach.
You are not the first who wants to do this, and I highly recommend looking at Djinni. It's a tool to accomplish just that. You can define common interfaces and datatypes and fill in the native parts. Communication is possible in both ways.
It's not as easy as writing the whole thing natively at once, but it supports clean design which you might benefit from anyway.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I plan to create an application on iOS, Android and a website with AngularJS.
But for not having to rewrite the business code on each app, I would like to reuse as much code as possible.
To be able to execute the core of the project on any platform, I have to use a web language.
Through different articles, I plan a common architecture to separate the business logic of the project - core - with the UI which will reimplemented for each system (UIKit for iOS, AngularJS and Polymer for the webapp, etc.)
The goal of this architecture is to respect important software engineering principles such as information hiding by decomposing requirements in modules, DRY and SOLID
Each feature will be decomposed in module.
Core: Business logic code - reusable on every platform - will be represented in form of a library.
View: The view class will be developed on each different platform to use the different UI elements proposed on each platform. E.g.: subclass of a ViewController in Objective-C / Swift for iOS or a simple class to manipulate HTML for the web-app. There is no logic in this class. It is only responsible to:
Handle user interactions to the business logic.
Display contents from the business logic
IView: Interface which abstracts the class which manipulates the view.
Presenter: Link between the Interactor and the View to drive the UI.
Interactor: The logic of the module, such as algorithms.
Data Store: Manage the persistence and the fetching of data by communicating with a database or API or web-service.
Model: Data represented in structures.
Here for iOS (almost the same for Android):
The code of "core" will be executed through a virtual machine as this article shows us: http://www.skyscanner.net/blogs/developing-mobile-cross-platform-library-part-3-javascript
Here for AngularJS:
Now that you know everything about the architecture, here are my questions.
I don't have enough experiences and feedback on the web-langages to be able to make a smart choice. After few researches, I found that there are various options:
Dart:
Question 1: Are there mechanisms to allow interoperability between Objective-C/Swift and Java through VM? I know that both platforms have VM to execute Javascript code and Google provides dart2js to compile Dart to Javascript code. But it's not plain Javascript: See an example here. So I don't know if there is still a proper interoperability.
Javascript ES6: Event if it's not fully implemented in browsers yet, it's possible to start using ES6 with Traceur compiler.
Question 2: Is there interoperability of Javascript compiled by Traceur and the VM in iOS/Android?
Question 3: Is it "safe" to use ES6 through Traceur to develop a large-scale project and have production code?
Thank you for reading.
I know this wasn't one of the options you listed but don't automatically rule out C++. This is what Dropbox uses for example, they even open sourced their tools for this purpose:
C++ to Java/Objective-C API generator:
https://github.com/dropbox/djinni
Sample "native" app for Android/iOS:
https://github.com/libmx3/mx3
Interesting article on the subject with more links:
http://oleb.net/blog/2014/05/how-dropbox-uses-cplusplus-cross-platform-development/
Updated Answer:
If you really don't want to use C++ and are okay with the bloat you'll get from going non-native then you can try the following:
https://github.com/MobileChromeApps/mobile-chrome-apps
That project is Google's fork of Cordova and adds a bunch of new features and benefits.
There is a Dart wrapper over Chrome APIs here:
https://github.com/dart-gde/chrome.dart
Basically, you would write your app in Dart using plain HTML5 technologies, then for certain things you'd use the Chrome APIs (device state, etc). Then you can deploy:
Web: Compile to JavaScript without the Chrome API features.
Chrome OS: Compile to JavaScript with Chrome API features.
Android: Compile to JavaScript and then use MobileChromeApps to create Android app.
iOS: Compile to JavaScript and then use MobileChromeApps to create iOS app.
This is an interesting topic. Here is what I learnt from the "GWT.Create" conference, the google guys showed how they did the cross platforms project:
First the DataStore and Model part in your picture should be done in an external server, so it's already crossed platforms.
UI render must be done in native way individually, that's the best solution.
They implemented the shared logic (complicated calculation, encryption, etc) with Java, for Android it works out of box, for Web they use GWT to translate Java to Javascript and for iOS they use J2ObjC, a new Google product. You can find it here:
https://github.com/google/j2objc
They also mentioned the C/Cpp solution, it's not a bad idea at all, Java is just a high level language and easy to use in most case.
If you want to create a cross platform application (iOS/Android/Web) the best thing you can do is sharing as much code as possible between these platforms. You could use something like PhoneGap/Cordova but this does not feel very native all the time. Event the best PhoneGap app feels not that native because it does not use the native UI. Instead in embeds a browser in a native UI container.
What I recommend is using a project structure as follows:
myapp-core
myapp-ios
myapp-android
myapp-web
The the core project is shared between the ios, android and web project. You can write the core project in Java and use GWT to translate this code into JavaScript for the web project. For the android project there is nothing to do because Android uses Java. For your ios project you can use J2Objc to transpile you core Java code into Objective-C.
What come into the core project?
Use interfaces and abstract base classes as well as factories as much as you can.
conversations, reminders, and contacts It also deals with the difficult task of network management and offline synchronization, where the app is used offline, reminders are made, and e-mails are sent. It's up to the app to store all that and fire it off to the Internet when the time comes.
Source
Of course, there are a number of elements of Inbox that are shared
across the three platforms: code for managing network communication,
caching objects, local persistent storage, managing user edits both
locally and remotely, and supporting it all while offline. This logic
must be faithfully and correctly implemented and kept up to date on
all three clients. Rewriting it three times in three different
languages would soak up substantial engineering resources and slow
down how quickly we make improvements to Inbox.
For iOS we developed the now open source J2ObjC cross compiler to translate our Java data model to Objective-C, and again we get a natural API on which to build our native iOS Inbox app (complete with -[Reminder snooze]). The astute reader may wonder how we deal with the impedance mismatch when translating from a garbage collected language (Java) to a reference counted one (Objective-C). Generally, J2ObjC relies on Objective-C autorelease pools, so objects normally garbage-collected are instead freed when a pool drains. One problem with this approach is reference cycles; in places that cycles exist in our Java data model, we use a Java annotation to identify the #WeakReference. When transpiled, the corresponding property in Objective-C will have the __weak modifier, thus breaking the retain cycle. In practice we’ve found this to be a relatively minor problem and we have automation tests that flag the rare cases of new cycles creeping into the object model. Source
The communication between your core modules can be done with Dagger2 it runs on Android/iOS/GWT. There is also a cross platform JSON library called realtime-json. The HTTP transport can be implemented in the core at least for Android and iOS. Form GWT/JavaScript you have to do it on the client side.
Here are some sample apps that should help you:
iOs App showing J2Objc: https://github.com/tomball/j2objc-sample-reversi
Starter Kit for Hybrid apps: https://github.com/Sfeir/jhybrid
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Doing some investigation on the feasibility of using QT/QML for an upcoming project. Client wants it initially on Windows and Mac desktops, with the possibility of iOS and Android down the road. They would like to know that what we build will move relatively easily. I'm not much of a desktop programmer, but what I see is that QML is designed to work with C++. As a result, it should be relatively easy to build an app that runs on Mac and Windows, and iOS will accept C++, so I can't see a lot of roadblocks there. But I'm confused about Android. I see folks talking about building an Android app using QML, but they seem to still be using java; I gather it uses the NDK in the background.
But if you write an application that has QML for the front and, and C++ for any guts not covered by QML, can it work on Android? Or do you need to rewrite the C++ piece in java? The app is not a simple one, so we are going to have to provide some logic outside of QML, at least, it sure looks that way. While we might save time and $$$ by using QT to not have to go native on the desktops and iOS, I see a problem with Android down the road.
But if you write an application that has QML for the front and, and C++ for any guts not covered by QML, can it work on Android? Or do you need to rewrite the C++ piece in java?
It really depends. You may need to go through the Java interface where the Android platform does not provide direct and public API for certain functionality. One example is low-level IO operations, like writing the serial port for usb-serial devices, but there is more to it.
In general, what Qt modules and third-party software based on Qt do is to use the QAndroidExtras add-on module introduced in Qt 5.2. This will allow easy backend integration into your C++ logic.
With that in mind, you could hide the Java implementation details in the background while you still maintain the C++ interface to QML. Therefore, it should just work that way.
Please see the following documentation to get the grasp of it:
Qt Android Extras
Here you can find one of those nice examples:
Qt Notifier - Demonstrates calling Java code from an Android application.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
:) When you write a iOS App, in order to use the UI like buttons. you have to write it in Objective-C. (Java on Android). I was wondering if anyone had any thoughts on the technical reasoning behind this. Why they might of done this. As you can write apps in C++ on iOS so I've never fully worked out why they didn't expose a way of making the UI in that. (Ignoring the fact that this is how they did it on the Mac).
Note: I know you can write apps in c++ for Android but the question is more why is the main UI i.e buttons etc forced to be written in a dynamic language for these platforms, why not expose access to it thorough C++ without having to write a crude wrapper or binding layer yourself.
I'm guessing that when the original framework engineers were working on their respective operating systems, cross-platform desires like UI support in a different language like C++ was at the bottom of their concerns. You'll have to realize that when deadlines loom, all of the features are prioritized only what is considered most important is made to work. Everything else is a consequence of that.
In the case of iOS, Objective-C is the language of choice for the OS that Apple uses. All of the MacOS app developers were writing in Objective-C so their developer based was in familiar territory.
In the case of Android, Java was already a popular language, with existing open source tooling and libraries (Eclipse IDE, Apache Harmony), so presumably they decided to use Java as the first class language for app development with apps running in a VM as a consequence. Alternatively the decision may have been VM first for the sandboxing of apps and Java was picked as the language for app developers. Or some other reason.
In either case any attempt to add in additional languages now that both are in the hands of customers means design decisions and trade offs along with a host of other questions like: how to add it in without breaking existing APIs, how to support it along with new features, how to test, etc. etc.
As you see more and more software, you'll realize that lots of stuff is just arbitrary or made sense at the moment of when it was designed.
iOS does expose a C API for drawing UI components; it's called Core Graphics.
Because the view itself is written in Objective-C, or Java, respectively. When in Rome, do as the Romans do.
I've been searching solutions for my enterprise apps, at least 3 platforms need to be supported, which are iOS, Android and Window Phone. After a whole day's search, I finally set my eyes on 2 promising cross platform solutions, one is monocross and the other phonegap.
monocross seems to use c# and .net at all, is it possible to access native libraries and languages? I read somewhere it's compiled directly into binaries that can execute on target platforms.
And about phonegap, it uses webviews on each platform to provide the capabilities of presenting user interfaces to final users. As it's implemented via interpreted language and high level apis, the performance may not meet our needs.
Finally, we(my team) decide to give it a try with mono, the architecture is illustrated as bellow:
+++++++++++++++++++++representation layer++++++++++++++++++++++++++
[monotouch,monodroid,silverlight]or [native gui calls] or [html5/js/css]
+++++++++++++representation controller/business logic layer+++++++++++++++
[ mono/c# ]
++++++++++++++++++++++++++++server side+++++++++++++++++++++++++++
[ the cloud ]
I want to use mono/c# to write some common purpose business logic and data structures, and when it comes to some common platform features, like storage service, notifications, I'd like to wrap them up on each platform and expose uniform apis for c#(business logic layer) to use. As to the representation layer, we decide to choose from the 3 optional solutions listed above.
To make this happening, first I have to figure out if it is possible to call native frameworks.
So, my questions are:
1, How does mono work, I mean, are the c# codes compiled into binaries that can be executed directly on iOS, Android and Windows Phone?
2, Is there a mechanism to make native invocations? Like in cocos2d-x, I can call java methods via JNI, and in iOS, c++ can call oc directly. Can I call cocoa touch stuffs in mono with c#?
3, Is it possible to manage all these stuffs in one single project, and how to build them?
4, Are there any better solutions?
Any suggestions will be appreciated, thanks for your patience!
I wonder why Xamarin does not land on the first page of your search result,
http://xamarin.com/features
But that's what the Mono guys created for the C# developers that want to target mobile platforms. MonoTouch and Mono for Android are there each featuring a common library base with Microsoft .NET, and also platform specific bindings.
Your non-UI code should be able to be used in portable libraries and share among them. Microsoft's portable library is Windows specific, and right now I am not sure how much Mono guys can embrace that, but even if PCL fails, you can create multiple platform specific projects based on the same copy of source files (which I did in #SNMP). The remaining task is to develop platform specific UI for Windows Phone, iOS, and Android.
There are tons of articles showing the features,
http://docs.xamarin.com/
and also many successful apps
http://xamarin.com/apps
The best way to learn a product is to try it out (for free in Xamarin's case). This also applies to MonoCross (which is a framework built upon Mono).
I am not familiar with PhoneGap, so you need someone's advice on that.
Disclaimer: this is not a complete answer - but I do hope it answers at least part of your question
I encountered a similar problem when I started cross-platform dev using the Mono products 18 months ago.
The approach I've built since is called MvvmCross - it forked off of MonoCross a long time ago - now shares no code with it (but maybe we'll team up again one day!).
The approach uses PCLs to share code. This is not entirely painless, but is easy after you've done a few setup steps - http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
You can learn more about this approach on this video: http://slodge.blogspot.co.uk/2012/12/mvvmcross-video-presentation-xaminar.html
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
we made a quit big iOS application with 2000+ objective c classes. I am wondering there is a best practice guide to port it to Android ? Currently I am looking at Visual Paradigm (UML) which reverse engineers objective c files to UML. Like Enterprise Architect it also allows me to generate code(headers + declaration) for another popular language like java or c++. Are there any other approaches yet ? Also, as our app is heavily using the UINavigation and UIView controllers, I am wondering there is similar model and implementation on Android.
Thanks so far, guenter
In all honesty, I think that what you are planing is just going to make for crappy code that will be insanely hard to maintain. I realize it sounds like a lot of work, but its gonna be easier in the long run, I would just "port" the concept of the app to android and write it from the ground up.
The Apportable SDK
It cross-compiles Objective-C applications to Android, without extensive changes to the original codebase. Instead of translating the code to Java, Apportable cross-compiles your code to run directly on the Android device’s processor, bypassing the Java runtime, resulting in speed and performance that rivals the iOS version.
The platform has been tested on Apportable’s library of over 150 devices and in the wild, where Apportable-powered apps have received 5-star reviews on thousands of devices.
check out the sdk here
AFAIK there is no automatic tool to convert Objective-C to Java. There is java2objc that does the reverse.
Here are some official tips for porting Objective-C to Java: http://www.nextcomputers.org/NeXTfiles/Software/WebObjects/Guides/PortingObjectiveCtoJava.pdf
I'm not an iOS expert, but AFAIK iOS does not have layout managers - it uses XIB/NIB to do layout (or dynamically in code, which is not recommended). On Android there are layout classes which are primarily used to support different resolutions. Also, layout is declared via XML files.
So it seems there is a lot of hand-coding in front of you. Since a project is quite large, I'd get a help of an expert that knows both Android and iPhone.
For going from C or C++ to Android you are probably best of using the NDK. The problem is that I don't think this is possible (at least, not directly?) for Objective C.
I think it might be best to try and go to C, and then use the NDK to make it into an app for Android. Going from your code, trough UML to JAVA sounds like a much harder option.
just to let you know how the story did end up, I kept using Sparx Enterprise Architect and have my design, architecture and documentation well under control, for all platforms finally except for JavaScript. Its a bit tedious when integrating new features but in an enterprise environment it saved me a lot of time. We are working on iOS, Desktop(Web2.0/HTML5), Android, Blackberry, Symbian and some router systems. To get rid of platform specific things, I introduced always an additional layer. Seems to work for our products so far.
Thanks to all again, g.
MyAppConverter service helps to convert native iOS mobile apps instantly to native Android app, it's not focused mainly on the look and feel, and UI interaction of your app. That means it don't replicate your application as it is. Instead, MyAppConverter make all changes to make a project suitable for the development of an Android application.
MyAppConverter currently support only iOS to Android conversion and objective-c to swift.