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
-~----------~----~----~----~------~----~------~--~---
