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 > > > > 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 > > > 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 > > 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 > 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 For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
