[Mobile-sig] python on android

[Bill Janssen]

Russell Keith-Magee <russell at keith-magee.com> wrote:

> I'm glad that you find Kivy good enough for your purposes, but I don't.

Don't get me wrong!  I think your core idea for a set of patches is a
great one, and I'm sure the Kivy folks would appreciate it, too.  They
bit off an awful lot to chew there.

>  a) I don't like the Kivy widget set. It might be fine for games, but if
> I'm using a platform, I want native widgets, and if I'm using native
> widgets, I don't want to carry the overhead of a customised widget toolkit
> I'm not using.

Yes, I don't care about native widgets.  Of course, the UI widget set is
there for a different purpose, portability across platforms, and if you
don't care about that, you can always use the native widget set with Kivy,
instead.  But I'm happy enough with the Kivy widgets.

>  b) I don't like the Kivy build tools. They're a lot more complex than they
> need to be.

I didn't find it troublesome, but of course this wasn't my first rodeo.
I'd certainly agree it's not a push-button solution.  So, what would a
less complex system be like?

> I'm going to guess the Kivy people are all Linux users, because
> they don't appear to have worked out that binary compatibility is a thing.

Sorry -- why is that a Linux thing?

> You don't need to have every user compile Python and the rest of the Kivy
> stack - you can just ship a binary library, and it will work on every phone
> with the same hardware (I know, because Toga does this. The Toga
> bootstrapping process is "clone this repo, and copy this file". You could
> reduce this to "clone this repo" if you were happy putting binary artefacts
> into version control.)

Sure.

>  c) Kivy's build tools are Python 2.7.1 only on iOS, and 2.7.2 on Android;

I believe the mobile platform packaging tools are still stuck at 2.7.
Kivy 1.8+ will run on Python 3 on desktop, though.

> and if you build them on OSX, when you're on the device, they report
> sys.platform as "darwin".

Seems like a bug; I imagine you're suggesting that the Kivy build
process should patch that file to return "android"?  Although I never
know what to look at to get that platform info correctly -- this is a
larger Python issue.

And kivy.utils.platform seems to return the proper thing.

> Going back to my post

For those of you following along at home, here's Jeff's list (I had to
go and look it up).

>  1. A library build of Python
>  2. Templates to stub out a working Python project
>  3. Libraries to do bridge between native language environments and Python
>  (for me, that's Rubicon)
>  4. Libraries for utilising native system services (for me, that's Toga)

> - I agree with Kivy on layer 1, and I was able to use
> their build tools to bootstrap my own. However, I have very different
> opinions on layers 2-4.

Just to outline the Kivy approach to 2-4: Kivy doesn't really do 2 -- it
provides examples, and you're supposed to extrapolate from them.  I
guess that's a form of template.  For #3, there's Kivy's "pyjnius" (to
access Java via JNI) (https://github.com/kivy/pyobjus) and "pyobjus" (to
access Objective-C via runtime reflection)
(https://github.com/kivy/pyjnius).  For #4, as I said, there's "plyer"
(https://github.com/kivy/plyer).

> Kivy is *a* solution for Python on mobile; it isn't the *only*
> possible solution.

Of course.

> On top of that, Kivy still has a lot of work to do on point (c). If effort
> is going to be spent fixing libPython for mobile, I'd like to see it done
> in Python's core - this isn't something that should need to be duplicated
> by every project that has an interest in this space.

I wouldn't imagine they'd argue with that.

> I also like to see this in core as a formal recognition that mobile
> platforms matter in the landscape of modern computing.

Sure.

> And once a mobile libPython exists, Kivy can use it however they want; I
> can use it however I want; and SL4A can use it however they want.

Sure.

We can have a separate discussion sometime about Django vs. Tornado :-).

Bill