[Python-ideas] python on mobile

[Russell Keith-Magee]

On Wed, Dec 31, 2014 at 12:58 AM, Chris Barker <chris.barker at noaa.gov>
wrote:
>
> On Mon, Dec 29, 2014 at 10:39 PM, Wes Turner <wes.turner at gmail.com> wrote:
>
>>
>>> As far as Kivy goes - I have tinkered with Kivy; I've even used Kivy's
>>> tools as a starting point for some of my own efforts. However, to me, Kivy
>>> is focussing too far up the stack - their toolchain appears to be based on
>>> getting *Kivy* working on mobile, not *Python*. This is an entirely
>>> reasonable approach if Kivy is what you want at the end of the day - but
>>> it's not what *I* want. I've been taking a much more atomic approach. The
>>> Kivy toolchain is also anchored in old versions of Python 2; something that
>>> definitely needs to be addressed.
>>>
>>
> IIUC, how Kivy works is not to  put a python interpreter on the platform,
> but rather to run all your code through Cython, creating a C program that
> used the python runtime as a library, essentially. So there is no python
> code involved at run time.
>

Incorrect. On both iOS and Android, Kivy uses Cython as the mechanism to
get a C-native platform binding (PyJNIus/PyObjCus) that allows your Python
code to invoke native libraries directly. The deployed app is a Python
interpreter that is packaged with all the Python code and libraries, and
it's executed as byte code at runtime.

Toga/Rubicon takes a similar approach, but using ctypes directly, instead
of using Cython.


> So the Kivy lib aside, is this a good way to go on Mobile? I can't image
> it's too hard to remove the kivy UI  stuff if you don't want to  use it --
> even if the current tools all include all that by default.
>

Sure, it could be done. And in a sense, that *is* what I'm doing - taking
all the Kivy-specific parts out of Kivy's tools. And what I've been left
with is things that, IMHO, should be in Python's own source tree. Along the
way, I've discovered all the ways that Kivy's tools are deficient (for
example, as a result of the way they've done their build, sys.platform
reports the compilation platform, not the runtime platform).

But is it better to target getting Python running on Mobile just like it
> does on the desktop: you have a python interpreter, a bunch of python
> modules, and you bundle it all up with a executable launcher of some sort,
> al la py2exe, py2app, etc.?
>

That approach might work. However, py2app etc are just optimisations - you
still need to have all the language bindings etc.

On top of that, on Android, the end product must essentially be a JAR file.
Jython doesn't currently work on the Dalvik VM, so there's a whole other
level of tooling required. This might be changing with Android 5/Lollipop -
I've only had a brief look at the VM changed in Android 5.


> Something to keep in mind is that that way most Python code is run may not
> make sense (or even be an option with Apple's rules, anyway): you have a
> python environment installed, and install a bunch of application code on
> top of that, and run that. Makes sense to system scripts, and web apps and
> that like, but really doesn't make sense for "Apps".
>
> What I'm getting at is that the final goal for what exactly we want people
> to be be able to distribute may effect decisions about what to build and
> how to build it.
>

However, at the core, an "app" is just iOS/Android are running a process.
Just as on desktop or web, that process can, if you so choose, start a
Python interpreter and run a script. It's just a set of instructions.

Yes, those instructions need to play nice with your local platform
conditions, but that's no different to the distinction between desktop apps
and web apps - I've spent plenty of time on the Django-users mailing list
teaching newcomers to the web that you can't just take a long lived process
and treat a web request as a button click starting that process - you need
to restructure your code to take into account the short lived, stateless
nature of HTTP requests.

As for the "Apple" factor - that's not an issue (at least, not at the
moment). Apple doesn't place restrictions on "interpreted" apps in the app
store, as long as the scripts are all bundled as part of the app (i.e., you
can't deliver updates/enhancements by sending an installed app a new script
to run). There are Kivy apps in the App Store right now. Of course, this is
subject to the whims and fancies of Apple, but this has been a stable
policy for a couple of years, and I suspect there would be a riot if this
policy were to change substantially, because it's central to the operation
of many games engines.

BTW, one thing I'd like to be able to build is what I call a "BILS"
> (Browser Interface, Local Server) app: you run a web server bundled up in
> an app that points itself to the browser component for all the UI. We've
> been very successful doing this on Windows and OS-X, as a way to provide a
> self contained desktop app, and a hosted Web App with almost entirely one
> code base, and an identical user interface.
>
> (http://cameochemicals.noaa.gov/ and
> http://response.restoration.noaa.gov/cameochemicals)
>
> (Python / Pyramid on the back end, desktop is the local browser hosted by
> a wxPython wrapper)
>
> We'd like to be able to port that to iOS and Android, but there doesn't
> appear to be a solid python option that we could run a Pyramid web server
> on Mobile at this point -- maybe I'm wrong)
>

I'm aware of the approach - I've even used it myself in the past (to get a
UI on an old iPaq handheld). However, once you've got a working Python
interpreter on mobile with good bindings to the underlying platform, it
shouldn't be too hard to write - getting a WebKit view that consumes the
entire screen is easy to write, no matter what platform you're on, so then
you just need to set up the server stuff, and for that all you need is a
Python interpreter with a working socket and threads module. I'm not sure
it would be great for battery life, but that's a separate problem.

I can't say that particular approach something I'm particularly interested
in myself, but my point is that this shouldn't matter - once you can do
Python on mobile, it's up to you to decide what works or doesn't. But the
first step is getting Python supported on mobile.

Yours,
Russ Magee %-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141231/0423c17b/attachment-0001.html>