Re: Sharing our experience with Xtend & Android

[Sven Efftinge]

Hi Duncan,

thanks for the feedback, they petty much reflect what we want to work on next (besides performance and bugfixes).

Note that there are bugzillas for some of the things you mentioned, you might want to subscribe on them to see when and how they are solved.

Keep the feedback coming.

thanks,

Sven

On Apr 11, 2013, at 2:27 PM, dmac...@gmail.com wrote:

Hi guys.

We are having a Hackweek at SUSE, and together with my colleague Johannes we started to port an Android app to 4.x APIs and before starting

we discussed about using Xtend for all new classes and rewritten code so that we get the chance to learn it. We decided to go for it.

Right now we have like 7-10 Xtend classes so we wanted to share our experience (I may reuse this for a blog post later).

 The overall experience has been good. However, there is some stuff that feels like a regression from Java:

- The ultra well known $:: mess with inner and static access. I make a mistake everytime I have to type that.

  eg: You type R::foo::foo to realize it is R$foo::bar, but then you write android$R::foo::bar, only to realize it is android::R$foo::bar.

- Johannes, without knowing about type literals, had a Class<? extend Activity> parameter, and passed SomeActivity::class as parameter. As a result

  the IDE became unstable, popups everywhere and Xtext errored about cross references. Changing to typeof(SomeActivity) fixed the issue. But we lost

  like half an hour debugging this one due to the meanless errors.

- The most annoying part is not having inner classes. Lambdas work well for one method functional interfaces, but most Android ones have more. That means you have to implement the interface, which sucks if you have 3 versions of them and want to create one class per kind of handling behaviour  So then you create a separate class, but Android manages the lifecycle of objects itself so you can't really pass context to the objects and don't have access to the outer class context.

- Ok, some minor stuff like not having bitwiseOr and having to spend 5 minutes googling to find out you can use a bitwiseOr() method on the object.

This language has lot of potential on Android, but there are still rough edges. I will share more feedback after we port more code.

Cheers

Duncan

--
You received this message because you are subscribed to the Google Groups "Xtend Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xtend-lang+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[pfr...@gmail.com]

Hi,

correct me if I'm wrong, but as far as I can tell, inner interfaces are not yet supported in the latest release of Xtend. As pointed out before, this is a rather essential feature for implementing stuff on Android and other SDKs. Is there an ETA for this feature?

In the meantime, is there any way to implement UIControl.OnTouchUpInsideListener in [1] using Xtend? 

Cheers,

Peter

[1] https://github.com/robovm/robovm-sample-ios-app/blob/master/src/main/java/org/robovm/sample/ios/RoboVMSampleIOSApp.java

[Sven Efftinge]

Hi Peter,

you can use static inner types. Just constructor calls to non-static inner classes are currently not supported.

The robovm example can be translated like this (without applying much Xtend sugar yet):

class RoboVMSampleIOSAppXtend extends UIApplicationDelegateAdapter {

    private UIWindow window = null

    private int clickCount = 0

    override didFinishLaunching(UIApplication application,

            NSDictionary<NSString, ?> launchOptions) {

  

        val button = UIButton.create(UIButtonType.RoundedRect)

        button.setFrame(new CGRect(115.0f, 121.0f, 91.0f, 37.0f))

        button.setTitle("Click me!", UIControlState.Normal)

        button.addOnTouchUpInsideListener [UIControl control, UIEvent event |

                button.setTitle("Click #" + (clickCount++), UIControlState.Normal)

        ]

        window = new UIWindow(UIScreen.getMainScreen().getBounds())

        window.setBackgroundColor(UIColor.colorLightGray)

        window.addSubview(button)

        window.makeKeyAndVisible

        

        return true

    }

    def static void main(String[] args) {

        val pool = new NSAutoreleasePool()

        UIApplication.main(args, null, RoboVMSampleIOSApp)

        pool.close()

    }

}

For more options, visit https://groups.google.com/d/optout.

[Sebastian Benz]

Hello everyone,

just a quick word of warning when using xtend on android. Android applications have a limit of 64K method references. This is usually not a problem, but can be for large applications using lots of libraries. Working around this can be quite painful [1]. A problem can be the xtend runtime libraries which alone already contain 16541 method references, which considerable decreases your headroom when it comes to integrating other libraries.

     348 org.eclipse.xtend.lib-2.5.3-596d64c46675a1cdf0e039712c21624a.jar
   14759 guava-16.0.1-112adff7f6280a657848262c3423e298.jar
    1434 org.eclipse.xtext.xbase.lib-2.5.3-0637011a1bbfa5f729a06a029b2f42b2.jar
Overall: 16541

Usually this is not a problem, but when you have to develop a large application you should be aware of this. Having to remove Guava from your application in hindsight is something I would not like to repeat...

Cheers,

Sebastian

[1] http://android-developers.blogspot.de/2011/07/custom-class-loading-in-dalvik.html

[Sven Efftinge]

I expected ProGuard to tree shake most of that off if it is not used.

Is that a false assumption?

[Sebastian Benz]

ProGuard helps, but this also means that you need to run proguard everytime you want to run your app on the target...

[Sven Efftinge]

Ok, so I assume running proguard is slow and therefore is typically only done when producing a release?

It would be awesome if you guys could help us setting priorities right.

We are not Android developers, just playing around with it to make sure it works.

So feedback from real world usage is needed.

We have discussed internally how we could avoid the dependency and make it optional

This bug is related https://bugs.eclipse.org/bugs/show_bug.cgi?id=414775

One idea was to inline from Guava just what’s needed. Which has some drawbacks and hassles.

Another was to use only parts of guava (i.e. collections) but the guava team has stopped to release these chunks.

Do you have any idea how to improve this situation, without compromising the experience for standard "Xtend on JVM"

users?

[Sebastian Benz]

A simple solution would be to provide a version of Guava containing only the classes needed by xtend. Maybe you could even use proguard to build the respective version of Guava.

[Bernd K.]

Am Dienstag, 8. April 2014 11:11:02 UTC+2 schrieb Sven Efftinge:

Ok, so I assume running proguard is slow and therefore is typically only done when producing a release?

Its probably not so much the slowness of ProGuard but the inability of current ADT Eclipse plugin to invoke ProGuard through the run/debug configurations with a simple mouse click. The only way of doing it with eclipse is to export the apk, then manually (with a separate tool outside of eclipse) move it to the device and install and run it. If ProGuard must be used for every build then Its actually faster to not use ADT at all and do the entire build with a separate tool from the command line. People have complained a lot about this in the past already but Google seems 100% focused on the new Android Studio and don't seem to care much about Eclipse anymore :-(