Live data from Hacker News

JUniversal: A new, Java-based approach to cross-platform mobile apps

msopentech.com

1–10 of 21 posts

Re: JUniversal: A new, Java-based approach to cross-platform mobile apps

#4
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 , your , your , etc. and save the platform-specific UI for things that change across platforms (like navigation paradigms).

Re: JUniversal: A new, Java-based approach to cross-platform mobile apps

#5
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.

Re: JUniversal: A new, Java-based approach to cross-platform mobile apps

#6
post #4

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 th…

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.

Re: JUniversal: A new, Java-based approach to cross-platform mobile apps

#7

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).

> desktop and android dev comes free.

As long as you stick to Java 6 and APIs common to both platforms.

Re: JUniversal: A new, Java-based approach to cross-platform mobile apps

#8
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...

Re: JUniversal: A new, Java-based approach to cross-platform mobile apps

#9
post #4

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 th…

> 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.

Post reply on HN