after almost 1.5 years since the last release (MOE 1.4.4) we are reviving the Multi-OS Engine project. We started working on MOE in 2013 (back then it was called Migeran for iOS), and it will always have a special place in my professional life. Therefore it is my great personal sorrow, that we have left the project without maintenance for so long. I don’t want to delve into the past why and how this could happen. Instead let’s look into the future, and see how we can make sure that this does not happen again.
But first, I want to express my deepest gratitude towards you, the MOE Community who kept using MOE and demanded updates. You are a big part of MOE and a huge inspiration to continue this journey. I would like to thank especially NoisyFox, who even created community builds to make sure MOE works with newer versions of the Apple and Android tools.
Now let’s see what are the next steps for MOE.
We already started working on the next release, that will make MOE functional again on current XCode and iOS versions. This release will include:
It will most probably not include any new APIs (except for those that the generator can pick up without any changes).
In October we plan to release the next update that will include:
We are committed to turning MOE into a true Community Project. This means multiple things:
We have way more plans and ideas for the future, that we are going to share in future updates. In the next update I will take a look at different components of MOE (the runtime, Nat/J and the generator … etc.), and what you can expect in the foreseeable future.
As always, feedback is very welcome here in the comments or on the forum.
Looking forward to hearing from you.
Gergely Kis
MOE Project Lead
today we moved the https://multi-os-engine.org website to GitHub Pages, so anyone can send in PRs to update the website.
]]>after almost 1.5 years since the last release (MOE 1.4.4) we are reviving the Multi-OS Engine project. We started working on MOE in 2013 (back then it was called Migeran for iOS), and it will always have a special place in my professional life. Therefore it is my great personal sorrow, that we have left the project without maintenance for so long. I don’t want to delve into the past why and how this could happen. Instead let’s look into the future, and see how we can make sure that this does not happen again.
But first, I want to express my deepest gratitude towards you, the MOE Community who kept using MOE and demanded updates. You are a big part of MOE and a huge inspiration to continue this journey. I would like to thank especially NoisyFox, who even created community builds to make sure MOE works with newer versions of the Apple and Android tools.
Now let’s see what are the next steps for MOE.
We already started working on the next release, that will make MOE functional again on current XCode and iOS versions. This release will include:
It will most probably not include any new APIs (except for those that the generator can pick up without any changes).
In October we plan to release the next update that will include:
We are committed to turning MOE into a true Community Project. This means multiple things:
We have way more plans and ideas for the future, that we are going to share in future updates. In the next update I will take a look at different components of MOE (the runtime, Nat/J and the generator … etc.), and what you can expect in the foreseeable future.
As always, feedback is very welcome here in the comments or on the forum.
Looking forward to hearing from you.
Gergely Kis
MOE Project Lead
MOE 1.3 is a big improvement over 1.2 with lots of new features. Most of these features were already included in the previous beta releases. Read on to find out what new stuff we included in the final release of 1.3.
Feedback is very welcome here in the comments or on the forum.
The iOS bindings were updated with more accurate type information in function pointers and blocks. We also updated internal bindings for clang and libimobiledevice.
We started a new MOE Bindings repository with pre-generated MOE bindings for a number of frequently used libraries:
The generated bindings can be published to your local maven repository using the following command:
./gradlew :<module-name>:publishMavenJavaPublicationToMavenLocal
Then you just need to add it as a regular Maven dependency in your MOE app. Don’t forget to link to the native part of the library as well, e.g. using CocoaPods.
Each binding project also doubles as a test project for the bindings, so you can import them into your IDE and try them out.
We intend to publish these bindings to JCenter, once they received a bit more testing.
The samples were updated to MOE 1.3. Some obsolete samples were removed. A new SimpleCharts based sample was added showing the use of a Swift library in a MOE App.
If you are a 1.3 beta user, then you can upgrade the following:
1.3.0-beta-2, for example 1.3.+. To force the upgrade, you can run ./gradlew --refresh-dependencies.<dependency>
<groupId>org.multi-os-engine</groupId>
<artifactId>moe-maven</artifactId>
<version>1.3.0</version>
<type>pom</type>
</dependency>
Multi-OS Engine Actions > Inject/Refresh Xcode Project SettingsTo install or upgrade to the MOE 1.3.0 plugin in Eclipse, you need to add the following plugin repository:
We created a more detailed guide for upgrading from MOE 1.2.
The command line tool is not present yet, but if you create a new MOE project, then replace the Xcode project with your existing one, then you can already run the Xcode updater command from your IDE.
We wanted to get the new version out to you as soon as possible. We will continue working on updated documentation and release updates as the become available. This blog post contains the most relevant information about the new version. If you get stuck, or run into a bug, you can contact us on our forum.
We designed MOE 1.3 based on the requests and reports from the MOE Community. We hope, that you will like these new features, and they will make your life easier as a developer.
As always, leave your comments below, so we will know your opinion on all the changes and plans. The development of MOE is based on the requirements of the community, so we are open to discuss any changes in direction or features for future releases.
If you need a specific feature in MOE, you may consider contracting Migeran, the core developers and project lead of the MOE project to develop it.
Also, if you are working on a commercial project with MOE, Migeran offers commercial support, including live online support with Migeran’s top engineers. Contact Migeran for more details.
]]>Please, keep in mind that this is a beta release, so be prepared for some bugs and rough edges. Feedback is very welcome here in the comments or on the forum.
iOS bindings in the new beta contains support for iOS 10.2. Also added bindings for the community requested SystemConfiguration/CaptiveNetwork.h.
There were also some fixes in existing bindings:
+initialize and +load method bindings were removed. Both of these methods shouldn’t be invoked directly and only caused issues with third party library bindings.The binding generator with the new nbc file support is already a big change, however there is always room for improvement. In this release we added support for handling custom runtime names for Objective-C classes and protocols. This allows our users to create bindings for 3rd party libraries which are written in Swift but are Objective-C compatible. Our new sample - SimpleChart - already makes use of this feature.
The SDK installation process was removed in this beta. When Gradle downloads the MOE SDK, there are no additional processing steps other than extracting it. In return the SDK is prepared faster and the process is much less error prone.
We added support for choosing between generating hybrid or binding classes. By default we supported binding classes. This gave you access to Objective-C APIs in Java. Hybrid classes extend on this by enabling you to extend existing Objective-C classes with Java code without inheritance.
This feature is mostly used to implement / extend UIViewController classes, that were created in Xcode and used in Storyboard designs. (Note, that MOE supports also generating Objective-C UIViewController stubs in Java UIViewController classes, if you prefer to start the implementation of your UI code from Java.)
In this beta we improved resource handling in the Gradle plugin. All resources should be correctly collected. Jar dependencies, custom resource directories, source set dependencies, etc. should work just fine.
Generating UI actions and outlets can now be configured. We added support for adding custom code snippets, disabling library imports and specifying which classes should be used during generation. You can read more about this here.
Other than the above changes, we also made a lot of under-the-hood improvements in NatJ, NatJGen, Gradle plugin, Maven plugin, IDEA plugin, Eclipse plugin and other components.
If you are a 1.3 beta 1 user, then you can upgrade the following:
1.3.0-beta-2, for example 1.3.+. To force the upgrade, you can run ./gradlew --refresh-dependencies.<dependency>
<groupId>org.multi-os-engine</groupId>
<artifactId>moe-maven</artifactId>
<version>1.3.0-beta-2</version>
<type>pom</type>
</dependency>
Multi-OS Engine Actions > Inject/Refresh Xcode Project SettingsTo install or upgrade to the MOE 1.3 beta 2 plugin in IntelliJ (and Android Studio), you need to add a custom plugin repository with the following URL:
https://plugins.jetbrains.com/plugins/Beta/8559
After refreshing the repository contents, the 1.3.0-beta-2 plugin version will be available for installation or upgrade.
To install or upgrade to the MOE 1.3 beta 2 plugin, you need to add the following custom plugin repository:
We created a more detailed guide for upgrading from MOE 1.2.
This is a second beta release, so we have a few known limitations.
Most of our Java samples are updated to 1.3. Don’t worry, Kotlin samples are on our TODO list!
The command line tool is not present yet in this first beta, but if you create a new MOE project, then replace the Xcode project with your existing one, then you can already run the Xcode updater command from your IDE.
The MOE documentation in general was not yet updated for the new version. This blog post contains the most relevant information about the new version. If you get stuck, or run into a bug, you can contact us on our forum.
This beta should have a working Windows support, but is was not heavily tested.
We designed MOE 1.3 based on the requests and reports from the MOE Community. We hope, that you will like these new features, and they will make your life easier as a developer.
As always, leave your comments below, so we will know your opinion on all the changes and plans. The development of MOE is based on the requirements of the community, so we are open to discuss any changes in direction or features for future releases.
If you need a specific feature in MOE, you may consider contracting Migeran, the core developers and project lead of the MOE project to develop it.
Also, if you are working on a commercial project with MOE, Migeran offers commercial support, including live online support with Migeran’s top engineers. Contact Migeran for more details.
]]>As mentioned in the release announcement, MOE 1.3 includes a tool to upgrade the Xcode part of a MOE 1.2 project without manual intervention.
In this blog post we will look at how a project created by the LibGDX 1.9.5 setup tool can be upgraded to use MOE 1.3. If you already have a MOE 1.2 based LibGDX project, you may follow the following guide to upgrade it as well.
This guide assumes, that you already installed the MOE 1.3 versions of your IDE plugins.
Create your new LibGDX project by running the tool from the command line.
java -jar gdx-setup.jar
ios-moe platform to create the MOE based iOS module.moe-gradle plugin version to 1.3.0-beta-1ios-moe module change the moe section in the build.gradle file as follows:moe {
xcode {
project 'xcode/ios-moe.xcodeproj'
mainTarget 'ios-moe'
testTarget 'ios-moe-Test'
}
}
ios-moe module and use the Multi-OS Engine Actions > Inject/Refresh Xcode Project SettingsNow your project should be ready for MOE 1.3. Launch from your IDE and Enjoy!
Note: If you have not used MOE before, then you will need to set up code signing. Follow the instructions on the MOE Website on how to set the default team for developer signing.
We designed MOE 1.3 based on the requests and reports from the MOE Community. We hope, that you will like these new features, and they will make your life easier as a developer.
As always, leave your comments below, so we will know your opinion on all the changes and plans. The development of MOE is based on the requirements of the community, so we are open to discuss any changes in direction or features for future releases.
If you need a specific feature in MOE, you may consider contracting Migeran, the core developers and project lead of the MOE project to develop it.
Also, if you are working on a commercial project with MOE, Migeran offers commercial support, including live online support with Migeran’s top engineers. Contact Migeran for more details.
]]>Please, keep in mind that this is a beta release, so be prepared for some bugs and rough edges. Feedback is very welcome here in the comments or on the forum.
The new Xcode project layout is more versatile and even less intrusive than our previous version in MOE 1.2. We also include a tool, that will update your MOE 1.2 Xcode project to MOE 1.3 from your favorite IDE.
The new Xcode project layout also supports using CocoaPods and other iOS specific options, e.g. the use of Xcode Workspaces.
Now the binding generator has a new configuration file + a GUI editor (in Eclipse and IntelliJ / Android Studio as well). To create a new binding use the Multi-OS Engine Actions > Create New Binding action from the context menu.
Now it is not necessary to open Xcode to make some basic adjustments to your Xcode configuration. Both Eclipse and IntelliJ / Android Studio includes a simple Xcode editor. You can edit the same settings that were allowed previously in the build.gradle file when build time Xcode project generation was enabled.
This feature will mostly help those, who are working on Windows, and they don’t have direct access to a Mac.
You may open the Xcode editor using the Multi-OS Engine Actions > Open Xcode Editor menu item.
As outlined in our plans for MOE 1.3 there are 2 ways to integrate with the Storyboard UI Designer in Xcode
One option is to create ViewController stubs in Objective-C and use the binding generator (with the new binding generator configuration) to generate the Java bindings for these stubs, and extend them in Java.
The other option is to create the ViewControllers in Java and generate Objective-C stubs, that can be used from Xcode to bind the IBOutlets and IBActions to a UI Design.
See below in the New Use Cases section for more details.
This beta release is released in parallel with the stable MOE 1.2 series. Therefore you need to use custom repositories for the IDE plugins.
https://plugins.jetbrains.com/plugins/Beta/8559http://dl.bintray.com/multi-os-engine/eclipse-dev/The SDK and Gradle plugin is released in the standard repository, just update your Gradle plugin dependency to 1.3.0-beta-1 in your build.gradle file.
If your project is still using build-time Xcode project generation, you will need to convert to the permanent Xcode project setup, as follows:
build/xcode folder to the xcode folder.Update the build.gradle file with the following Settings
moe {
xcode {
generateProject false
project 'xcode/<projectname>.xcodeproj'
}
}
First, you need to update the MOE Plugin in your IDE. Then, change the MOE Gradle plugin to 1.3.0-beta-1 in your build.gradle file, and reimport / synchronize your project with your updated IDE.
Finally, right click on the project and choose the Multi-OS Engine Actions > Inject/Refresh Xcode Project Settings menu item.
pod installIn your MOE module’s build.gradle file set up the following properties:
moe.xcode.workspace 'path/to/xcworkspace'
moe.xcode.mainScheme '<Scheme Name>'
moe.xcode.testScheme '<Scheme Name>'
Multi-OS Engine Actions > Create New Binding menu item.Configure the binding, e.g. set the desired base package and specify an import code For example:
#import "AFNetworking.h"
Generate (in Eclipse the UI is slightly different)UIViewControlleralloc() and init() methods@Runtime(ObjCRuntime.class)
@ObjCClassName("MyViewController")
@RegisterOnStartup
public class MyViewController extends UIViewController {
Add the desired action methods like this:
@IBAction
@Selector("myButtonAction:")
public void myButtonAction(UIButton view) {
}
Add the desired outlets like this:
private UIView outlet;
@IBOutlet
@Property
@Selector("outlet")
public UIView getOutlet() {
return outlet;
}
@IBOutlet
@Property
@Selector("setOutlet:")
public void setOutlet(UIView v) {
outlet = v;
}
Multi-OS Engine Actions > Generate Actions and Outlets for Interface Builder menu itemMulti-OS Engine group.This is a first beta release, so we have a few known limitations.
Only the Calculator and the CurrencyConverter samples were updated so far.
The command line tool is not present yet in this first beta, but if you create a new MOE project, then replace the Xcode project with your existing one, then you can already run the Xcode updater command from your IDE.
Eclipse Mars is not supported in the beta version. We have an ongoing RFC on our forum to discuss if Mars support is still needed.
The MOE documentation in general was not yet updated for the new version. This blog post contains the most relevant information about the new version. If you get stuck, or run into a bug, you can contact us on our forum
Please do not try this on Windows yet, it is completely untested. Full Windows support will return in the final MOE 1.3 release.
We designed MOE 1.3 based on the requests and reports from the MOE Community. We hope, that you will like these new features, and they will make your life easier as a developer.
As always, leave your comments below, so we will know your opinion on all the changes and plans. The development of MOE is based on the requirements of the community, so we are open to discuss any changes in direction or features for future releases.
If you need a specific feature in MOE, you may consider contracting Migeran, the core developers and project lead of the MOE project to develop it.
Also, if you are working on a commercial project with MOE, Migeran offers commercial support, including live online support with Migeran’s top engineers. Contact Migeran for more details.
]]>Please read on for more information on the changes that were introduced by each patch release.
To update from an earlier MOE 1.2 SDK / Gradle plugin version, you should run Gradle with the --refresh-dependencies option.
The IDE plugins can be updated using the standard plugin update mechanism from inside the IDE. (IDE plugin versions may differ from SDK versions.)
In this blog post we will outline our plans for the next couple of months.
Since the start of the Multi-OS Engine Open Source Project we made a number of releases:
We are planning a number of releases in the next months:
MOE 1.3 is a huge update, it includes:
In fact, we prepared another blog post to provide details about the new features of MOE 1.3 and beyond. Read on here for all the cool, new stuff!.
MOE 2.0 will have 2 main features:
Despite the big internal changes, MOE 2.x will be mostly a drop-in replacement from the app developer’s point of view.
We will provide more details of the new features in future blog posts.
We designed the MOE Roadmap based on the requests and reports from the MOE Community. We hope, that you will like these new features, and they will make your life easier as a developer.
As always, leave your comments below, so we will know your opinion on all the changes and plans. The development of MOE is based on the requirements of the community, so we are open to discuss any changes in direction or features for future releases.
If you need a specific feature in MOE, you may consider contracting Migeran, the core developers and project lead of the MOE project to develop it.
Also, if you are working on a commercial project with MOE, Migeran offers commercial support, including live online support with Migeran’s top engineers. Contact Migeran for more details.
]]>For a general overview of our roadmap, check out our MOE Roadmap post.
One of the main design goals of the Multi-OS Engine is to be a versatile, flexible tool for professional developers. This means, that when we design our tools and solutions, we try to accommodate the requirements of even the most complex projects and provide solutions for them.
Up to MOE 1.2, our build system required some specific settings in an Xcode project, including a build.xcconfig file. These requirements made it difficult to add MOE to an existing Xcode project. Working with a CocoaPods enabled Xcode project was not possible.
Starting with MOE 1.3, we will only require a few custom build phases and build settings in your main Xcode project. The build system will also work with Xcode workspaces.
MOE 1.3 will include a tool that can upgrade an MOE 1.2 Xcode project to MOE 1.3. This tool can also apply the required MOE settings to an existing Xcode project, similar to pod install in CocoaPods. This way it will be straightforward to add Java code to any iOS project.
The main goal of the Xcode project layout redesign was, that MOE should work together with any dependency management framework like CocoaPods or Carthage.
Our solution is basically to get out of the way of these frameworks, and only require minimal changes to the Xcode project.
Starting with MOE 1.3 you can add your native libraries to your MOE project the same way you would do in an Objective-C / Swift only iOS project, e.g. call pod install and pod update the same way you would do it with any other CocoaPods enabled project.
Up to MOE 1.2 we included a few custom actions in the IDE plugins, like Link third party framework / library or Link CocoaPods. With these features MOE promised that you could take any native library, and generate bindings for it with the click of a button.
There was only one slight problem with this: it only worked for simple cases. In more complex situations things failed with cryptic error messages.
The new method goes into a different direction, and introduces MOE Binding Projects. These projects are mostly regular MOE projects, where the native library was already imported into the Xcode project using the most convenient native dependency management method.
For Example the Google Play Services library for iOS is also distributed using CocoaPods, that can be used in the Binding Project as well.
The Binding Project also includes the Nat/J Generator configuration, that can be used to regenerate the Java bindings whenever a new version is released, and any handwritten convenience methods and classes to provide a smooth developer experience.
Finally, the Binding Project has a Gradle task to regenerate the binding and publish it as a Maven artifact in the Maven repository of your choosing.
These bindings can be reused in your MOE projects by simply adding them as a build dependency (and of course by adding the native counterparts to the associated Xcode project using the preferred method).
We are also creating a central repository of MOE bindings for the most frequently used iOS libraries. The binding projects will be hosted on GitHub with the rest of MOE, and the generated bindings will be added to JCenter and Maven Central for your convenience.
We already have a few bindings created (e.g. the already mentioned Google Play Services for iOS library).
Contributions of additional bindings are very welcome!
For productive app development Storyboard integration is crucial.
There are 2 options for working with Storyboards and MOE. These 2 options are not mutually exclusive, you may mix them in a single project, as you need.
In this case the ViewController classes are created manually in your favorite Java IDE. You have to make sure to add the correct @Selector annotations on your action methods and the @Property annotations on the properties that you want to make accessible from Objective-C. Then, the Synchronize to Xcode menu action will create the Objective-C stubs that correspond to your ViewController classes.
Up to MOE 1.2 the implementation of this function had several issues:
In MOE 1.3 the complete implementation was replaced with a new one:
Generate Actions and Outlets for Interface Builder#if preprocessor guards)In this case ViewController stubs are created in Objective-C, and used with Storyboards directly to connect the properties and actions. The Synchronize to Java action (we will rename it to be more descriptive) can be used to generate the Java bindings for these ViewController stubs. These Java classes can be extended with the action implementations, as usual.
Up to MOE 1.2 this action could only be executed on a single header file.
MOE 1.3 will allow the creation of a custom binding generation configuration (similar to binding projects), so you can easily generate Java bindings for your ViewController and other classes in complex situations as well.
MOE 1.3 will be a huge update, but these changes took time to develop. They are also closely connected to each other, so an incremental release strategy (adding new features one by one while keeping the old features functional) would have been even more difficult.
We will release a beta version of MOE 1.3 before the end of 2016. It will have a lot of the functionality already in place, so you can try out some of the new features. We are already using it for our own projects, so it should be relatively stable, if you are not afraid of hard edges, and some bugs here and there.
The final, polished release of MOE 1.3 will arrive in January 2017.
While MOE 1.3 will lay the stable foundations that we can build on, there will be features that simply won’t fit into this release. A few examples:
Also, MOE 2.x is in the works with the Android 7 based runtime and LLVM based compiler backend updates. While a lot is changing under the hood, it will be mostly a drop-in replacement / incremental upgrade from the app developer’s point of view, so every new MOE 1.x feature will still be available in MOE 2.x.
We designed MOE 1.3 based on the requests and reports from the MOE Community. We hope, that you will like these new features, and they will make your life easier as a developer.
As always, leave your comments below, so we will know your opinion on all the changes and plans. The development of MOE is based on the requirements of the community, so we are open to discuss any changes in direction or features for future releases.
If you need a specific feature in MOE, you may consider contracting Migeran, the core developers and project lead of the MOE project to develop it.
Also, if you are working on a commercial project with MOE, Migeran offers commercial support, including live online support with Migeran’s top engineers. Contact Migeran for more details.
]]>