Alas, this one is not a one-way interface. It expects a boolean back: False = cancel upload of image, True = continue uploading image. It allows the (remote) client to cancel uploads forcefully. Luckily, the client receiving the call-back can return this answer really fast.
The client is not the same process. It is a different app (Activity) in a different process. What is your opinion, in terms of speed/performance: One 'mCallbacks' instance for the Service, sending this callback to its clients, inside a synchronized(...) block or having each a 'mCallbacks' for each thread (max 3)? Which one would be better? The client is always remote (other process). Thanks! On Mar 13, 2:29 pm, Dianne Hackborn <hack...@android.com> wrote: > If your callbacks are oneway, the easiest thing to do is put it all in a big > synchronized() block. Be aware though that if the callback is into the > local process, it will still be synchronous, so holding a lock while doing > this can be a problem. > > Usually the safest thing is to have a handler that you post a message to, > which does the callbacks. Then you don't need any locking since the > broadcasts are serialized by the handler. > > On Fri, Mar 13, 2009 at 10:55 AM, Streets Of Boston <flyingdutc...@gmail.com > > > > > > > wrote: > > > Ah, now i get it! :-) > > > Indeed, sendProgressCallback can be called from multiple threads. And > > with your earlier explanation that the beginBroadcast does not do > > locking (only a brief internal lock), it may explain the problem. In > > other words, RemoteCallbackList is not thread-safe across multiple > > calls to it. > > > I should put the broadcast code inside a 'synchronized(mCallbacks) > > { ... }' block or surround it with a ReentrantLock. > > Or create mCallbacks instances for each possible thread and have my > > listeners register with each of them. > > > Thank you very much for your help. > > Have a great weekend! > > > On Mar 13, 12:58 pm, Dianne Hackborn <hack...@android.com> wrote: > > > On Fri, Mar 13, 2009 at 7:27 AM, Streets Of Boston > > > <flyingdutc...@gmail.com>wrote: > > > > > Either way, it means that the number of items in the list accessed by > > > > getBroadcastItem is always equal to N. > > > > The problem remains: How can getBroadcastItem(int) return null? > > > > I'm not sure what you mean by "either way" -- if you are doing this from > > > multiple threads, your threads can clobber the list, which can lead to > > this > > > kind of problem. > > > > -- > > > Dianne Hackborn > > > Android framework engineer > > > hack...@android.com > > > > Note: please don't send private questions to me, as I don't have time to > > > provide private support. All such questions should be posted on public > > > forums, where I and others can see and answer them. > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them.- 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 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 -~----------~----~----~----~------~----~------~--~---