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