Re: [akka-user] Akka + Android ReSTful client app pattern?

[Akka Team]

Hi Adam!

I am not too familiar with Android, so I cannot really help on that front, but I have some observations that might be helpful:

 - an ActorSystem is a heavyweight object, so it is probably not optimal to shut it down and start another one frequently

 - ActorSystem.shutdown is asynchronous, so you have to call awaitTermination to make sure that the shutdown itself has been finished.

-Endre

On Sun, May 5, 2013 at 4:35 AM, Adam Mackler <adamm...@gmail.com> wrote:

Hi:

Briefly my question is whether I can find any patterns for using Akka on Android to develop a ReSTful client for a web service?  And if not a pattern, I'll settle for whatever guidance is available.

Here is the full background: I'm brand new to Akka, and new to the whole actor paradigm.  As I said, I am trying to develop an Android app that is a ReSTful web service client.  It goes without saying that I'm dealing with network requests, asynchronous tasks, threads, processes, Android components, and database queries.  I've watched Dobjanschi's video repeatedly.  I looked at at this project from the Minnesota Android Users Group, and rewrote it in scala to see it work.  I started to use it as the basis of my app but it seemed like I was violating the principle of DRO (don't repeat others), so I looked around for a library that implements Dobjanschi's patterns.  I looked at DataDroid, and most recently "settled" on trying to use RoboSpice.  RoboSpice is pretty darn close to what I imagine ought to exist for such a seemly common task as creating a ReSTful client, but alas it falls short of its potential by being "impossibly" difficult to extend and customize.  I put impossible in quotes because it is possible, it just requires duplicating an excessive amount a code, leading me again to think there might be some tool in the same vein (i.e., to deal with threading and asynchronous requests) but more generalized by enough that I can comfortably make it do what I want.  Enter Akka.

So now, having read a bit about actors and Akka, and having compiled the very most minimal Android app that simply starts an actor system and creates an actor, I'm ready to get into a higher gear and see if Akka is what I've been looking for.  As I survey the landscape of this topic, I am overwhelmed by concern that I not reinventing the wheel.  I would love to be learning from other's mistakes right now rather than from the mistakes I am surely about to spend my time making without the knowledge I seek.

One of the first things I noticed is that if my Activity calls ActorSystem.shutdown() in its onStop() method, an ActorSystem of the same name cannot be restarted within the same process (at least not without doing things I don't know about).  I don't mean to dwell on that particular issue, except to explain my immediate realization that both Akka and Android are frameworks, and I would love to avoid doing very much experimentation in order to learn how properly to use them together.

What I would really love is some kind of pattern showing (even if only suggesting) how simultaneously to work within the constraints of Android with regard to the issue of Activities versus Services being shut down by the system and their different lifecycles, and the related issue of threads, and avoiding ANR on the user interface Thread, and at the same time time using Akka's actor system.  I can also see how ContentProvider's could be in this mix.

If no such Akka + Android patterns exist, perhaps someone could at least give some some feedback on my thoughts here:

What I propose is that because Akka uses an ActorSystem which keeps running, but Android Activities come and go, I should have each Activity bind to a Service, and have the Service start the ActorSystem.  The Service could have a method that returns an Actor that serves as an interface for the Activity to invoke asynchronous procedures: after binding, the Activity could call that method, get its Actor, and then send messages to it to communicate with the Service.  The Activity could also send a message to its Actor containing callback methods that the Actor could use to let the Activity know about changes that might affect the display.  That Actor's supervisor will be in the Service, and thus not be destroyed based on the life-cycle of any Activity.  The Activity's onStop() method would unbind from the Service.

Does that make sense?  Am I on the right path?  What's a better way?

Anyway, to repeat myself, I cannot believe that I'm the first person to have these questions.  I can, however, believe that someone else has even answered them already.  A straightforward, generally-usable, pattern that utilizes the Akka paradigm within the peculiar Android framework would be so ideal.  But I will appreciate any helpful information, even if it falls short of telling me everything I ought to know about this topic.

Thank you,

--

Adam Mackler

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Akka Team

Typesafe - The software stack for applications that scale

Blog: letitcrash.com
Twitter: @akkateam