Hi Tim: Thanks for your interest. It's been a while since I looked at this code, so it's not very fresh in my memory. Also, I'm not fully certain I'm understanding your question, so I'll just tell you some stuff, and hopefully what you want to know is in there.
My assessment of the "way" to integrate Akka and Android is that each framework has an essential base class and its own message-passing mechanism. Those classes are *Actor* and *Activity* respectively. The message-passing is done in Akka, as you know, using *tell*, a.k.a. "*!*". The native mechanism for passing messages in Android is by passing a *Runnable* to *Handler.post()*<http://developer.android.com/reference/android/os/Handler.html#post(java.lang.Runnable)>. Integrating Akka + Android works nicely by figuring out where the Actor instances need to *post* messages to *Activity*s. I know I'm being very vague since, again, this is not fresh in my mind, but if I were preparing a lecture on integrating Akka and Android, that would be the first thing I would want to explain in detail. The next thing to understand is that one of my requirements for the Metronome app was to require no special permissions. As best I remember, the only way to make sure the app would stop making sounds if an incoming phone call occurs without requiring a permission to read the phone state was to cause it to stop whenever the *Activity* is hidden. Since the purpose of a *Service* is to continue running when an app's *Activity* is hidden, I did not want to use a *Service*, but that is a direct consequence of my desire to avoid requiring any special permissions. Obviously if you're making an app for internal corporate use, special permissions is not something you would be worried about, thus no such limit on *Service* use would exist. Finally, you mention the need for the app to respond to external events regardless of its state. Without knowing the essence of the debate you're having, my first reaction is that my attention would go toward configuring the *AndroidManifest.xml* file so that your app responds to events as needed, even if the device has just been rebooted and the driver has not yet started the app. That might involve starting a *Service*automatically. Depends on the specifics of how the events are making their way to the device. Knowing as little as I do about your specific requirements, I can say it sounds as if your implementation ought to be very straightforward, and the fault-tolerance that is possible with Akka can make your app very resilient to the connectivity interruptions your app can expect while operating on the road with the drivers. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/groups/opt_out.
