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" <[email protected]> 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
[email protected]
https://mail.python.org/mailman/listinfo/mobile-sig
_______________________________________________
Mobile-sig mailing list
[email protected]
https://mail.python.org/mailman/listinfo/mobile-sig
_______________________________________________
Mobile-sig mailing list
[email protected]
https://mail.python.org/mailman/listinfo/mobile-sig
_______________________________________________
Mobile-sig mailing list
[email protected]
https://mail.python.org/mailman/listinfo/mobile-sig
