My Activity starts a remote service, and can bind to it to call some
interface functions. Is there any way for the Service to pass a
message to the Activity?
All the sample apps seem to be one way communication - Activity to
Service.
> My Activity starts a remote service, and can bind to it to call some
> interface functions. Is there any way for the Service to pass a
> message to the Activity?
> All the sample apps seem to be one way communication - Activity to
> Service.
I actually just finished reading up on broadcastIntent(), seems like
what I want to do. Now I created a new class extending IntentReceiver
and added it to the manifest file as an IntentReceiver. No problems
calling broadcastIntent() to my service, calling the new class by
name.
Now what I don't understand is - does my Activity class have to create
an instance of the IntentReceiver class at startup time in order for
this to work? Here is my Activity class:
class MyActivity extends Activity
{
MyIntentReceiver m_Test = new MyIntentReceiver();
}
Yeah so do you need to create an instance of it to work? Because right
now I am NOT doing that, and my app seems to crash when the service
does the broadcastIntent() call.
Thanks,
Mark
On Jan 5, 5:21 pm, Cow Yow <nm...@hotmail.com> wrote:
> On Jan 5, 1:06 pm, Mark Wyszomierski <mar...@gmail.com> wrote:
> > Hi,
> > My Activity starts a remote service, and can bind to it to call some
> > interface functions. Is there any way for the Service to pass a
> > message to the Activity?
> > All the sample apps seem to be one way communication - Activity to
> > Service.
> My Activity starts a remote service, and can bind to it to call some > interface functions. Is there any way for the Service to pass a > message to the Activity?
> All the sample apps seem to be one way communication - Activity to > Service.
> Thanks, > Mark
Intents are uni-directional and broadcast based while IBinder/RMI is synchronous subroutine calls. I'm extending the messaging to allow bi-directonal asynchronous messaging and will work within the same process or across processes. Eventually, I want it to also work between Android devices and between an Android device and non-android device. Would this help resolve your problem?
>> I'm extending the messaging to allow bi-directonal asynchronous messaging and will work within the same process or across processes.
Yes that is precisely what I need - is there any facility to do that
at the moment with the current API? My solution is rather messy as it
involves:
1) The Activity binding to the remote Service, then calling its
exposed interface functions
2) The Service broadcasts an intent back to the Activity to pass
some data back
This solution is pretty weak, there should be one way to pass bi-
directional messages? I'm used to win32 programming via pipes, shared
memory, etc. How can we do it with Android?
Thanks!
On Jan 5, 6:53 pm, Wink Saville <w...@saville.com> wrote:
> > My Activity starts a remote service, and can bind to it to call some
> > interface functions. Is there any way for the Service to pass a
> > message to the Activity?
> > All the sample apps seem to be one way communication - Activity to
> > Service.
> > Thanks,
> > Mark
> Intents are uni-directional and broadcast based while IBinder/RMI is
> synchronous
> subroutine calls. I'm extending the messaging to allow bi-directonal
> asynchronous
> messaging and will work within the same process or across processes.
> Eventually,
> I want it to also work between Android devices and between an Android device
> and non-android device. Would this help resolve your problem?
> I actually just finished reading up on broadcastIntent(), seems like
> what I want to do. Now I created a new class extending IntentReceiver
> and added it to the manifest file as an IntentReceiver. No problems
> calling broadcastIntent() to my service, calling the new class by
> name.
> Now what I don't understand is - does my Activity class have to create
> an instance of the IntentReceiver class at startup time in order for
> this to work? Here is my Activity class:
> class MyActivity extends Activity
> {
> MyIntentReceiver m_Test = new MyIntentReceiver();
> }
> Yeah so do you need to create an instance of it to work? Because right
> now I am NOT doing that, and my app seems to crash when the service
> does the broadcastIntent() call.
> Thanks,
> Mark
> On Jan 5, 5:21 pm, Cow Yow <nm...@hotmail.com> wrote:
> > try broadcast Intent
> > On Jan 5, 1:06 pm, Mark Wyszomierski <mar...@gmail.com> wrote:
> > > Hi,
> > > My Activity starts a remote service, and can bind to it to call some
> > > interface functions. Is there any way for the Service to pass a
> > > message to the Activity?
> > > All the sample apps seem to be one way communication - Activity to
> > > Service.
> I actually just finished reading up on broadcastIntent(), seems like
> what I want to do. Now I created a new class extending IntentReceiver
> and added it to the manifest file as an IntentReceiver. No problems
> calling broadcastIntent() to my service, calling the new class by
> name.
> Now what I don't understand is - does my Activity class have to create
> an instance of the IntentReceiver class at startup time in order for
> this to work? Here is my Activity class:
> class MyActivity extends Activity
> {
> MyIntentReceiver m_Test = new MyIntentReceiver();
> }
> Yeah so do you need to create an instance of it to work? Because right
> now I am NOT doing that, and my app seems to crash when the service
> does the broadcastIntent() call.
> Thanks,
> Mark
> On Jan 5, 5:21 pm, Cow Yow <nm...@hotmail.com> wrote:
> > try broadcast Intent
> > On Jan 5, 1:06 pm, Mark Wyszomierski <mar...@gmail.com> wrote:
> > > Hi,
> > > My Activity starts a remote service, and can bind to it to call some
> > > interface functions. Is there any way for the Service to pass a
> > > message to the Activity?
> > > All the sample apps seem to be one way communication - Activity to
> > > Service.
u need to define the abstract function of your MyIntentReceiver class
to work, like
public class MyIntentReceiver extends IntentReceiver{
public void onReceiveIntent(Context context,Intent intent){
if (intent==null) return;
String action=intent.getAction();
if (action.equals(...))
...
}
}
good lucks.
--cy
On Jan 5, 2:37 pm, Mark Wyszomierski <mar...@gmail.com> wrote:
> I actually just finished reading up on broadcastIntent(), seems like
> what I want to do. Now I created a new class extending IntentReceiver
> and added it to the manifest file as an IntentReceiver. No problems
> calling broadcastIntent() to my service, calling the new class by
> name.
> Now what I don't understand is - does my Activity class have to create
> an instance of the IntentReceiver class at startup time in order for
> this to work? Here is my Activity class:
> class MyActivity extends Activity
> {
> MyIntentReceiver m_Test = new MyIntentReceiver();
> }
> Yeah so do you need to create an instance of it to work? Because right
> now I am NOT doing that, and my app seems to crash when the service
> does the broadcastIntent() call.
> Thanks,
> Mark
> On Jan 5, 5:21 pm, Cow Yow <nm...@hotmail.com> wrote:
> > try broadcast Intent
> > On Jan 5, 1:06 pm, Mark Wyszomierski <mar...@gmail.com> wrote:
> > > Hi,
> > > My Activity starts a remote service, and can bind to it to call some
> > > interface functions. Is there any way for the Service to pass a
> > > message to the Activity?
> > > All the sample apps seem to be one way communication - Activity to
> > > Service.
It seems that the IntentReceiver class exists in a vacuum though - how
can you communicate back with your main Activity class that an intent
was received? It seems like there's no way to communicate between the
IntentReceiver class and your UI classes. Example:
public class MyIntentReceiver extends IntentReceiver{
public void onReceiveIntent(Context context,Intent intent){
// Ok we received an intent - now how do we let the
Activity class know about it!
}
}
Thanks,
Mark
On Jan 6, 7:46 am, Cow Yow <nm...@hotmail.com> wrote:
> u need to define the abstract function of your MyIntentReceiver class
> to work, like
> public class MyIntentReceiver extends IntentReceiver{
> public void onReceiveIntent(Context context,Intent intent){
> if (intent==null) return;
> String action=intent.getAction();
> if (action.equals(...))
> ...
> }
> }
> good lucks.
> --cy
> On Jan 5, 2:37 pm, Mark Wyszomierski <mar...@gmail.com> wrote:
> > Hi CowYow,
> > I actually just finished reading up on broadcastIntent(), seems like
> > what I want to do. Now I created a new class extending IntentReceiver
> > and added it to the manifest file as an IntentReceiver. No problems
> > calling broadcastIntent() to my service, calling the new class by
> > name.
> > Now what I don't understand is - does my Activity class have to create
> > an instance of the IntentReceiver class at startup time in order for
> > this to work? Here is my Activity class:
> > class MyActivity extends Activity
> > {
> > MyIntentReceiver m_Test = new MyIntentReceiver();
> > }
> > Yeah so do you need to create an instance of it to work? Because right
> > now I am NOT doing that, and my app seems to crash when the service
> > does the broadcastIntent() call.
> > Thanks,
> > Mark
> > On Jan 5, 5:21 pm, Cow Yow <nm...@hotmail.com> wrote:
> > > try broadcast Intent
> > > On Jan 5, 1:06 pm, Mark Wyszomierski <mar...@gmail.com> wrote:
> > > > Hi,
> > > > My Activity starts a remote service, and can bind to it to call some
> > > > interface functions. Is there any way for the Service to pass a
> > > > message to the Activity?
> > > > All the sample apps seem to be one way communication - Activity to
> > > > Service.
Mark Wyszomierski wrote: >>> I'm extending the messaging to allow bi-directonal asynchronous messaging and will work within the same process or across processes.
> Yes that is precisely what I need - is there any facility to do that > at the moment with the current API? My solution is rather messy as it > involves:
> 1) The Activity binding to the remote Service, then calling its > exposed interface functions > 2) The Service broadcasts an intent back to the Activity to pass > some data back
> This solution is pretty weak, there should be one way to pass bi- > directional messages? I'm used to win32 programming via pipes, shared > memory, etc. How can we do it with Android?
> Thanks!
I agree, that's why I'm working on an API that extends the current Android messaging. I'm not aware of any shared memory in Android, I think it goes against the intent (pun intended) of using Linux processes to protect components from each other, but it could be there.
What I've done is to use the android.os.Message and android.os.Handler as the transports for a more complete Msg which I pass in the android.os.Message.obj field (I would have like to just extend android.os.Message but its final, bummer). I use that for intra-process messaging. I then tunnel Msg's between processes via java.net.Socket and deliver these inter-process messages via the intra-process messaging. The upshot is that a Msg can be sent via the inter-process or intra-process scheme seamlessly.
Right now I've got the intra-process messaging working and the inter-process partially working and hope to have both functional in the next few days.
After I've created this proof of concept, and if there is interest, I'll Open Source it and we can create something that is useful for many people.
If you or anyone else is interested let me know, (wink at saville period com)
Wink, amazing. After researching this today I have come to the same
conclusion. If you were to open source this I would at least be
interested, and if others haven't picked this up yet, I'm guessing
it's because the API is so young most people haven't tried any real
IPC yet. Once you get into this though, it's very frustrating
realizing there's no (built in) way to do it.
Is there anything I can do to help? Do you really think you'd be able
to finish within the next few days? If not, I was going to look at
writing a simple socket class which could possibly be used for
bidirectional communication between processes. I am pretty new to
android so am not sure if it's possible but java supports it so...
Thanks for your response,
Mark
On Jan 6, 2:02 pm, Wink Saville <w...@saville.com> wrote:
> Mark Wyszomierski wrote:
> >>> I'm extending the messaging to allow bi-directonal asynchronous messaging and will work within the same process or across processes.
> > Yes that is precisely what I need - is there any facility to do that
> > at the moment with the current API? My solution is rather messy as it
> > involves:
> > 1) The Activity binding to the remote Service, then calling its
> > exposed interface functions
> > 2) The Service broadcasts an intent back to the Activity to pass
> > some data back
> > This solution is pretty weak, there should be one way to pass bi-
> > directional messages? I'm used to win32 programming via pipes, shared
> > memory, etc. How can we do it with Android?
> > Thanks!
> I agree, that's why I'm working on an API that extends
> the current Android messaging. I'm not aware of any shared
> memory in Android, I think it goes against the intent (pun intended)
> of using Linux processes to protect components from each other,
> but it could be there.
> What I've done is to use the android.os.Message and android.os.Handler
> as the transports for a more complete Msg which I pass in
> the android.os.Message.obj field (I would have like to just extend
> android.os.Message but its final, bummer). I use that for intra-process
> messaging. I then tunnel Msg's between processes via java.net.Socket
> and deliver these inter-process messages via the intra-process messaging.
> The upshot is that a Msg can be sent via the inter-process or intra-process
> scheme seamlessly.
> Right now I've got the intra-process messaging working and the
> inter-process partially working and hope to have both functional
> in the next few days.
> After I've created this proof of concept, and if there is interest, I'll
> Open Source it and we can create something that is useful for
> many people.
> If you or anyone else is interested let me know, (wink at saville period
> com)
I suppose one of the most optimal solution will be to have a singleton
class which can have a number of listeners registered as part of its
instance.
As soon as Service calls the post message on this class, it executes
onReceive methods on the listeners in a cycle.
This will be the fastest way to send something, however, it's limited
to intra-process only.
Regards,
Alex
On Jan 6, 10:02 pm, Wink Saville <w...@saville.com> wrote:
> Mark Wyszomierski wrote:
> >>> I'm extending the messaging to allow bi-directonal asynchronous messaging and will work within the same process or across processes.
> > Yes that is precisely what I need - is there any facility to do that
> > at the moment with the current API? My solution is rather messy as it
> > involves:
> > 1) The Activity binding to the remote Service, then calling its
> > exposed interface functions
> > 2) The Service broadcasts an intent back to the Activity to pass
> > some data back
> > This solution is pretty weak, there should be one way to pass bi-
> > directional messages? I'm used to win32 programming via pipes, shared
> > memory, etc. How can we do it with Android?
> > Thanks!
> I agree, that's why I'm working on an API that extends
> the current Android messaging. I'm not aware of any shared
> memory in Android, I think it goes against the intent (pun intended)
> of using Linux processes to protect components from each other,
> but it could be there.
> What I've done is to use the android.os.Message and android.os.Handler
> as the transports for a more complete Msg which I pass in
> the android.os.Message.obj field (I would have like to just extend
> android.os.Message but its final, bummer). I use that for intra-process
> messaging. I then tunnel Msg's between processes via java.net.Socket
> and deliver these inter-process messages via the intra-process messaging.
> The upshot is that a Msg can be sent via the inter-process or intra-process
> scheme seamlessly.
> Right now I've got the intra-process messaging working and the
> inter-process partially working and hope to have both functional
> in the next few days.
> After I've created this proof of concept, and if there is interest, I'll
> Open Source it and we can create something that is useful for
> many people.
> If you or anyone else is interested let me know, (wink at saville period
> com)
I've been told that the next SDK release will have extra interfaces to
promote asynchronous binder communication. It is currently possible
to do this, but the documentation and samples don't suggest that to be
the case.
On Jan 6, 12:25 pm, Alex Pisarev <alex.pisa...@gmail.com> wrote:
> I suppose one of the most optimal solution will be to have a singleton
> class which can have a number of listeners registered as part of its
> instance.
> As soon as Service calls the post message on this class, it executes
> onReceive methods on the listeners in a cycle.
> This will be the fastest way to send something, however, it's limited
> to intra-process only.
> Regards,
> Alex
> On Jan 6, 10:02 pm, Wink Saville <w...@saville.com> wrote:
> > Mark Wyszomierski wrote:
> > >>> I'm extending the messaging to allow bi-directonal asynchronous messaging and will work within the same process or across processes.
> > > Yes that is precisely what I need - is there any facility to do that
> > > at the moment with the current API? My solution is rather messy as it
> > > involves:
> > > 1) The Activity binding to the remote Service, then calling its
> > > exposed interface functions
> > > 2) The Service broadcasts an intent back to the Activity to pass
> > > some data back
> > > This solution is pretty weak, there should be one way to pass bi-
> > > directional messages? I'm used to win32 programming via pipes, shared
> > > memory, etc. How can we do it with Android?
> > > Thanks!
> > I agree, that's why I'm working on an API that extends
> > the current Android messaging. I'm not aware of any shared
> > memory in Android, I think it goes against the intent (pun intended)
> > of using Linux processes to protect components from each other,
> > but it could be there.
> > What I've done is to use the android.os.Message and android.os.Handler
> > as the transports for a more complete Msg which I pass in
> > the android.os.Message.obj field (I would have like to just extend
> > android.os.Message but its final, bummer). I use that for intra-process
> > messaging. I then tunnel Msg's between processes via java.net.Socket
> > and deliver these inter-process messages via the intra-process messaging.
> > The upshot is that a Msg can be sent via the inter-process or intra-process
> > scheme seamlessly.
> > Right now I've got the intra-process messaging working and the
> > inter-process partially working and hope to have both functional
> > in the next few days.
> > After I've created this proof of concept, and if there is interest, I'll
> > Open Source it and we can create something that is useful for
> > many people.
> > If you or anyone else is interested let me know, (wink at saville period
> > com)
Is there any sample out there anywhere which shows how to do it?
>> I've been told that the next SDK release will have extra interfaces to promote asynchronous binder communication
The binder communication right now is fine, if you want to do it one
direction. Did 'they' say that they're going to promote bidirectional
communication?
Any word as to when the next SDK release is anyways?
Thanks,
Mark
On Jan 6, 4:04 pm, Josh Guilfoyle <jast...@gmail.com> wrote:
> I've been told that the next SDK release will have extra interfaces to
> promote asynchronous binder communication. It is currently possible
> to do this, but the documentation and samples don't suggest that to be
> the case.
> On Jan 6, 12:25 pm, Alex Pisarev <alex.pisa...@gmail.com> wrote:
> > Well, just my 2 cents.
> > I suppose one of the most optimal solution will be to have a singleton
> > class which can have a number of listeners registered as part of its
> > instance.
> > As soon as Service calls the post message on this class, it executes
> > onReceive methods on the listeners in a cycle.
> > This will be the fastest way to send something, however, it's limited
> > to intra-process only.
> > Regards,
> > Alex
> > On Jan 6, 10:02 pm, Wink Saville <w...@saville.com> wrote:
> > > Mark Wyszomierski wrote:
> > > >>> I'm extending the messaging to allow bi-directonal asynchronous messaging and will work within the same process or across processes.
> > > > Yes that is precisely what I need - is there any facility to do that
> > > > at the moment with the current API? My solution is rather messy as it
> > > > involves:
> > > > 1) The Activity binding to the remote Service, then calling its
> > > > exposed interface functions
> > > > 2) The Service broadcasts an intent back to the Activity to pass
> > > > some data back
> > > > This solution is pretty weak, there should be one way to pass bi-
> > > > directional messages? I'm used to win32 programming via pipes, shared
> > > > memory, etc. How can we do it with Android?
> > > > Thanks!
> > > I agree, that's why I'm working on an API that extends
> > > the current Android messaging. I'm not aware of any shared
> > > memory in Android, I think it goes against the intent (pun intended)
> > > of using Linux processes to protect components from each other,
> > > but it could be there.
> > > What I've done is to use the android.os.Message and android.os.Handler
> > > as the transports for a more complete Msg which I pass in
> > > the android.os.Message.obj field (I would have like to just extend
> > > android.os.Message but its final, bummer). I use that for intra-process
> > > messaging. I then tunnel Msg's between processes via java.net.Socket
> > > and deliver these inter-process messages via the intra-process messaging.
> > > The upshot is that a Msg can be sent via the inter-process or intra-process
> > > scheme seamlessly.
> > > Right now I've got the intra-process messaging working and the
> > > inter-process partially working and hope to have both functional
> > > in the next few days.
> > > After I've created this proof of concept, and if there is interest, I'll
> > > Open Source it and we can create something that is useful for
> > > many people.
> > > If you or anyone else is interested let me know, (wink at saville period
> > > com)
Mark Wyszomierski wrote: > Wink, amazing. After researching this today I have come to the same > conclusion. If you were to open source this I would at least be > interested, and if others haven't picked this up yet, I'm guessing > it's because the API is so young most people haven't tried any real > IPC yet. Once you get into this though, it's very frustrating > realizing there's no (built in) way to do it.
Yes, I should be able to get it done.
> Is there anything I can do to help?
Not right a the second but when hopefully soon.
> Do you really think you'd be able > to finish within the next few days? If not, I was going to look at > writing a simple socket class which could possibly be used for > bidirectional communication between processes. I am pretty new to > android so am not sure if it's possible but java supports it so...
If you're not familiar with the java sockets stuff learning it wouldn't hurt.
> I suppose one of the most optimal solution will be to have a singleton > class which can have a number of listeners registered as part of its > instance. > As soon as Service calls the post message on this class, it executes > onReceive methods on the listeners in a cycle. > This will be the fastest way to send something, however, it's limited > to intra-process only.
> Regards, > Alex
In my solution I have a singleton which is used to register components and defines a components location and you can then use android.os.Message/Handler to send a message directly from one component. There maybe better ways but this seems to work for now.
Josh Guilfoyle wrote: > I've been told that the next SDK release will have extra interfaces to > promote asynchronous binder communication. It is currently possible > to do this, but the documentation and samples don't suggest that to be > the case.
If they don't then I'm 100% sure we can do it ourselves.
> My Activity starts a remote service, and can bind to it to call some > interface functions. Is there any way for the Service to pass a > message to the Activity?
> All the sample apps seem to be one way communication - Activity to > Service.
|> Take a look at this posting: |> http://groups.google.com/group/android-developers/browse_thread/threa... |> |> | Zach, | | Thanks, looks interesting, but it seems that this is a | synchronous callback and hence doesn't do what I | want, but certainly could useful . | | Cheers, | | Wink | | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin)
On Jan 5, 1:06 pm, Mark Wyszomierski <mar...@gmail.com> wrote:
> My Activity starts a remote service, and can bind to it to call some
> interface functions. Is there any way for the Service to pass a
> message to the Activity?
There should be no requirement to use an IntentReceiver fore this.
You can simply define a second AIDL interface that serves as the
callback to your service, with a method on your service that hands the
interface in to it; once the service has a pointer to the interface,
it can make calls on to it as desired like any other interface.
The low-level binder IPC mechanism is fully bi-directional and
orthogonal. There is nothing special about a Service's interface at
the binder level; it is just an object you can send to another process
which can call back on to it. The underlying transport does do a
number of things to make remote interface calls look very similar to
local calls, which you should be aware of:
- All calls are synchronous (in the future we will add support for one-
way calls, but this is purely for performance and robustness reasons,
and introduces no additional functionality).
- Incoming calls from another process are dispatched out of a thread
pool maintained in the OS in each receiving process. This means that
if you are performing IPCs across processes, then you will receive the
calls outside of the main UI thread. This maintains the local call
model (by virtual of having two processes, you have multiple threads
of execution), but does mean you need to start thinking about
multithreading when implementing binder interfaces.
- Performing recursion across processes causes the later incoming call
to be dispatched on the same thread that sent the previous IPC (and is
currently waiting for the reply). This again makes the remote call
case consistent with a local method call.
- An IBinder object represents a unique handle, which will be
maintained across IPCs. That is, if you have an IBinder that you send
from process A to process B, and at any point process B sends that
object back to process A, then process A will receive the exact same
IBinder object it originally sent. This is another part of
maintaining consistency with a local call, and can be very useful for
implementing things like tokens that are sent around, since there is
no way for a process to spoof them (and you can use
IBinder.linkToDeath() to be informed when the process hosting a token
as gone away).
- HOWEVER, IInterface objects are -not- currently a unique identity --
basically IMyInterface.asInterface() will always return a new instance
of the interface (proxy) every time you call it. So when comparing
objects, always be sure to call IInterface.asBinder() and compare the
underlying IBinder objects.
The current remote service example code is admittedly extremely
simplistic; a future SDK will have a much more complete example,
including showing how to implement callback interfaces.
On Jan 6, 8:33 am, Mark Wyszomierski <mar...@gmail.com> wrote:
> It seems that the IntentReceiver class exists in a vacuum though - how
> can you communicate back with your main Activity class that an intent
> was received? It seems like there's no way to communicate between the
> IntentReceiver class and your UI classes. Example:
> public class MyIntentReceiver extends IntentReceiver{
> public void onReceiveIntent(Context context,Intent intent){
> // Ok we received an intent - now how do we let the
> Activity class know about it!
> }
> }
There are two ways to use IntentReceiver:
- The approach I think you are doing here, publishing a <receiver>
component in your manifest and implementing a top-level IntentReceiver
class. This allows your code to be run -any- time the Intent is
broadcast, whether your app is currently running or not. It is most
useful for situations where you want to wake up when some external
action happens, and not depend on having an activity or other program
component running to watch for it. This is not what you want for your
case, instead:
- Use Context.registerReceiver() to register a live IntentReceiver
object with the system to receive broadcasts, while some larger
containing component (an activity, service, or content provider) is
running. Usually your IntentReceiver implementation will be an inner
class of the associated component, such as your activity here. In
this case you do not put anything in your manifest; instead, you
supply an IntentFilter when registering that describes the Intents
your receiver will see during the time it is registered. Because it
is an inner class, it has direct access to the component (such as your
activity) that it is a part of, and it is only monitoring broadcasts
while that component is running.
On Jan 6, 5:38 pm, Wink Saville <w...@saville.com> wrote:
> Thanks, looks interesting, but it seems that this is a
> synchronous callback and hence doesn't do what I
> want, but certainly could useful .
Building asynchronous semantics on top of synchronous calls is very
simple -- just have a Handler that the recipient posts a message to,
doing its processing there. By design, it's the same as how you'd
implement an asynchronous call from a normal direct function call.
This only issue to be aware of is potential robustness problems if you
don't trust the implementation being called to actually handle it
asynchronously, which is why we will be introducing one-way binder
calls in the future... but for now, this shouldn't be a show-stopper
(and this is in fact how the vast majority of the core operating
system is implemented).
hackbod wrote: > On Jan 6, 5:38 pm, Wink Saville <w...@saville.com> wrote:
>> Thanks, looks interesting, but it seems that this is a >> synchronous callback and hence doesn't do what I >> want, but certainly could useful .
> Building asynchronous semantics on top of synchronous calls is very > simple -- just have a Handler that the recipient posts a message to, > doing its processing there. By design, it's the same as how you'd > implement an asynchronous call from a normal direct function call. > This only issue to be aware of is potential robustness problems if you > don't trust the implementation being called to actually handle it > asynchronously, which is why we will be introducing one-way binder > calls in the future... but for now, this shouldn't be a show-stopper > (and this is in fact how the vast majority of the core operating > system is implemented).
I agree you can build asynchronous on top of synchronous but as you point out robustness can be a problem. I've been using asynchronous messaging to build loosely coupled systems for a number of years and found it quite to my liking. When I saw that Android had asynchronous messaging I was excited, but then was a little disappointed when it didn't do what I wanted. Of course it has been entertaining and educational implementing what I had hoped Android would do.
Question; from the looks of the class hierarchy there are two separate messaging mechanisms in one for IPC (android.ipc.Message) and another for Intents (android.os.Message). Are these going to be unified when the one-way binder is implemented?
