Home Features Docs Blog Support GitHub

MOE 1.4.0 with Xcode 9 support is available for testing


(Gergely Kis - Migeran) #1

Dear MOE Users,

we just uploaded the MOE 1.4.0 build. It is not tagged yet in the repository, and the samples are not yet updated, because we want to get some more testing before we encourage everyone to upgrade.

In this (pre)release:

  • Xcode 9 is required
  • Support for launching Xcode 9 simulators
  • Support for launching apps on iOS 11 devices
  • Generated bindings for iOS 11 APIs
  • Updated error reporting and fixed race condition in Maven plugin (many thanks to Dukescript for their pull request!)

How to test:

  1. Clone the MOE samples repository

    git clone https://github.com/multi-os-engine/moe-samples-java
    
  2. Update the moe-gradle plugin version to 1.4.+

  3. Run ../gradlew moeUpdateXcodeSettings from the ios module folder

  4. Import the project into your favorite IDE

  5. Launch / Debug as usual

The IDE plugins don’t have to be updated for this release.

Please share your experience (and of course any issues) with us.

Best Regards,
Gergely


XCode 9 build error "Type redefinition 'uint_least16_t'" on Swift header import
(Kees Van Dieren) #2

We have tested Xcode 9 with one of our MOE customer apps.

We have a fluent upgrade experience, nothing unexpected!

Things tested:

  • Changed MOE version to 1.4.0 in build.gradle
  • Run ./gradlew moeUpdateXcodeSettings
  • Run ./gradlew clean && ./gradlew build
  • Open XCode project
  • Run on iPhone 5s simulator
  • Run on connected iPhone device.

Thanks for the new version!


(Gergely Kis - Migeran) #3

Hi Kees,

thanks for the report.

In the meantime the source code for the new release was also pushed to Github on the moe-master branch.

You may get it, like this:

repo init -u https://github.com/multi-os-engine/manifest -b moe-master
repo sync

(Leejjon) #4

No problems running it on an iPhone SE from my mac mini from xcode. Will test remote build tomorrow.


(Alan Hamilton) #5

It looks like libimobiledevice.dylib is linked against the wrong version of liblzma. It is linked against version 8.0.0, but a standard macOS install only has version 6.0.0. See the exception below from a clean macOS install. A workaround is to brew install xz, which has version 8.0.0 of liblzma.

Exception in thread "main" java.lang.UnsatisfiedLinkError: /Users/auser/.moe/moe-sdk-1.4.0/tools/macosx/x86_64/libimobiledevice.dylib: dlopen(/Users/auser/.moe/moe-sdk-1.4.0/tools/macosx/x86_64/libimobiledevice.dylib, 1): Library not loaded: /usr/local/opt/xz/lib/liblzma.5.dylib
 Referenced from: /Users/auser/.moe/moe-sdk-1.4.0/tools/macosx/x86_64/libimobiledevice.dylib
 Reason: Incompatible library version: libimobiledevice.dylib requires version 8.0.0 or later, but liblzma.5.dylib provides version 6.0.0
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
at java.lang.Runtime.load0(Runtime.java:809)
at java.lang.System.load(System.java:1086)
at org.moe.ios.device.launcher.Main.loadNativeLibraries(Main.java:51)
at org.moe.ios.device.launcher.Main.main(Main.java:94)

otool -L output for 1.4.0 (after brew install xz):

