android.app.Application vs android.app.Service
I am writing an android application that uses location.LocationManager and LocationListener to receive GPS location updates. The application updates the location on a MapActivity and sends the co-ordiantes to a restful web service. The web service needs to receive location updates even when the MapActivity is not visible to the user.
At the moment i am doing everything (apart from UI) within app.Application as it stays active even when the MapActivity is not visible. However, all the documentation i have read suggests that app.Application is used to store state rather than carrying out more demaning tasks. I have tried using app.Service, but it seems to be over complicated (life-cycle, binding, unbinding) and has many memory leak problems. I haven't been able to find any articles or documentation that explicitly forbids carrying out these kind of tasks from app.Application, so i was wondering if there is anything wrong with this approach?
Edit: Thanks for the replies, looks like i am going to have to s开发者_C百科pend a bit more time figuring out app.Service
You should probably go with a service. I think that the lifecycle of the Application is bound to any of its components that are currently running. I would guess that the process monitor is at liberty to destroy your Application at will when resources are required elsewhere if it is not running any Applications or Services or whatever. You might find that your code works sometimes but you get unexpected crashes.
It is generally best to use the model that Android prescribes for the different components
Generally I think using Application is ok: I've made extensive use of it. The major complication I'd say is that the only lifecycle callback is onCreate
: with Service
you at least have the option of cleanly shutting it down with the onDestroy
callback.
The lifecycle can be a bit confusing on the Service
, I'll admit. If the Application object is working for you I wouldn't lose sleep over it.
精彩评论