You're right, and I've corrected my explanation about services in subsequent posts (with an eye to exactly this scheduling behavior!).
That was misworded, but even so I think people conflate activities vs. services as having different threading semantics (they don't, things both run on the main thread). *This* is really what the OP fails to get right in his app, regardless of it being run in a service, broadcast receiver, activity. The point is that you really shouldn't be running blocking operations on a main thread. Kris On Mon, Mar 4, 2013 at 9:56 PM, Indicator Veritatis <[email protected]> wrote: > A Service is a lot like an Activity w/o a UI, but the lifecycle is > different: you have to override a rather different set of callbacks, for > example. Especially for a bound service.The rules for keeping the hosting > process alive are different, too. Services do not go on the Activity Stack > either. > > > On Sunday, March 3, 2013 7:54:52 AM UTC-8, Kristopher Micinski wrote: >> >> Well, since a Service is just an Activity without a UI, you still get >> the same behavior... >> >> You shouldn't be running blocking operations in a service either (even >> if they're scheduled a bit more nicely), it just coordinates things. >> >> Kris >> >> On Sun, Mar 3, 2013 at 3:47 AM, Piren <[email protected]> wrote: >> > i think everyone just forgot to mention the obvious and what you seemed >> > to >> > get wrong: >> > At no point what so ever were your activity and the other acitvity >> > running >> > at the same time. >> > >> > Only one activity can be running (as in "Resumed" state) at a time. >> > Android >> > has one UI thread, if you're using it, someone else is waiting. >> > >> > In your instance what happens is that your activity is launching, >> > pausing >> > the other app and then giving control back once it is done. It doesn't >> > matter that it has no UI. I've used such activities myself and they have >> > the >> > nasty habit of making the phone appear unresponsive - even without a UI, >> > it >> > is still the "top" app, thus whatever app is behind it, while appearing >> > to >> > run, will not recieve any input commands and most likely have the UI >> > itself >> > hault. Since its only for a brief state, no one is the wiser. >> > >> > Either way, you should take TreKing's suggestion, you should not be >> > using a >> > activity for this, rather a Service (which btw, is an activity without a >> > UI) >> > with a background thread. >> > >> > >> > On Sunday, March 3, 2013 2:00:25 AM UTC+2, [email protected] wrote: >> >> >> >> TreKing. You gressed it. Broadcast receiver. It's an activity that >> >> runs >> >> for about 600 - 700 mills. >> >> On Saturday, March 2, 2013 11:05:23 AM UTC-7, TreKing wrote: >> >>> >> >>> >> >>> On Sat, Mar 2, 2013 at 10:36 AM, [email protected] >> >>> <[email protected]> wrote: >> >>>> >> >>>> Well, the app reliably works while other activities are running and >> >>>> when >> >>>> the phone is locked. >> >>> >> >>> >> >>> This may be the case in your testing, but this is not guaranteed. Your >> >>> app can and will be killed at any point while it's in the background >> >>> to make >> >>> room for other components as the system requires. You will find this >> >>> out >> >>> quite quickly once you release the app users who manage to get into >> >>> these >> >>> type of edge-cases. >> >>> >> >>> It sounds like you should be using a Service. >> >>> >> >>>> >> >>>> You send the phone a text and you get back the phones location. It >> >>>> doesn't have to be running. In fact it never has to run. It just >> >>>> has to be >> >>>> installed on the phone. >> >>> >> >>> >> >>> Obviously it does have to run at some point to do anything. Maybe it >> >>> runs >> >>> in response to a Broadcast instead of user interaction but it doesn't >> >>> just >> >>> magically work without actually running some code. >> >>> >> >>> >> >>> >> >>> ------------------------------------------------------------------------------------------------- >> >>> TreKing - Chicago transit tracking app for Android-powered devices >> > >> > -- >> > -- >> > 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 >> > --- >> > You received this message because you are subscribed to the Google >> > Groups >> > "Android Developers" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an >> > email to [email protected]. >> > For more options, visit https://groups.google.com/groups/opt_out. >> > >> > > > -- > -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Android Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
