[Mobile-sig] Experiments with Dalvik

[Martin Kolman]

Wed, 18 May 2016 00:23:10 +0200 Gabriel Pettier:
> One limitation we didn't work around yet with pyjnius, and that is 
> quite painful on android, is that JNI doesn't provide a way to extend 
> a class, and it's painful because a lot of the android API requires 
> you to do precisely that, in such case the way to do it is to do a 
> java class for the part that requires it, and then use this class from 
> pyjnius, but it's not very nice to have to jump to java often if you 
> use a lot of the android api that requires that. Another way I toyed 
> with (quite some time ago) was to automatically generate utility 
> classes, that allowed you to implement an interface instead of 
> extending a class (the generated java class would call code from your 
> implementation in its overriden methods), but failing to find a way to 
> generate a whole set of the possible classes you'd need to generate 
> the android api, i put that aside and never really came back to it. 
> Another possible solution was suggested recently, which was using 
> bytebuddy [1] to generate the classes you'd need, i didn't explore 
> this track, since i'm not currently focused on android stuff, but that 
> could be a nice way to work around the issue.
>
> [1] http://bytebuddy.net/
Another possibility (and what I'm doing) is to use use PyOtherSide 
(which can be used on Android[0]) and use the Android API over the 
interface provided by Qt/QML[1]. While not all of the Android API is 
covered, many of the Qt APIs (such as location ,sensors, etc.) are cross 
platform, so if you are also doing a cross platform application you 
don't need to special case for Android so much.
And if you *do want* to special case/make and Android only application 
Qt seems to have some sort of mechanism for interacting with the Android 
Java code[2]. Even though that interface is in C++, it can be easily 
exported to QML and then used from Python via PyOtherSide.

[0] http://pyotherside.readthedocs.io/en/latest/#building-for-android
[1] http://doc.qt.io/qt-5/android-support.html
[2] http://doc.qt.io/qt-5/qtandroidextras-module.html
>
> @david: thanks for sharing, that does look nice, and as was said, even 
> parts of it could maybe help us to do a better usage of android assets 
> formats, so thanks again for sharing :)
>
> On Tue, May 17, 2016 at 07:18:01PM +0200, Dima Tisnek wrote:
>> How about python-java bridge, like Rubicon or pyjnius?
>>
>> You get best of both worlds -- a good language and a mature runtime.
>> On 17 May 2016 18:05, "David Boddie" <david at boddie.org.uk> wrote:
>>
>> In a belated attempt to jump on the Android bandwagon I started to look
>> into learning Java and the Android APIs. I realised very quickly that I
>> couldn't face writing a lot of code in that language. Looking around for
>> other languages running on the Dalvik VM, I found a few that might be 
>> nicer
>> than Java, but I wasn't so sure that I wanted to write in any of those,
>> either.
>>
>> In the end, I decided to try an experiment to see how much I could learn
>> about Dalvik and Java by creating tools to handle some of the file 
>> formats
>> used in Android packaging, and by trying to implement a compiler for a
>> subset
>> of Python.
>>
>> The result can be found in this repository:
>>
>>  https://bitbucket.org/dboddie/duck
>>
>> It should be noted that the source language isn't really Python. The 
>> parser
>> from the standard library is used to parse it, but the semantics of the
>> generated code are different to those of Python. That's why I gave the
>> language a different name.
>>
>> How is this relevant to a mailing list about Python on mobile platforms?
>>
>> Firstly, the language may be close enough to Python for people to 
>> find it
>> more familiar than Java, even if there are places where the 
>> differences may
>> trip them up. Writing code to fit into a framework designed for a 
>> statically
>> typed language requires a slightly different mindset to the one you 
>> might
>> have when writing regular Python code, so it may not seem so strange to
>> developers once they've accepted that.
>>
>> Secondly, it makes it possible to write a more faithful 
>> implementation of
>> Python using code that looks a lot like Python, instead of Java. You 
>> could
>> use it to write support code for a compiler, or perhaps write an 
>> interpreter
>> in it.
>>
>> It's all very experimental at the moment. I've been uncomfortable about
>> publishing it before now because I keep finding things I've overlooked,
>> though it's been a good learning experience. Maybe there will be 
>> things in
>> there that people find useful.
>>
>> David
>> _______________________________________________
>> Mobile-sig mailing list
>> Mobile-sig at python.org
>> https://mail.python.org/mailman/listinfo/mobile-sig
>
>> _______________________________________________
>> Mobile-sig mailing list
>> Mobile-sig at python.org
>> https://mail.python.org/mailman/listinfo/mobile-sig
>
>
>
> _______________________________________________
> Mobile-sig mailing list
> Mobile-sig at python.org
> https://mail.python.org/mailman/listinfo/mobile-sig



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/mobile-sig/attachments/20160518/01dee1c4/attachment.html>