Hi! So far I've seen that Scala offers safe, composable, scalable approaches to > concurrency, whether it's by using Future or going all-out with Akka. I've > also seen that lots of people have trouble getting Akka working at all on > Android, and I wonder whether it's worth the risk. > Here’s a project allowing to use Akka to pass messages between Android Fragments: https://github.com/macroid/macroid-akka-fragments And here’s an Activator template demonstrating it: http://typesafe.com/activator/template/macroid-akka-pingpong
I have a few activities using this trick, and so far it seems extremely useful. The trade-off is that you can spend some time configuring ProGuard, but you can use my config (see those projects), which should work unless you use some extra things that I don’t use. You can mail me or open an issue if something fails. Android also has its own concurrency mechanisms: on top of what Java gives > you, it has AsyncTask and Handler, and it has the requirement to update > your GUI on the main thread. > > What I'm wondering is, if I start using Scala concurrency, how can I get > my background tasks to communicate with the main thread? It seems like > there might be some alternatives (as follows), but I'd like to know what > people are actually using for real development, rather than beating a path > through unknown jungles. > Macroid (http://macroid.github.io/) offers several utilities, which are much more flexible than Scaloid’s: 1. UiThreadExecutionContext for futures [1]. You probably wouldn’t need to use this directly. 2. UiFuture [2], which provides mapUi, flatMapUi and other xxxUi methods, where the supplied function will be called on the UI thread: import macroid.UiThreading._ import scala.concurrent.ExecutionContext.Implicits.global Future { ... // happens on background thread } mapUi { x ⇒ ... // happens on the UI thread } 3. UI actions (http://macroid.github.io/guide/UiActions.html): most Macroid operations actually return a so-called UI action: val action = myTextView <~ text("Foo") // nothing happens yet action.run // the action is sent to the UI thread By the way, action.run returns a Future, so you can actually know, when it’s executed. 4. There are some interesting dataflow ways of dealing with concurrency, for example you can define complex asynchronous UI workflows — see http://macroid.github.io/guide/Snails.html. > - Is there some way to communicate with a Handler on the main thread > as if it were an Akka Actor? > > Yes, use Scaloid’s runOnUiThread (just spawns a UI thread task), or — better — Macroid’s Ui(...).run, since you get a Future in return. If you use macroid-akka-fragments, it’s even simpler. > - Or is it possible to get callbacks from Future that are guaranteed > to run on the main thread? > > Yes, use Macroid’s mapUi and co. Or specify UiThreadExecutionContext explicitly. > > - Or perhaps the best way is just to use AsyncTask and Loader the same > way I did in Java. > > I never use it — that’s just blasphemy and suicide :) > My needs are pretty simple: I don't want anything complicated like > task-based parallelism, just an easy way to have ongoing background work > that pokes the GUI with new data now and then. So far, I haven't found a > way of getting things back to the main thread without stepping outside > Scala's concurrency ops. > Hope the above helped. If you really don’t want to depend on Macroid (why would you... it’s very small :)), see the references below — the relevant code could be copied into your project. P.S. My ScalaDays talk (on June, 18) covers most of these things: http://scaladays.org/#schedule/What-s-in-your-pocket--The-state-of-the-art-in-Android-programming-with-Scala Nick [1] https://github.com/macroid/macroid/blob/master/src/main/scala/macroid/util/Ui.scala#L9 [2] https://github.com/macroid/macroid/blob/master/src/main/scala/macroid/UiThreading.scala#L18 -- You received this message because you are subscribed to the Google Groups "scala-on-android" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
