Home Features Docs Blog Support GitHub

MOE 2.0 | I'm not an expert... but maybe together we are?


(Christian Ringshofer (Das Weiße Lama)) #1

Hi there everyone!

For me it seems like this community (which is very nice btw!) is waaaaay more active than the core development team of MOE.

It is very sad indeed, to see no support at all for existing bugs and problems currently, related to issues which might not be fixed during the next time.

So well… this should not be a mutiny or something like that, but yesterday it came to my mind:
Why don’t we fork the project together with some brave developers who love multi-os-engine and the main concept of using ART on ios and bring the open-source project / code to the next level? (Android Pie, Swift, Java 8.0+)
I really depend on this project, and for me it will work better than any other project I’ve heard so far:

Downsides of other frameworks:

  • Flutter: java / kotlin bindings possible BUT no native UI, (sucks for me)
  • Nativescript: javascript, no real multithread (sucks for me)
  • React-native: still javascript, stinky…
  • Xamarin: uhm… c#, cannot use libgdx (sucks for me)

Did I forget another bad way of bringing cross-platform to my project?

Positive facts about MOE so far:

  • I can reuse many parts I need on my java server-backend for very well designed offline support. No webworkers needed, just plain good old java code.
  • My whole environment is built on java, which does not give me many situations when I have to switch languages
  • I can use retrofit, gson, rxjava, file-management, sqlite databases on both platforms without having to worry at all
  • I can develop my ios app in Android Studio
  • I can use libgdx, my existing apps heavily depend on it
  • I can use native UI perfectly and fast!

What I currently fear:

  1. Due to inactivity, many people leave Multi-OS-Engine and the project slowly dies while the core developers don’t care at all about existing apps and projects depending on it.
  2. Switching to another framework will force me to making compromises which will totally make things really bad.
  3. Cool libraries and Apple will slowly drop support for objective-c and will push to swift, making multi-os-engine mostly useless over the next period of time (a couple of years maximum)

I’d absolutely volunteer!

One problem still:
I’d call myself a good java developer, I also had some experience with C++ in the past, but there are lacks of knowledge in parts the next level of the project would aquire. I’m willing to learn of course, but I’d also look out for other people helping building “multi-os-engine 2.0”.

Thanks for reading and have a nice weekend!!!


(Ivan) #2

too bad…MOE since first day is already open source but… so far only one person fork it and made a minor changes…

i remember kotlin also got some thing similar to MOE but way more active…


(Christian Ringshofer (Das Weiße Lama)) #3

But does the Kotlin alternative also fully support jvm based libraries? What I have seen is, that some of the kotlin projects on github also use moe (maybe without really knowing the destiny of the project)


(Ivan) #4

ya, i think you are right, their way is not create a full set JVM but just make the required libraries cross platform.
but I think their move are quite fast. Not only they support mobile but desktop as well.
I love full set JVM as well at least I know I can compile my existing Java without any headache.

https://kotlinlang.org/docs/reference/native-overview.html


(Ivan) #5

What make Kotlin Native so powerful is…iOS can access Kotlin Native library as well.


(Christian Ringshofer (Das Weiße Lama)) #6

Yeah, but wouldn’t it still be possible? With iOS I can also access registered classes done with Moe…

But I guess you’ve got my point.

I think the current repository Setup of moe is a huge mess, which by itself already causes a headache when thinking about contributing to it. It’s not a good practice to have an extra GitHub repo for every thought and tiny chunk of code. Especially when you want people to take part in the project. Secondly, it still is worse when only one person manages the code.

Like on the libgdx project where Mario zechner seemed to have completely abandoned the release cycle of the framework, despite the fact that the contributors are still quite active.

The only thing which is quite okay is the intellij plugin having its own repo.

So first for improving the motivation of contribution, I probably would want to change the structure of the repositories (maybe putting stuff together, the repos are not even huge)


(Kees Van Dieren) #7

Robovm also is still alive. We are using Robovm and MOE, but see Robovm is much more active. See https://gitter.im/MobiVM/robovm and https://github.com/MobiVM


(Ivan) #8

yes,way more active, almost every week i received their update…


(Guilherme Campos Hazan) #9

Hi, in the past 2 weeks i ported my libgdx+moe project to use libgdx+robovm, and i must say that RoboVM is very easy to use. Moe was a great idea and a great project but it is really dead, even if the owner says that some day he will dedicate time to improve the project.


(Eugene) #10

What people think of this?

https://mail.openjdk.java.net/pipermail/mobile-dev/2019-June/000584.html

And


(Ivan) #11

JavaFX, I think Flutter better in terms of performance. Since both draw their own widgets or controls.
Plus, Flutter makes coding like connections much much more easier. I tested JavaFX on Android, performance really bad. feel like web client.


(Eugene) #12

They are saying Java and Javax. So maybe moe bindings for ios api may work with Java compiled ahead of time too.


(Raphael) #13

I would be open to help in upgrading MOE. But I am definitely not an export, nor do I have plenty time :frowning:


(Mohammad F) #14

Hi there I really like to contribute , I used libgdx a lot in my project and I really like it due to it’s awesome performance.
Can you suggest where to start and how to contribute ?
Libgdx and moe really need support because they are awesome super cool performance projects
I really think that contributing in this project make me evolve to a better programmer and I don’t want to miss opportunity like this


(Leejjon) #15

If something like this happens I’ll use it to update my existing app. I might be able to help testing and create a PR if I find something simple enough to fix.

But for new projects I’ll just make PWA’s. As much as I prefer Java over JavaScript, it is easier to have one JS codebase and distribute it yourself. Screw the App stores and the money they try to take.