Not really -- most mobile code is simply glue for UI event handlers and the like. And Python's really good at writing glue code.

Just like when you're coding in Java, code that needs performance is native, and written in C.

Python would idle just as well as pure java if it needed to :)

Yup. If we had Jython, this talk wouldn't have needed to have been written.

And I'd probably be working to improve Jython as we speak.

I wonder if this new ART system shipped with 4.4 changes anything - Google like Python and Go so maybe they'd have them available as languages that target the runtime?

PS. See you at LCAU2014!

ART is an install-time compiler from Dalvik bytecode to native code. It improves CPU, RAM, and battery usage, but still requires whatever code is run through it to be converted to Dalvik bytecode.

If we don't currently have a way to run Python on a Dalvik JIT, then we don't currently have a away to run Python on ART.

Why did they go to an install-time optimizer instead of inventing something better than Dalvik?

Well, continuing to run legacy apps efficiently is almost certainly a requirement. Presumably it's also a requirement for them that the Java semantics easily and efficiently map to their program representation.

An AoT compiler instantly makes everyone's favorite Android apps start faster, and many of them run faster, without having to wait for (sometimes defunct) publishers to re-compile the apps.

A static single assignment representation that matches the Java semantics, such as Michael Franz's SafeTSA, would be better than Dalvik bytecode if they're going to do install-time generation of native code.

In any case, I hope they continue to promote architecture-independent distribution formats for apps and libraries. I've said for a while that I think compiling directly to native code is going to eventually be treated like we now treat hand-written assembly... a last resort for small pieces of code that need speed and have been found to not be efficiently served by more abstract tools.

My guess is that it's still Java-like under the hood -- at the very least, calling out to API endpoints will be...

Probably doesn't change much at all. (Though I'd love to be wrong).

You're running the Python interpreter as a native executable, so it's roughly comparable to Dalvik.

If you want performance, write it in C, optimise it. That's what the NDK is for.

The talk was at mostly web developers. The second and third parts of the talk were about why the web doesn't cut it as a platform.

Part 1 was there to lay the groundwork. Basic? Maybe, but it's necessary.

That's pretty much exactly what python-on-android does; the problem is that you don't get access to any of the Java/Dalvik-based libraries, which includes all of the UI programming libraries.

Couldn't a language-bridge library use Java reflection to accomplish a lot of what's needed?

That is already done with pyjnius. The missing part is providing more pythonic and more productive ways of using it. Currently it is extremely awkward...

My guess is that someone will write a pythonic UI framework based on the Android API...

Do you mean you want something like Mono's Xamarin in Python?

It's a possibility – Qt's there, and in fact Kivy is a pretty good solution.

The problem I raise in the talk is that such libraries will always lag behind the state of the art for Android GUIs, which makes them less attractive.

Ah I see. This is the old issue. Why wrapper layers have to be later than its source…

The Kivy lead developer has just recently been working with native Android widgets in python-for-android. Stop by #kivy on Freenode and ask tito about his Google maps demo.

Ohai!

I wrote the talk, and just want to let you know that you can watch it over at https://www.youtube.com/watch?v=p77BR6e1uoo

--Chris

Thanks for transcribing the talk onto the slides. Most people don't, and just post their mostly-useless slides.

Yes. Actually, when I saw it was just slides I simply closed the tab because they're most often useless, not adapted to presenting something on the web.

After seeing your comment I went back to it, and indeed, the talk is there, which was unexpected and great.

Glad you enjoyed it – I find I present better if I have notes. Glad they have extra utility for you!

Great talk, thanks for posting it!

I really like how thoroughly you cover the problems with and potential work-arounds for using a non-Java language with Android. Your analysis applies to many other languages besides Python. I wonder if it would be worth making a language-neutral version of the talk.

Thanks for taking the time out and putting in all the notes. Very helpful and I'm sure, time taking for you. Much appreciated!

Great presentation, thanks for sharing it.

Why isn't Kivy or one of the other existing solutions good enough for your needs?

Mainly, can't use native controls and is focused to their own toolkit.

(I talk about iOS, that I care most. I wish badly that I could use python instead of obj-c)