I see - just to be clear - you'll only be operating a GUI in a separate process if you've either got 2 separate applications, or one application where an activity within it explicitly specifies it wants to run in a separate process.
I only say this because I didn't understand the term 'process' initially - I thought when an application spawned a service, by the fact that service could live on after the activity that spawned it was killed, it would be running in a different process! Good luck! On 21 May 2010 10:41, FrankG <frankgru...@googlemail.com> wrote: > Thanks a lot for this hint. > > But in my case I have an independent GUI in a seperate prozess. > > I must check whether I can avoid this and use this local binding > pattern. > > Thanks a lot ! > > Frank > > > > On 19 Mai, 09:46, redders <redders6...@googlemail.com> wrote: > > Looking into this further - I now understand the local binding pattern > > that Mark mentioned. There's a good example in the api section of the > > code examples that ship with the android SDK. > > > > Essentially as we are not using more than one process there's no need > > for IPC (*inter process* communication) interfaces defined in AIDL. > > Objects passed do not need to be marshalled across the barriers in the > > same way they would with a remote service running in a separate > > process. > > > > I strongly advise you to take a look at: > > [SDK DIRECTORY]/samples/ApiDemos/src/com/example/android/apis/app/ > > LocalServiceBinding.java (an activity to bind to a local service) > > and > > [SDK DIRECTORY]/samples/ApiDemos/src/com/example/android/apis/app/ > > LocalService.java (the service itself). > > > > On May 19, 8:06 am, FrankG <frankgru...@googlemail.com> wrote: > > > > > > > > > > > > > At first many thanks to Mark Murphy for his very detailed answer. > > > > > To the last post : I must say I use currently a mixture between > > > 1) and 2) .. > > > > > In my case the service uses Intents to inform othter apps. > > > > > And the services provides an interface via aidl. > > > > > But I also thinking about a pure 1) "Intent only" solution. > > > > > From Marks post I got the suggestion, to use a start intent , when > > > something > > > happens on service side and no activity callback "handle" ist set, to > > > send a start intent. > > > > > The service can keep a kind of status flag, to know, whether the > > > corresponding > > > activity is running. And the activity on the other side must send an > > > intent to the service, > > > when the activity will be finished ? > > > > > Is this a bad design ? > > > > > Thanks a lot ! > > > > > Frank > > > > > On 18 Mai, 22:48, redders <redders6...@googlemail.com> wrote: > > > > > > Hi, > > > > > > I have a similar question. My application has a long running service > > > > that acts as a TCP client. There is also an activity which needs to > be > > > > able to pass messages to the service which will then send them to the > > > > TCP server. In turn, the service needs to 'forward' the reply it gets > > > > from the TCP Server to the activity, which performs an action as a > > > > result. > > > > > > I understand there are [at least] two ways to deal with this: > > > > > > 1. Broadcast receivers and intents: The service and activity each > > > > register a broadcast receiver, and broadcast intents to communicate > > > > with each other, using putExtras for the data. > > > > > > 2. IPC using AIDL. I define two interfaces (activity to service, and > > > > service to activity), make my TCP message class implement parcelable. > > > > When my activity starts up, I bind to the service (if running, or > > > > create it if not), then receive the Service->Activity aidl Stub, then > > > > use a method defined within that to pass the Activity->Service Stub. > > > > Service and client now both have IPC Stubs and can call the each > > > > other's methods that have been defined in the interfaces. > > > > > > So my questions: > > > > i) is the above roughly correct? > > > > ii) are there any other sensible ways to do it? (e.g. I have heard > the > > > > term Local binder / local binding pattern in the last post - is that > > > > the same as [2]?) > > > > iii) which is most appropriate for my situation? > > > > > > Any help would be much appreciated - this is really confusing me. > > > > > > Cheers > > > > > > ~redders. > > > > > > On May 3, 1:02 pm, Mark Murphy <mmur...@commonsware.com> wrote: > > > > > > > FrankG wrote: > > > > > > I have short question to your example : > > > > > > > > If I understood it right, the Broadcast from the > WeatherPlusService > > > > > > will not start > > > > > > up the WeatherPlus Activity ? > > > > > > > Correct. In this case, the WeatherPlus activity is already running. > > > > > > > > So how must the example be changed, that the first broadcast will > > > > > > startup the activity > > > > > > and the next ones are normal broadcast to send the new status to > the > > > > > > activity. > > > > > > > > I know that I can use startActivity(Intent) to startup the > > > > > > activity ..and use then sendBroadcast(Intent), > > > > > > but you cannot know, whether then your Activity is still running. > > > > > > > Sure you can, though the sendBroadcast() model is probably not the > right > > > > > one to use. > > > > > > > Have the activity bind to the service using the local binding > pattern > > > > > and have it register a callback/listener object with the service > once bound. > > > > > > > When the "devise status changed", the service looks to see if it > has a > > > > > listener from an activity. > > > > > > > -- If yes, it calls a method on that listener to tell the activity > to > > > > > display the dialog or whatever. > > > > > > > -- If no, the service starts the activity with an extra indicating > "hey, > > > > > please go ahead and pop up that dialog, please" > > > > > > > Bear in mind that popping up an activity from a service is a very > bad > > > > > practice except in unusual circumstances (alarm clock, incoming > phone > > > > > call). If the user is in the middle of doing something else, and > you > > > > > interrupt them forcibly, and they do not think your interruption is > > > > > warranted, they will get...cranky. :-) > > > > > > > -- > > > > > Mark Murphy (a Commons Guy)http://commonsware.com| > http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > > > > > > _Android Programming Tutorials_ Version 2.0 Available! > > > > > > > -- > > > > > 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<android-developers%2bunsubscr...@googlegroups.com> > > > > > For more options, visit this group athttp:// > groups.google.com/group/android-developers?hl=en > > > > > > -- > > > > 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<android-developers%2bunsubscr...@googlegroups.com> > > > > For more options, visit this group athttp:// > groups.google.com/group/android-developers?hl=en-ZitiertenText ausblenden > - > > > > > > - Zitierten Text anzeigen - > > > > > -- > > > 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<android-developers%2bunsubscr...@googlegroups.com> > > > For more options, visit this group athttp:// > groups.google.com/group/android-developers?hl=en > > > > -- > > 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<android-developers%2bunsubscr...@googlegroups.com> > > For more options, visit this group athttp:// > groups.google.com/group/android-developers?hl=en- Zitierten Text > ausblenden - > > > > - Zitierten Text anzeigen - > > -- > 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<android-developers%2bunsubscr...@googlegroups.com> > 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 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
