User "Events"? What the hell are those? Last time I checked, talking on the phone involved just that: TALKING. Do you mean you are processing voice input from the phone call and generating actions based on that? If so, that seems sketchy as Mark rightfully suggested.
Its not clear why this Service would need to be running all the time. Start the service when a call is initiated, end it on termination or when done processing. I see no reason to keep it open when all your data is apparently coming from phone calls. Jonathan On Mar 16, 1:04 am, Rohit Ghatol <[email protected]> wrote: > Hi Mark, > Thanks for the quick response. > > Unfortunately, the nature of our App demands we need a ever running > service (its like you need service so that communication like chat or > VOIP can happen). > > Yes we would have used BroadCast Receiver if it where Phone Events > like Battery, Network change, actually what we are talking about is > User Events. We need to see what User is generally doing on the phone > and hence we need a long running service to see this and do more stuff > on behave of the user. > > Cheers, > Rohit > > On Mar 16, 2:49 am, Mark Murphy <[email protected]> wrote: > > > > > > > > > On Tue, Mar 15, 2011 at 5:28 PM, Rohit Ghatol <[email protected]> > > wrote: > > > We are developing an Android Product, where we have Queues which are > > > created by Services and accessed by Activities. In general, I know > > > that objects (irrespective of where they are created ) in Android will > > > live in the same JVM and are accessing by any other object on the same > > > JVM. > > > > The idea in our product is that the Service is always running > > > Everlasting services are to be avoided unless absolutely necessary > > (e.g., VOIP client). > > > > and > > > listening for certain phone events and pushing these in the queue for > > > processing. > > > If you are referring to phone state events, you do not need an > > everlasting service for this. Use a BroadcastReceiver please, and make > > your queue durable (e.g., file, database). > > > > The UI (Activity if its running) will show the status of > > > the Queue and it currently accesses the queue directly. > > > > Now the questions which I have are following > > > 1. Is it a good idea to access objects created by Service directly > > > from Activity? > > > OR > > > Should I always access these from AIDL Interface? > > > There should be no AIDL interface, if these are all in the same JVM. > > AIDL adds no value and reduces flexibility. > > > > 2. Say my Service starts a thread to consume the queue which we have, > > > Should this thread be daemon thread? > > > What is a "daemon thread"? > > > > I dont want this thread to last > > > more than life cycle of the Service. > > > Then shut down the thread when you're done with it. > > > > 3. What is the best way to keep a Service running forever (this is the > > > nature of the app)? > > > The best answer is: don't do it, because users don't like it, and they > > will terminate your service when they feel like it. > > > The next best answer is: you can't do it, because Android doesn't like > > it, and it will terminate your service when it feels like it. > > > You have no choice but to design your app such that the service will > > not run forever. > > > -- > > Mark Murphy (a Commons > > Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > > Warescription: Three Android Books, Plus Updates, One Low Price! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
