MOE 1.3.0 beta 2 released

Comments
1

We are pleased to announce the release of the second beta of MOE 1.3. We already shared our plans for MOE 1.3 in a previous blog post and since the last beta a lot of improvements have been made.

This is a companion discussion topic for the original entry at https://multi-os-engine.org/blog/2017-01-25-moe-1.3.0-beta-2-released/
2 Likes
2
3

Any news on Java 8 support. When I google it it still says you have to use retrolambda.

4

Dear Leejjon,

yes, currently Java 8 is supported via Retrolambda, but you don’t have to set it up manually. Because we think this is an important feature, we integrated Retrolambda into our Gradle plugin, so you can use lambdas and default methods out-of-the-box.

Our handling of Java 8/Retrolambda/ProGuard will change in MOE 2.0. MOE 2.0 is based on Android N which uses Jack for ProGuarding and Java 8 support. Also the Java APIs in Android N are based on OpenJDK 8, which will also be available.

Best Regards,
Kristóf

2 Likes
5

Is there going to be another beta before 1.3 release? What is the tentative timeframe for 1.3?

6

We have a few items on the TODO list, e.g. the NatJGen improvement to handle id<Protocol> types better. We will release when we are ready with those. If there are bugs discovered that need quick fixes, we will release another beta, otherwise the next one will be the 1.3 final.

This beta should be stable for general use, I would recommend this one over 1.2.x any day.

7

Are there plans to handle generics better in the generated bindings and bindings for standard ios frameworks?

I can provide more specific examples, but right now you have to resort to specific casting in the java code when working with most of collections and that is cluttering code quite a lot and producing a lot of compiler warnings.

8

Sure, please provide examples that make the use of the bindings cumbersome. The same code runs to create the SDK and the 3rd party bindings, so both will follow the same pattern. Please create a separate thread in the forum for each issue that you see.

9

Strangely, I switched to beta-2 on Jan 15 and it supposed to have bindings for SystemConfiguration/CaptiveNetwork.h

But I don’t see classes like CNCopyCurrentNetworkInfo or CNCopySupportedInterfaces and all related structures in moe jars from beta-2. Were there updated jars after January 15?

Please advise.

1 Like
10

These are C functions in the SystemConfiguration framework, so you can find them in the apple.systemconfiguration.c.SystemConfiguration class as static functions.

    @Generated
    @CFunction
    public static native CFArrayRef CNCopySupportedInterfaces();

    @Generated
    @CFunction
    public static native CFDictionaryRef CNCopyCurrentNetworkInfo(CFStringRef interfaceName);
1 Like
11

Thank you Gergely, I completely missed that. So I managed to port this objc code:

NSArray *interfaceNames = CFBridgingRelease(CNCopySupportedInterfaces());

NSDictionary *SSIDInfo;
for (NSString *interfaceName in interfaceNames) {
    SSIDInfo = CFBridgingRelease(CNCopyCurrentNetworkInfo((__bridge CFStringRef) interfaceName));
    if (SSIDInfo.count > 0) {
        return SSIDInfo;
    }
}

So, Java version look something like this:

NSArray<String> arr = (NSArray<String>) Foundation.CFBridgingRelease(SystemConfiguration.CNCopySupportedInterfaces());
for (String intName : arr) {
  NSDictionary<String, ?> SSIDInfo = (NSDictionary<String, ?>) Foundation.CFBridgingRelease( //
    SystemConfiguration.CNCopyCurrentNetworkInfo(
        CoreFoundation.CFStringCreateWithCString(
            CoreFoundation.kCFAllocatorDefault(),
            intName, CFStringBuiltInEncodings.UTF8)));
  String key = (String) Foundation.CFBridgingRelease(SystemConfiguration.kCNNetworkInfoKeySSID());
  return (String) SSIDInfo.get(key);
}

That’s very cool and it is working! Though some of the casts could be improved.