Hi Mark, first of all thanks for your answer :D I come from a J2ME background in which I had the same problem, i.e I need to have a always-existent database interface and a always- existent xml-parser which (in J2ME) I placed in a singleton Thread, so that they could be paused when needed and they could get to work when, well, they needed to parse data and/or write/retrieve data :D My knowledge atm is pretty lacking regarding all those things of Android (like activities, tasks, Context or the mentioned asyncTask and intentService) but having a marketing peep as a boss I have a very strict deadline (next monday) to set up a first demo of the app... For me this means I cannot dig too deep into the subjects and most probably I could use the simplest possible implementation... The problem with Threads in the form of a SIngletong(as I undertsood from the selective reading I have done) is that those can be closed anytime by the underlying OS, which in my case would block the whole app :P Also the quesiton remains about inter-class (or in this case interprocess) communication ? How can this be done safely but most importantly as fast as possible in regards to studying theory for it ? Thanks again Mark...
On 9 feb, 13:53, "Mark Murphy" <mmur...@commonsware.com> wrote: > > Hi, > > I'd like to create some sort of Thread which can be accessed by my > > main program.. > > Specifically I'd like two classes, both with their own thread, one for > > parsing XML data and one for doing database operations, without > > actually interfering with the main UI-thread (slowdowns for > > example)... > > Use AsyncTask for each of these. > > > I was wondering if those should just extend Runnable, and maybe make > > them some sort of Singleton, or if these should be implemented as a > > Service ? > > Use AsyncTask, perhaps mediated by a Service. I'd probably use a Service, > only because I like a stable foundation where I can get it, and activities > tend to be twitchy (e.g., user presses BACK, and they get destroyed). But, > since you're asking this in a very abstract fashion, I have no idea if a > Service is necessarily right for your case. > > Another possibility, instead of AsyncTask, is to use an IntentService. > They both allow you to do work in the background without your own thread > management. I tend to use IntentService more for totally asynchronous > stuff (e.g., app widget updates, alarms with AlarmManager, etc.), where I > want the service to go away when there's no outstanding work to do. > > > Or maybe they shouldnt be implemented at all as an > > individual Thread ? > > Forking your own threads should only be taken after you have investigated > AsyncTask. AsyncTask doesn't handle every scenario where you might use > threads. However, since AsyncTask lets you do background work without your > own thread-management code, it is definitely worth looking into. > > At the risk of sounding self-serving, you might want to look into getting > a book that covers threads and services in Android. The questions that you > are asking are rather involved -- I've barely scratched the surface of the > subject in this reply. > > -- > Mark Murphy (a Commons Guy)http://commonsware.com > Android App Developer Books:http://commonsware.com/books.html -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
