Following some of the discussion on this post from the forum at Intel, has there been any discussion on support for building frameworks or pods to include in existing iOS projects? The largest barrier to introducing shared code between our iOS and Android teams is that the iOS team would have to switch to a MOE project. Being able to distribute a library as a pod would let many orgs start using MOE without fully switching over their iOS team.
Ideally we would be able to build and distribute a standalone Java library project as both a JAR (for Android) and a framework/pod (for iOS).
From the previous thread:
If your client wants to develop in Objective-C / Swift, then your Java library and Objective-C bindings could be distributed as CocoaPods. We would provide special CocoaPod recipes for such Java libraries and their dependencies, so the end user only have to specify the pods in her project configuration, and the build will automatically combine the different Java libraries, minify them using proguard and add the MOE runtime as a framework dependency to the project. The end user only has to add a single line (MOE_init(argc, argv) in the main.m, before UIApplicationMain() is called. This will initialize the MOE VM and set up its connection with the Objective-C runtime. After that the Java library can be accessed through the Objective-C wrappers, without the need of JNI calls.
the necessary changes were already commited to MOE core, so it can load the precompiled Java code from a framework and not just from the main binary. This was a prerequisite to integrate MOE with CocoaPods. Based on our experiments, the approach seems to work well. We will need to create a CocoaPods plugin to make the integration of MOE based components with regular CocoaPods projects easier. We will look into this in more detail, once the open sourcing is done.
Is this cocoapods plugin available? If not, can you share a sample project with a manual procedure of building cocoapod libraries?
In your first reply on the forum at Intel, you said:
Currently MOE does not support packaging everything into a framework (including the runtime + Java code) for redistribution. We could add the required entry points quite easily: the MOE runtime uses JNI internally for startup, just like RoboVM in the MyJavaFramework samples, and it would work fine: as long as an app only uses a single Java framework.
The last requirement (“as long as an app only uses a single Java framework”) isn’t an issue for us right now. Could you share a way of building a classical ios framework as well?
An automated, one-click, solution in the future would be nice of course, but It would be great to have a manual way, even tedious, to create a framework / cocoapod bundle right now.
we created a prototype of the CocoaPods plugin earlier, prior to the open-sourcing of MOE. However, the main topic for MOE 1.3 is to revamp the handling of 3rd party libraries, and as part of this work we plan to introduce proper CocoaPods support both to consume CocoaPods libraries and to use MOE libraries in a CocoaPods project.
We will use this forum for a public design review, and we would very much appreciate your feedback.
is there any news from deciding if a “build as framework” or “build as cocoapod” will be officially supported by MOE someday soon? Actually we used the Dynamic Library feature from RoboVM heavily and successfully in the past and we are in real need for an adequate replacement. The two discussed solutions would be MOE (closest to current solution and preferred) or J2Objc (needs a lot more rework).
A prototype similar to the RoboVM MyJavaFramework example was mentioned in this thread. If there is something available to test and try out I would be happy to help.
While it does not provide a direct 1 on 1 replacement to the dynamic library framework feature of RoboVM (which had its own problems), it provides a simple way to add MOE based code to any Xcode project, including projects using CocoaPods.
Dear kisg,
Hope MOE 2.x will support watchOS, tvOS after moe2.x support android7 and bitcode,
In fact according the roadmap, MOE 1.3 is great, it make MOE1.3 true native iOS development platform, the best iOS development tool using java. MOE 1.3 will make java just like swift, objective C.
Thanks.
in the main.m, before UIApplicationMain() is called. This will initialize the MOE VM and set up its connection with the Objective-C runtime. After that the Java library can be accessed through the Objective-C wrappers, without the need of JNI calls.
in the main.m, before UIApplicationMain() is called. This will initialize the MOE VM and set up its connection with the Objective-C runtime. After that the Java library can be accessed through the Objective-C wrappers, without the need of JNI calls.