MacBook-Pro-4:mydir auser$ otool -L ~/.moe/moe-sdk-1.4.0/tools/macosx/x86_64/libimobiledevice.dylib 
/Users/auser/.moe/moe-sdk-1.4.0/tools/macosx/x86_64/libimobiledevice.dylib:
	libimobiledevice.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/local/opt/xz/lib/liblzma.5.dylib (compatibility version 8.0.0, current version 8.2.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

otool -L output for 1.3.8:

MacBook-Pro-4:mydir auser$ otool -L ~/.moe/moe-sdk-1.3.8/tools/macosx/x86_64/libimobiledevice.dylib 
/Users/auser/.moe/moe-sdk-1.3.8/tools/macosx/x86_64/libimobiledevice.dylib:
	libimobiledevice.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/liblzma.5.dylib (compatibility version 6.0.0, current version 6.3.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

Testing my app on ios device leads to error:
(Leejjon) #6

Had some signing issues but figured them out.

I seem to have the same problem as Alan_Hamilton now when I try to run from Android Studio. Installing xz via brew solved it.

Here’s my update on testing remote build:


(David Wernhart) #7

I am trying to migrate my existing moe 1.3 project to 1.4, but sadly, I had no luck so far.

after changing the moe version in the build.gradle to 1.4, none of my bindings get recognized anymore.
I get errors like this:

Error:(96, 38) Gradle: error: name clash: errorWithDomainCodeUserInfo(String,long,NSDictionary<?,?>) in GADRequestError and errorWithDomainCodeUserInfo(String,long,NSDictionary<String,?>) in NSError have the same erasure, yet neither hides the other
Error:(114, 31) Gradle: error: name clash: initWithDomainCodeUserInfo(String,long,NSDictionary<?,?>) in GADRequestError and initWithDomainCodeUserInfo(String,long,NSDictionary<String,?>) in NSError have the same erasure, yet neither overrides the other

Re - generating the bindings with the .nbc files does not work eighter, it throws an error too.
I also updated the xcode settings with the gradle command, but no luck here.

Did I miss some steps? Is it even possible to migrate a project from 1.3 to 1.4 right now?

Thanks for the new version and for the help!

Best regards,
David Wernhart


#8

moe 1.4 changed the argument type for methods take generic parameters. Most of them become more specific instead of Foo<?> (NSDictionary instead of NSDictionary<?, ?> in your case). But in Java Foo and Foo<?> have same earsed type signature so you will get those errors.


(David Wernhart) #9

thank you for the reply!

but does that mean I have to rewrite my bindings manually or is there something else I can do?


(Gergely Kis - Migeran) #10

Dear David,

we are looking into this.

Best Regards,
Gergely


(Roland Vigh - Migeran) #11

Hi!

We updated moe-bindings to MOE 1.4.0 and regenerated all bindings:

Best Regards,
Roland


(Gergely Kis - Migeran) #12

Hi @Noisyfox,

Could you please elaborate where do you see type-erased NSDictionary instances? We saw that due to the iOS 11 changes, some APIs are now generated differently (e.g. as NSDictionary<String, ?> instead of NSDictionary<?,?>).

Thank you for your help in advance.

Best Regards,
Gergely


(David Wernhart) #13

thank you for your help! I managed to get my project up and running with MOE 1.4 now, but I want to add some new bindings for firebase. I basically took the .nbc file from the moe-bindings github page, but when I want to create the bindings, I get the following error:
58

It would be really helpful for me to know how to fix this.

Thank you and best regards,
David Wernhart


(Gergely Kis - Migeran) #14

Dear David,

despite this error output, the bindings should have been correctly generated (at least this is our experience).

We are working on removing this error, in the meantime, could you please check if the bindings are generated for you?

Best Regards,
Gergely


Generate Bindings Error
#15

In our case, the interface AVCaptureMetadataOutputObjectsDelegate changed from

public void captureOutputDidOutputMetadataObjectsFromConnection(
AVCaptureOutput captureOutput, NSArray<?> metadataObjects, AVCaptureConnection connection )

to

public void captureOutputDidOutputMetadataObjectsFromConnection(
AVCaptureOutput output, NSArray<? extends AVMetadataObject> metadataObjects, AVCaptureConnection connection )

give us the same compile error after upgrade to 1.4.


Libgdx my game is just black after splash screen using ios 11
(Nicolas Prugne) #16

Thanks a lot! I just add the two commands needed to brew install xz to your post.

If you don’t have Homebrew installed on your machine run this:

Then run:

  • brew install xz

Testing my app on ios device leads to error:
(Василий Кудрявцев) #17

Dear colleagues,
have you finalized your plans on Android 8/OpenJDK support?
we’ll be very thankful if you already have date of planned release for A8
do you plan early access for MOE 2.0 for your enterprise customers?


(Viet Dzung) #18

Seem good so far, but the CPU using are very high. My project is an Libgdx game. I test with both real device and simulator on iOS 10.3 and iOS 11.1. it use more than 30% of CPU even with a blank project generate by Libgdx Setup app. It is both on real device and Simulator. My CPU is core i7 @2.66GhzX4


#19

My iMac also has experienced CPU spikes while building iOS apps with 1.4.0. This did not happen with 1.3.10.

My iMac is brand new and has latest gen 3.6 GHz Intel Core i7 with 16 GB RAM and 512 SSD. I’m running Sierra (OSX 10.12.6). So far MOE 1.4.0 is the only thing that can make the internal fan kick on loud enough to notice it.

Activity Monitor shows a “java” process taking over 300% of CPU at times. I should mention that this doesn’t happen on every build, and it seems to happen more often when I’m using the iPhone X simulator.

Other than that everything has worked great for me. I’m using Android Studio 3.0.1 with MOE 1.4.0 and Xcode 9.1. Already built and published an app update to the App Store (adding iPhone X support) with this setup and everything seems to be going as usual.

Also recently upgraded Gradle to 4.1 and I’m using the classpath “com.android.tools.build:gradle:3.0.1” (I use LibGDX). Everything going fine with that too. Good job MOE Team!


(Gergely Kis - Migeran) #20

Dear MrPat,

could you please elaborate a bit which java process seems to eat that much CPU? Does it happen during building or during running your app on the iPhone X Simulator?

Could you please try also MOE 1.4.1 and Xcode 9.2 just to make sure that you can still reproduce it with the latest tools?

Best Regards,
Gergely