[Mobile-sig] Pythonic idioms on mobile platforms

[David Boddie]

Really, I'm talking about async in that, if I implement an Adapter (in
Android terminology), I don't want it to be doing its work in the GUI
thread if that work is strenuous. (At this point I roll my eyes that we
are still dealing with frameworks in 2017 with a "GUI thread".)

My first workaround was to create a background thread but, as you may be
hinting, this is probably a false move for the use case I had.

It's interesting to see that you're integrating support for async using
Handlers. I haven't even considered language features like that, relying
on explicit use of Handler instances. I think this is probably the result
of being exposed to GUI frameworks on the desktop.

Since you're sharing links, here's a link to the workaround I was talking
about:

https://bitbucket.org/dboddie/spriteviewer-android/src/8faee99cd2ca74a9091e08d0220017e402d4831a/Sources/spritebrowser.py?at=default&fileviewer=file-view-default#spritebrowser.py-178

The problem here is that there seems to be no officially blessed way to do
what I want to do, even in Java, so it would be difficult to write a nice
wrapper for someone else to use. That doesn't stop me from writing library
code to abstract away the horrible details, but I still wonder whether I've
missed something. Hopefully, someone learns from my experience.

David

On Thursday 14. December 2017 08.30.41 Russell Keith-Magee wrote:
> To clarify - are you talking about threading specifically, or async, or just
> the general problem of implementing long-lived behavior in a GUI without
> blocking the GUI thread?
> 
> If you’re talking about async, I’ve been able to integrate the Cocoa/iOS
> event loops with Python’s asyncio event loop with remarkably little code:
> 
> https://github.com/pybee/rubicon-objc/blob/master/rubicon/objc/eventloop.py
> <https://github.com/pybee/rubicon-objc/blob/master/rubicon/objc/eventloop.p
> y>
> 
> I haven’t actually tried to do this on Android yet, but from research I’ve
> done, it should be possible to use Handlers to implement the same thing.
> You don’t (necessarily) need threads - you just need a non-blocking
> (usually select-based) I/O API.
> 
> The upshot of this is that you can make every even handler (e.g., button
> click handlers) asynchronous, which means they can be long lived without
> blocking the GUI thread. There are a couple of examples of this in the Toga
> examples repository
> 
> The Detailed List widget example uses an async handler to simulate a process
> retrieving data from a remote API
> https://github.com/pybee/toga/blob/master/examples/detailedlist/detailedlis
> t/app.py#L14
> <https://github.com/pybee/toga/blob/master/examples/detailedlist/detailedli
> st/app.py#L14>
> 
> Beeliza uses an async handler to emulate response times from a virtual chat
> participant
> https://github.com/pybee/toga/blob/master/examples/beeliza/beeliza/app.py#L
> 11
> <https://github.com/pybee/toga/blob/master/examples/beeliza/beeliza/app.py#
> L11>
> 
> Yours,
> Russ Magee %-)
> 
> > On 14 Dec 2017, at 8:15 am, David Boddie <david at boddie.org.uk> wrote:
> > 
> > [Answering Russell as well, as I see his response to my original message.]
> > 
> > I can try to be more specific about the problems I found, though I'm not
> > sure if I really know the best practices for threading in Android (or
> > Python for that matter).
> > 
> > I was trying to lazily populate items in a scrolling list using instances
> > of the AsyncTask class, which is a convenient way to do work in a
> > background thread:
> > 
> > https://developer.android.com/reference/android/os/AsyncTask.html
> > 
> > I initially thought I was being clever and had found a nice way to handle
> > processing using background threads. The problem is that, for many items,
> > you hit a limit where creating new AsyncTasks fails, so the abstraction
> > is quite brittle and you need to find a way to process a large number of
> > items.
> > 
> > I experimented with using a regular Thread and using queue and
> > communicating with the main GUI thread using a Handler. This worked fine,
> > but doesn't scale very well. I ended up returning to the AsyncTask
> > solution and working around the problem by using a trick familiar to
> > users of desktop GUI frameworks: posting an event for later evaluation.
> > 
> > One of my points is that getting things done in the GUI tends to involve
> > techniques that purists would frown on, yet this is something desktop GUI
> > developers are familiar with. Getting something to work can involve
> > details
> > that we would prefer not to expose to the user. Given that there is
> > usually
> > a preferred way to do things with the platform APIs, does that mean that
> > things like the threading module are effectively obsolete for developers
> > of
> > mobile GUIs?
> > 
> > Sorry not to be more specific. I'm still trying to wrap my head around
> > some
> > of these issues.
> > 
> > David
> > 
> > On Wednesday 13. December 2017 08.12.42 Guido van Rossum wrote:
> >> Can you be more specific?
> >> 
> >> On Dec 13, 2017 8:04 AM, "David Boddie" <david at boddie.org.uk> wrote:
> >>> I was looking at threading on Android and it occurred to me that perhaps
> >>> others sidestep problems I encountered with native APIs by using
> >>> Python's
> >>> own
> >>> threading features. Then I wondered if some developers prefer to stick
> >>> to
> >>> the
> >>> platform native APIs for things like threading, and if they found it
> >>> difficult to adapt to a non-Pythonic API.
> >>> 
> >>> Has anyone else looked at how well (or poorly) some of the idioms used
> >>> in
> >>> Python map to each of the underlying mobile platforms and frameworks, or
> >>> are
> >>> people just using the native APIs directly? The answer to this might
> >>> save
> >>> someone the effort of trying to reproduce the APIs of those standard
> >>> Python
> >>> libraries that aren't interesting to mobile developers.
> >>> 
> >>> 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