MOE 1.4.0 with Xcode 9 support is available for testing

kisg · September 30, 2017, 9:31pm

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 · October 4, 2017, 8:27am

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

Alan_Hamilton · October 4, 2017, 10:45am

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)

Leejjon · October 4, 2017, 11:50pm

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:

wernimaster · October 11, 2017, 9:41pm

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

Noisyfox · October 12, 2017, 12:05am

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.

wernimaster · October 12, 2017, 8:12am

thank you for the reply!

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

kisg · October 12, 2017, 4:00pm

Dear David,

we are looking into this.

Best Regards,
Gergely

vighr · October 13, 2017, 8:01am

Hi!

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

Best Regards,
Roland

kisg · October 13, 2017, 1:29pm

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

wernimaster · October 15, 2017, 6:26pm

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:

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

Thank you and best regards,
David Wernhart

kisg · October 17, 2017, 10:18am

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

Noisyfox · October 17, 2017, 11:15pm

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.

nprugne · October 26, 2017, 10:52am

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:

/usr/bin/ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)” (see: https://brew.sh)

Then run:

brew install xz

dunemaster · November 17, 2017, 1:07pm

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?

dzungpv · November 24, 2017, 8:28am

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

MrPat · November 30, 2017, 10:02pm

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!

kisg · December 9, 2017, 11:28am

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

MrPat · December 12, 2017, 11:13pm

Well I haven’t done as much iOS development in the last few days. I updated to MOE 1.4.1 a few days ago but I’ve been mostly doing Android. I did do a few runs of my iOS apps today on the iPhone X simulator and my iPhone SE device and didn’t experience any problems.

If I remember correctly the runaway task just said “java” in the Activity Monitor, but I’m not certain of that. It always happened during the build and would go back to normal when the build finished.

Will let you know if it happens again but is looking good so far on 1.4.1. Thanks!

Andrea_Paci · May 4, 2018, 7:16pm

Idk if it’s a bit late, but i’ll try.
Everything works just fine, execpt for the run on connected iPhone device
Any hint?