Page 1 of 1

JavaFX Android Port

Posted: Sat Mar 11, 2017 4:18 pm
by smaudet2
So, I'm gonna try and get the android JavaFX stuff working today. Not for Maptool/Dicetool/Tokentool, mind, just for my Parsetool atm.

Build actually looks pretty simple - yeah, sure you need 3 SDKs, that's not really much different to how JavaFX used to be (2 SDKs and separate packaging tools). After you get them installed, just fire up a script it sounds like and it should be boom, ready to go.

I'll try this with Parsetool first, then try Dicetool (should be simple if I can get Parsetool working). Then maybe Tokentool. Then maybe more Dicetool fixes :P:


  • Parsetool Android Port - not done
  • Dicetool JFX Port - not done
  • Dicetool Android Port - not done
  • Tokentool - not done
  • Maptool - not done

(Btw, just a little teaser - sounds like iOS should actually be a potential target - turns out somebody's been building Java onto iOS devices...)

EDIT: Developer note - ok, first roadblock I hit - couldn't deploy to my Android device, period. Turns out...IntelliJ in its current form (still confirming, but the theory fits the facts) can't pass ENV vars to gradle, which uses those to select and android sdk...I have two installed - my old one can't see my device, my new one can. My new one can deploy to my device, my old one can't. My build doesn't say anywhere which Java/Gradle/Android SDK combination its using (major problem if you ask me, although gradlew is at least a godsend for reproduceable builds). And there is no way to set (today) your env vars for your gradle script from IntelliJ. Maybe this is because the gradlew script blocks them? No idea. Just a big fat warning, this is an issue. If you've got an sdk that works, check for an ANDROID_HOME and an old android sdk installation.

EDIT2: Forget JavaFX/Gradle - there generally is a big issue with the android tooling in general - Android Studio is Google's attempt to hide the ugly from everyone...but there's a lot of work left to be done making the tooling seamless.

EDIT3: Got JavaFX+Gradle+Android working, with two different SDKs (Dalvik and Gluon). Gluon seems like the slicker experience, of course they're paid. They offer open source license though. Dalvik is free...but I get the sense they stopped developing it. It uses a really, really old Android API (which I guess is great if you're all running crap phones/tablets).

Gluon just ran with gradlew androidInstall (I still had to start it manually).

I'll be working on integrating parsertool next.

EDIT4: So...

  • To build the java app (with gradle) you pretty much have to use the java plugin. Makes sense, alright.
  • To build the android app (with gradle) you pretty much have to use the android plugin. Makes sense, alright.
  • You cannot use the java and the android plugins together.

I'm not sure what that means for the eventual port...but that alone will make any JavaFX -> Android port a hairball. I think I can solve this, and I was planning on doing this already - but I think I'm going to need 3 modules, one android, one java one common, and the java/android ones will be thin wrappers around the base module. Yay multi-module gradle apps...

I'm going to take a break for a couple hours here...maybe something will come to me.

EDIT5: Android/Java Hybrid project is setup. I think it works...haven't really tested anything. Project workflow needs ironed out...but I have bigger fish to fry.

Android has a big issue, (which I sort of already knew about) - Java 7 was the last real supported version by the Dalvik VM, the Ensemble stuff in the javafx-dalvik SDK uses retrolambda to target Java 8 and backport it to dalvik - so basically its a hack. Not only that, the build task is a hack... it does 'work' but the sample project uses a jar that's hard coded into a hacked up version of the retrolambda task. There's a new plugin version of my thinking is I just have to play around with the build file a bit. I'm about 95% confident that I can get a dalviked version of the build in here...

Gluon is probably a no-go. They have a complicated Desktop/Mobile strategy - it probably works great, but you probably also have to buy wholesale into their stuff - which, granted, I'm pretty darn sure the scenebuilder they provide and the one inside IntelliJ are one and the same, so maybe its not that bad...but the way gluon projects are structured you basically become a gluon app, not a java app with a gluon transmogrifier. That being said, I think its worth it to look at the plugin, and see which dependencies they have. I'm not advocating whole-sale RE...just seeing their general strategy, as its probably worth copying.

Re: JavaFX Android Port

Posted: Sun Mar 19, 2017 7:56 pm
by smaudet2
Just a quick bump - I haven't gone anywhere, I was working on something different this weekend.

Re: JavaFX Android Port

Posted: Mon Mar 27, 2017 11:25 pm
by smaudet2
Been (am still) sick. Got android + java building together in same project, still trying to figure out how to tie the same code base to both projects.

EDIT: Good news! It builds an apk and I can install it on android. I can also run/package the app fork desktop. Bad news - I get a screen full o' black when I run it. Something about it not packaging the libraries it was built with... *glares at dexing plugin*

EDIT2: Got it running. Ugh. One library downgrade, one one library elimination. If you use Java 8 - tread, very, very carefully. Granted, I'm not sure what the problem is, since the folks over at gluonhq seem to think retrolambda should be enough (to be fair, it works), but there's something up with the bytecode manipulation. The bigger issue is the although it runs and everything came up, I ran into the other issue I was expecting to have, namely window sizing. Ultimate app might look like this:

JavaFX ui main module
-> Desktop wrapper version
-> Mobile wrapper version.

Frankly, though, I think no real effort should be spent on trying to move the UX components between Deskop/Android, as they're likely to be wildly different, and users and components will have wildly different needs. But, it is a common toolkit at least I guess that can be ported between the might get away with a MapTool JavaFX rewrite on e.g. an iPad-sized device, but that's about it (don't forget you have to do usability testing for things like finger vs mouse, and mice can do things fingers are terrible at).

I'll upload later what I got done, maybe someone will find it useful for an eventual (offical) port...