JUniversal: A new, Java-based approach to cross-platform mobile apps(msopentech.com)
msopentech.com
JUniversal: A new, Java-based approach to cross-platform mobile apps
https://msopentech.com/blog/2015/01/26/juniversal-a-new-java-based-approach-to-cross-platform-mobile-apps/
9 comments
I'm sold on the concept. I especially like the fact that you're using ARC on iOS; my intuition is that this would interact better with the platform and native development tools than something like Xamarin which requires GC.
Do you have a way of doing local storage, i.e. to the file system or a database, in cross-platform code? Or does that have to be platform-specific? How about making HTTP/HTTPS requests?
Do you have a way of doing local storage, i.e. to the file system or a database, in cross-platform code? Or does that have to be platform-specific? How about making HTTP/HTTPS requests?
We dependency injection network and database abstractions. For network, because Google loves protobufs, we have a network channel abstraction between client and server, or between processes, that can send/receive protos. For storage, we have an IndexDb like abstraction.
We hand-rolled our dependency injection stuff, but if we did it again, we'd just use Dagger 2 which works on all platforms.
We are second guessing our decision to go with an IndexDB abstraction. The code to use this is not very maintainable, and so we're looking at moving to a SQL-lite-ish kind of abstraction for storage. It might still be IndexDB underneath on some platforms, but operations will be higher level.
You can't get away from some platform native APIs. In general, abstract them, or copy the ones that PhoneGap already designed, and dependency inject the real implementations (instead of the PhoneGap approach which is to serialize RPC calls through URLs from a JS VM)
You can imagine a class like this:
public class InboxImpl {
We hand-rolled our dependency injection stuff, but if we did it again, we'd just use Dagger 2 which works on all platforms.
We are second guessing our decision to go with an IndexDB abstraction. The code to use this is not very maintainable, and so we're looking at moving to a SQL-lite-ish kind of abstraction for storage. It might still be IndexDB underneath on some platforms, but operations will be higher level.
You can't get away from some platform native APIs. In general, abstract them, or copy the ones that PhoneGap already designed, and dependency inject the real implementations (instead of the PhoneGap approach which is to serialize RPC calls through URLs from a JS VM)
You can imagine a class like this:
public class InboxImpl {
@Inject
public InboxImpl(SQLStorage sql) { ... }
public List<Messages> findMessagesByAuthor(String author) {
return sql.from("messages").select("body","author").where("author").contains(author).asList();
}
}The architecture (shared business logic with platform-specific UI) sounds a lot like React Native. The difference is that in RN, your UI is primarily specified in JSX on all platforms. This means you can even reuse a lot of your non-platform-specific UI.
I expect that in a year or two, there will be a React Native UI library that implements Material Design on Android and the Web, perhaps even with iOS bindings for things that are similar across platforms. It will always be a best practice to adopt the conventions of the platform you're on, but it does nobody any good to implement the same UI three times. Reuse your <Text>, your <Image/>, your <ProductListing/>, etc. and save the platform-specific UI for things that change across platforms (like navigation paradigms).
I expect that in a year or two, there will be a React Native UI library that implements Material Design on Android and the Web, perhaps even with iOS bindings for things that are similar across platforms. It will always be a best practice to adopt the conventions of the platform you're on, but it does nobody any good to implement the same UI three times. Reuse your <Text>, your <Image/>, your <ProductListing/>, etc. and save the platform-specific UI for things that change across platforms (like navigation paradigms).
IIRC, React Native still runs a JavaScript thread to execute the logic. JUniversal and similar code translators will convert to Obj-C (iOS) or C# (Windows Phone) to run at native speed / memory / CPU consumption.
> The architecture (shared business logic with platform-specific UI) sounds a lot like React Native.
That is a very common approach.
So far I have done that for an hobby application using C++ for the business logic, as it is the language common to all SDKs.
So on my case was Java/C++ on Android and C++/CX on Windows Phone.
Where it fails down is the NDK pain in Android, where the best aproach to avoid JNI hell is to use the same approach as distributed computing.
Instead of calling lots of Android API methods, just invoke one that does the bulk of the work on the Java side and back.
Alternatively a binding generator like SWIG or Djini.
I almost though a few times to go back to Qt, but there one is forced to re-write the UI multiple times anyway as it provides very little support for native integration and everyone is forced to mimic native behaviors in QML and JNI invocations.
That is a very common approach.
So far I have done that for an hobby application using C++ for the business logic, as it is the language common to all SDKs.
So on my case was Java/C++ on Android and C++/CX on Windows Phone.
Where it fails down is the NDK pain in Android, where the best aproach to avoid JNI hell is to use the same approach as distributed computing.
Instead of calling lots of Android API methods, just invoke one that does the bulk of the work on the Java side and back.
Alternatively a binding generator like SWIG or Djini.
I almost though a few times to go back to Qt, but there one is forced to re-write the UI multiple times anyway as it provides very little support for native integration and everyone is forced to mimic native behaviors in QML and JNI invocations.
Nice to know about it.
Sadly Oracle seems more keen in pushing the brain dead idea of Oracle Mobile Application Framework[0].
Regardless of the Google vs Oracle situation on Android, they could provide JIT and AOT compilers for the remaining mobile platforms, instead of leaving it in the hands of third parties.
I have turned to Qt/C++ and Xamarin for my hobby mobile development as cause of that.
[0]http://www.oracle.com/technetwork/developer-tools/maf/overvi...
Sadly Oracle seems more keen in pushing the brain dead idea of Oracle Mobile Application Framework[0].
Regardless of the Google vs Oracle situation on Android, they could provide JIT and AOT compilers for the remaining mobile platforms, instead of leaving it in the hands of third parties.
I have turned to Qt/C++ and Xamarin for my hobby mobile development as cause of that.
[0]http://www.oracle.com/technetwork/developer-tools/maf/overvi...
Another great (though not free) framework is Tabris: http://developer.eclipsesource.com/tabris/
Well, those who have done some iOS or Android development know that any good app requires extensive hacking. Unfortunately this doesn't work in a cross-platform manner. For the simplest applications having a cross-platform framework is fine but if you really want to make an immersive app for iOS or Android you need to go native. Now this is not to say that some applications will work perfectly fine under this framework.
>Now this is not to say that some applications will work perfectly fine under this framework.
This is similar to Kirin framework (http://github.com/futureplatforms/kirin)
Cross platform development in Java is compiled to JS via GWT and can be deployed anywhere Java or JS is available.
It powers apps with hundreds of thousands of users on iOS, Android, Windows, Windows Phone and Xbox One.
Cross platform development in Java is compiled to JS via GWT and can be deployed anywhere Java or JS is available.
It powers apps with hundreds of thousands of users on iOS, Android, Windows, Windows Phone and Xbox One.
The approach is similar to the one chosen by Haxe. I would keep a close eye on the progresses made by this open source language. For the moment the most mature translation target is the C++ one, however there are also targets for Java and C#. Sadly the community seems to be 95% focused on mobile gaming.
Haxe is robust though; it's the libraries that are developed based on the focus of the community. If you want to develop apps with it, you can by just developing a lib. The language & toolchain are robust and with haxescript you can nicely try before you convert.
I know it's robust. The fact is that the libraries are most mature just for 2d games, Windows Phone is not supported and the C# and Java backends have less focus from the community. The community is made mostly of old Flash developers so the focus is on OpenFL and NME. These are really the libraries that sparked interest in Haxe.
The typical workflow for such uses is to quickly develop the game on Windows compiling haxe to flash. The haxe to flash compiler is extremely fast, there is debugging support and FlashDevelop rocks. Once done then there is a final transpilation step to the mobile platform of choice. This works and is stable but awkward. Cross compiling to Ios and Android takes a lot of time.
Besides hxscript it would be probably feasible to port Neko to mobile devices and use it as a way to add fast compile-reload cycles. However this not something that a single developer can do and it would be a complete project on its own. The same goes for developing a cross platform application by adding libraries for the functionality needed. Not feasible at all if the final aim is to develop a mobile application.
I really admire Haxe and I really think it's a neat piece of work and that the architect of the language has been able to design it with a wonderful balance of features . I am just sorry that its libraries don't cover the application domain in which I am more interested.
And I am sorry but I don't have time to contribute to the language development. :P
The typical workflow for such uses is to quickly develop the game on Windows compiling haxe to flash. The haxe to flash compiler is extremely fast, there is debugging support and FlashDevelop rocks. Once done then there is a final transpilation step to the mobile platform of choice. This works and is stable but awkward. Cross compiling to Ios and Android takes a lot of time.
Besides hxscript it would be probably feasible to port Neko to mobile devices and use it as a way to add fast compile-reload cycles. However this not something that a single developer can do and it would be a complete project on its own. The same goes for developing a cross platform application by adding libraries for the functionality needed. Not feasible at all if the final aim is to develop a mobile application.
I really admire Haxe and I really think it's a neat piece of work and that the architect of the language has been able to design it with a wonderful balance of features . I am just sorry that its libraries don't cover the application domain in which I am more interested.
And I am sorry but I don't have time to contribute to the language development. :P
libgdx also uses robovm for ios, but prefers gwt for web. since its 'just java' desktop and android dev comes free.
If you're into build *gl based guis it's a great cross platform toolkit in disguise (especially with scene2d).
If you're into build *gl based guis it's a great cross platform toolkit in disguise (especially with scene2d).
This looks awesome! I can hardly wait for the promised C++ and ObjC++ support. I wonder how much gtime the main committer, Bret Johnson, is able to devote to this project.
I wonder how if they are going to implement pure C++ support. And in that case how they are going to support GC. Any idea?
Prior to that, some 20% Googlers also produced the PlayN library (https://github.com/threerings/playn) This was taken over by Michael Bayne who added an iOS backend by Bytecode -> IKVM -> Mono conversion. I beleive j2objc and RoboVM backends exist now as well.
The major benefit of the j2objc approach is the avoidance of GC in favor of ARC, the conversion of message-sends into C-method calls when possible, and integration with existing iOS toolchain.
When we started, it seemed like an iffy idea, but after developing a product delivered to millions of users on a high volume site (gmail) that has 70% code sharing, and being able to simultaneously develop, test, and deploy across the platforms reasonably efficiently, a lot of skeptics have become converts to the concept.