It depends. Usually your activity (either WaitActivity or some other activity of your app) starts or binds to your service. The activity is the initiator. Your service can stay around for a while.
When your activity binds to your service, the activity can call your service and your service can call-back into your activity (calls and callbacks can be defined in IADL - Android Interface Description Language - files). - Some activity of your app starts your service when the user asks it to do some long-running action. - Then that activity binds to your service to setup a communcation channel with your service for calling into the service and receiving callbacks from the service. - Then your activity goes into wait mode, waiting for the service to complete (you can show a progress-bar, a progress-dialog and such). - The user can leave the activity (activity will unbind from the service). - The user can start the activity again (activity will bind to the service again). - The activity can receive callbacks from your service to get info from the user. - If the service discovers there is no activity to callback to (the user left the activity), the service can show a notification. This notification can be used to start the actvity again. This is one way of doing it. It won't bother the user unless he or she is focused on your app. Otherwise, a notification will be put into the status-bar. On Nov 11, 2:11 pm, Weston Weems <[email protected]> wrote: > I assume when you say "tie/bind" here you aren't just referring to spawn > activity via intent > On Nov 11, 2010 11:03 AM, "Streets Of Boston" <[email protected]> > wrote: > > > > > Tie/bind your service to a visible activity (let's call it > > WaitActivity). > > > If it is really important that user reacts immediately while your > > service chugs along and needs more info, the user'd better be looking > > at the phone and looking at the WaitActivity. > > > E.g. you could show an activity (WaitActivity) that says 'busy with > > doing the stuff you asked for.... please wait.' :-). > > > Then when the service needs credentials or other important > > information, it can communicate back to the WaitActivity to which it > > is bound that it needs some info. Your WaitActivity gets the info from > > the user and sends it back to the service. > > > If your user is no longer looking at your WaitActivity, then he or she > > is no longer urgently interested in the result or actions of the > > service. If the user restarts the WaitActivity at some point in time, > > rebind it with your running service so that the user can get updates/ > > info-requests from your service again. > > > But as long as your user is not looking at your WaitActivity, you > > should not interrupt your user. Instead, show a notification that > > opens WaitActivity which then get the necessary info from your > > service. > > > On Nov 11, 9:32 am, Weston Weems <[email protected]> wrote: > >> I know this question has been asked and been shunned for quite some > >> time. Like everyone else, I believe my idea to be the next big thing > >> and likewise I cant explain exactly what I am trying to do, except > >> that I think its acceptable use in my case. > > >> The idea is that the service will be chugging along... should > >> something occur with credentials or a number of other things, the idea > >> is that its important and needs users attention more or less right > >> away. After reviewing all the other existing chat discussions on the > >> topic, I can say that I understand why people generally dislike the > >> idea, and why just poppin a notification is the suggestion. > > >> Obviously displaying a straight dialog doesn't work, and I guess its > >> understandable so lets move on to popping a activity. I've had it > >> spawning my activity with extras on the intent and that works quite > >> well, but I'd like to be able to hit a button there and have it dump > >> completely back to what user was doing prior to my calling of the user > >> info dialog. > > >> What I'm actually noticing is that because the activities can be in > >> use and different states, and the whole FLAG_ACTIVITY_NEW_TASK still > >> appears to try and reuse activities from my app if they are suitable. > > >> eg, if i open front end and navigate around, then hit home, then some > >> event occurs, it will navigate to the correct activity in my app... > >> but when I attempt to dismiss with finish(), it returns the my apps > >> main activity. If I force kill it just prior to event occuring, it > >> works 100% like expected. > > >> Do I need to specify other flags to spawn an activity with literally > >> no history (like a static method call) or should I be ok there? > > >> Is there anyway I can just build a dialog, ask for a couple bits of > >> user info, continue upon its business if user hits ok (or cancel for > >> that matter)? > > >> I really believe that android sdk is probably right that there are > >> very very very few cases in which this should be done in the first > >> place... but notifications in this case wont do. > > >> Please help! > > >> Weston > > > -- > > 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]<android-developers%2bunsubs[email protected]> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en- Hide quoted text - > > - Show quoted text - -- 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
