[Mobile-sig] python on android

[Russell Keith-Magee]

Hi all,

Introducing myself - I'm Russell Keith-Magee, the person behind
Python-Android-support [1], Python-iOS-support [2], rubicon [3] and toga
[4]. In terms of past history, I've been a member of the Django core team
for 9 years.

For the record, iOS is my platform of personal choice, and that's the
platform that has received the bulk of my attention to date. However, the
reason I'm looking at Python on mobile at all is for cross-platform
purposes, so Android is still of interest to me. For that matter, so is
Windows Mobile, Tizen, Sailfish and so on, but at least for the moment, the
big two are where most of the market is.

My personal end goal is to make Toga a viable platform for mobile
application development. In attempting to reach that goal, I've been very
careful to separate the goals of getting Python working on mobile, and
getting Toga working on mobile. To my mind, there are 4 layers to the story:

 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)

Of these, in my mind only layer 1 is something that should be targeted at
Python's core. I've gone to great lengths to keep the concerns separate. If
I had to criticise some of the other approaches mentioned, it would be that
they *haven't* necessarily kept that separation (although, in their
defence, that's possibly been done in the name of simplifying their own
projects).

To date, I've managed layer 1 with an external build process that applies
patches and packages up a usable framework/library. My packages leverage
heavily off what Kivy provided - but without all the layer 2-4 stuff.
However, I've been working on patches for Python's own build system, so
that the same product could be generated "out of the box". There are some
complications associated with this, but that's the subject for another
email (when I've got a little more to show for my work).

In various discussions to date, some people have stated a goal of wrapping
mobile facilities like Geolocation into a "standard" API in the stdlib. I'd
like to go on the record that I think this is a bad idea, and possibly even
an unachievable goal. The reason I think this is that you can't just "link"
native system tools (at least, not trivially). You need to a cross language
barrier - either Objc or Java, depending on your platform. I don't see ObjC
or Java integration layers as being part of the mandate of Python core, but
without a language integration layer, you can't use system native services
[5].

To be clear, I think a common cross-platform API for these services is
definitely worthwhile - I just don't think it's something that Python's
*core* needs to be concerned with. For me, it's "layer 4" in my description
above. I'm also of the opinion that while batteries included is a good
philosophy, committing to a set of batteries too early is a bad idea -
witness what has happened in Python's stdlib with HTTP handling or argument
parsing. I'd rather see third party libraries, easily installed using pip
et al, as the community's first response to this problem.

Another proposal is to have an official install of Python for mobile
platforms. While this is slightly more achievable, I doubt whether it's
worthwhile, compared to the effort involved.

The simplest interpretation of an "installable Python" would be a "Python
shell on mobile". While this is an interesting novelty, I don't see it as
being particularly useful in the long run; and, in order to have this
novelty, you'd need to essentially write native terminal emulators for iOS
and Android. Python on Windows doesn't ship with a *windows native*
terminal emulator - it uses a DOS console, or Tk to launch IDLE. iOS
doesn't have a native terminal capability, Android's isn't surfaced by
default, and getting Tk to launch on either platform would be.... an
interesting exercise :-)

An alternate approach would be to have a "Python-running activity" which an
APK might provide - SL4A does something like this, giving other apps the
ability to execute Python scripts. While I'm sure this can be made to work,
my experience as an end user was pretty poor. Perhaps this is my iOS bias
showing, but when I use an app, I want to go to an app store, pick it, and
install it. Android's ability to install an app from a URL is also
appealing, albeit unavailable to iOS. What isn't appealing is trying to
make sure that you've got a series of pre-requisite apps installed, and
that they're correctly configured, and so on.

On top of all that, no analogous service or capability exists on iOS, so
even if you did this for Android, there wouldn't be cross-platform parity
in what a "Mobile python" is able to do.

So - after all that: what do I see as the way forward?

To my mind, it's pretty minimal:
 - a set of patches to the existing build system to provide better support
for cross-platform, targeted builds for libPython
 - a set of patches to sys.platform to provide an "android" and "iOS"
platform definition
 - a set of patches to os to provide an "android" and "iOS" operating
system definition

And that's it. In order to get these patches into core, there are a bunch
of questions to be answered about build systems and release testing, but
the first step is to get the patches ready.

Beyond that, there's still plenty of work to do to get a *useful* Python on
a mobile platform - but what constitutes "useful" will vary wildly between
users. I want to write standard, AppStore apps that use system native
widgets. Kivy's approach is to write apps with a custom, but common widget
appearance. Others might actually be interested in the SL4A "Python-running
service" approach. SL4A differs from Kivy and Toga at layer 2; Kivy and
Toga differ at layer 3. However, all these end-user approaches have the
same layer 1 - a libPython that can be used on a mobile device. However,
the different approaches to layers 2-4 can all co-exist, and do so
*outside* Python's core.

Regardless of what comes of this SIG, I'm going to keep beavering away; but
if anyone in the community is similarly aligned, and we can work together
(especially on the Android bits, which fall into the "secondary interest"
pile for me personally), I'd love to be able to work together.

Yours,
Russ Magee %-)

[1] https://github.com/pybee/Python-Android-support
[2] https://github.com/pybee/Python-iOS-support
[3] http://pybee.org/rubicon/
[4] http://pybee.org/toga

[5] At least, I haven't been able to find a way. On iOS, you definitely
need to cross the ObjC barrier - there isn't a "raw C" API for any basic
system services that a native module could link against. On Android, I
haven't found any way to link to native capabilities - the APIs are all in
Java, and expect to be called through Java. However, as I said in my intro,
Android isn't my platform of strength, so I'll defer to expertise on this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/mobile-sig/attachments/20150128/a43f282b/attachment.html>