Ahh.. i might have been too simplistic when i said they are an activity without a UI, i dont want to pass the wrong impression: you'll get what appears to be similar behavior, but it isnt... Services being Services behave differently when it comes to how they run and what they can do... in his case, a service makes more sense since it can be used to relaunch events that were not processed properly (e.g cell network is unavailable).
Google had a reason to create Services and even though they appear to be "Activities without UI" at a glimpse, you get to see they are not once you go deeper into how they work and what they do. And no one suggested to run a blocking operation.. i reiterated TreKing's suggestion - Service + background thread. On Sunday, March 3, 2013 5:54:52 PM UTC+2, 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] <javascript:>> > 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]<javascript:> > > To unsubscribe from this group, send email to > > [email protected] <javascript:> > > 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] <javascript:>. > > 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.
