Is Fire / ElementsRTL is the right direction to take my app?

Specific question is why is the link for Android SDK for Fire struck out in the docs plse?

Implementing a PoC to decide on where I go with the app next. Current app is about 30,000 lines of Java using Swing, targets macOS and Windows today, but is about 10 years old and impossible to extend to iOS and Android.

Lots of XML marshalling for persistence so thought maybe migrate to Swift for future-proofing and use ElementsRTL to implement as much as possible in a cross-platform way, then implement the UI following the best practise of using the platform-specific APIs.

I’ve no experience in Android development so was trying to follow the Elements docs but the struck out link to the SDK brought me to a halt and thought I’d seek advice on how to proceed and if I’m thinking about this the right way. Desperately trying to avoid porting to Javascript and using wrapped browser views for native apps - horrible thought!!!

on what page, exactly? struck out links are either broken/wrong or refer to topics that haven’t been written yet. in this case, it sounds like it’s probably an accidental breakage, eg a typo.

This one Marc - https://docs.elementscompiler.com/Platforms/Java/ADK/

Ah yes. will fix ASAP, the correct link is https://docs.elementscompiler.com/Fire/Setup/Mac/AndroidSDK/

Many thanks! Is the rest of my thinking more or less accurate too plse, i.e. switch implementation language from java to swift, leverage the Elements RTL for as much as possible in everything except the UI, in one Fire solution with multiple projects therein?

I’m not sure how I share between the projects in the solution yet, I’m hoping to see that as I work through the PoC.

the good thing is, with Elements you don’t even have to completely switch languages. Why I dot recommend sticking with Java, Elements can now compile Java language code (to all platforms), so you can migrate existing stuff by just adjusting it to Elements RTL and the new platforms, without having to translate it too. You can use Swift for new code, and either keep the old Java code around indefinitely, or translate it “later”.

You can mix languages even within the same project.

Yeah.

that’s the way to go, yeah. check out

among others.

Shared Projects are the way to go — in addition to the above, I have another blog post about those coming up soon. Here’s a preview (lacking screenshot and any kind of typo/grammar/sanity review !): Working with Shared Projects.

—marc

That blog preview was very useful, thank you Marc! Looks like the model and helpers for the model could be shared, and the only external dependency they have should be ElementsRTL for maximum portability between platforms. Then UI for required platforms in their own projects.

I should really consider seriously if I should invest in the Java (Iodine) capability as potentially the easiest migration route for shared code rather than Swift.

Thanks again!

1 Like