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 <[email protected]> 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" <[email protected]> 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 > >>> [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
