mmmmmmmmm.... you mean that the value of 'N 'could be larger than the
actual elements accessed by getBroadcastItem(i), i.e. HashMap changes
while looping over the 'N' items...?
For now, i'm check for null and just ignore it. The problem is that it
is very hard to reproduce. It happens on rare occasions, but often
enough to be problematic.
This line has only 3 points in which it could throw a null-pointer
exception (the stack-trace reports the NPE on this line, not inside
progressChanged(...)):
- mCallbacks is null: Not possible. It is declared final and refers to
an instance.
- qiu is null: Not possible. It is a stack-variable and it has been
guarded against null value.
- getBroadcastItem(i): The only one left...
I thought that beginBroadcast() would lock the callback-list for
modification and finishBroadcast() would unlock it again. This way, N
should always be the number of items in this HashMap you were
mentioning. Am i correct in this.
I'll let you know if i can figure out which values for 'i' are
problematic :-)
Thanks for your help.
On Mar 12, 9:27 pm, Dianne Hackborn <hack...@android.com> wrote:
> Hm actually could you see if it is the -last- ones that are null? The code
> that makes the list gets a count from the HashMap, and then iterates through
> its values and puts them in the array, and returns the original count. So
> if that count is different than the number it iterated over, that could be a
> problem. I'll change it to return the actual number it iterated over, but
> in theory these shouldn't be different.
>
> On Thu, Mar 12, 2009 at 6:25 PM, Dianne Hackborn <hack...@android.com>wrote:
>
>
>
>
>
> > The callbacks are just stored in a HashMap, and the entries there are never
> > set null (actually that field is final), so I don't really see how that can
> > happen. Are you sure you aren't potentially doing this loop from different
> > threads without doing your own synchronization?
>
> > On Thu, Mar 12, 2009 at 6:07 PM, Streets Of Boston <
> > flyingdutc...@gmail.com> wrote:
>
> >> Hi,
>
> >> I found out that RemoteCallbackList.getBroadcastItem(int) sometimes
> >> returns null. I have this code in my Service and it raises a null-
> >> pointer exception:
>
> >> ...
> >> // instance variable of my Service
> >> final RemoteCallbackList<IProgressCallback> mCallbacks
> >> = new RemoteCallbackList<IProgressCallback>();
>
> >> ...
> >> ...
> >> public boolean sendProgressCallback(String imgUri, int albumId, int
> >> progressBytes, int progressPercent) {
> >> final QueuedImageUpload qiu = getUploadingImage(imgUri, albumId);
> >> if (qiu == null)
> >> return true;
>
> >> qiu.setSizeUploaded(progressBytes);
>
> >> final int totalSizePercent =
> >> mQueues.calculateRemainingSizePercent();
> >> final int N = mCallbacks.beginBroadcast();
> >> try {
> >> for (int i = 0; i < N; i++) {
> >> try {
> >> if
> >> (!mCallbacks.getBroadcastItem(i).progressChanged(qiu.getID(),
> >> imgUri, albumId, progressPercent, totalSizePercent)) {
> >> return false;
> >> }
> >> } catch (RemoteException e) {
> >> // The RemoteCallbackList will take care of
> >> removing
> >> // the dead object for us.
> >> }
> >> }
> >> }
> >> finally {
> >> mCallbacks.finishBroadcast();
> >> }
> >> return true;
> >> }
>
> >> This line is the one throwing a nullpointer exception:
> >> "if (!mCallbacks.getBroadcastItem(i).progressChanged(qiu.getID(),
> >> imgUri, albumId, progressPercent, totalSizePercent))"
>
> >> - The mCallbacks is never null. It is declared as final.
> >> - The local 'qui' stack-variable is never null. It is guarded by a
> >> null-pointer check.
>
> >> That only leads me to conclude that the call getBroadcastItem(i)
> >> returns null. However, the documentation states that this method never
> >> returns null. Is this a bug in Android?
>
> >> This problem only happens on occasion (I can not reproduce it
> >> consistently), but it happens often enough to be of concern for my
> >> app.
>
> >> BTW, someone else reported the same problem a while ago:
>
> >>http://groups.google.com/group/android-developers/browse_thread/threa...
>
> >> Thank you.
> >> -- Anton Spaans
> >>http://soft.antonspaans.com
>
> > --
> > 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
-~----------~----~----~----~------~----~------~--~---
