This week's book giveaway is in the Open Source forum.
We're giving away four copies of Programmers Guide to Apache Thrift and have Randy Abernethy on-line!
See this thread for details.
Win a copy of Programmers Guide to Apache Thrift this week in the Open Source forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Knute Snortum
  • Paul Clapham
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Frits Walraven
Bartenders:
  • Ganesh Patekar
  • Tim Holloway
  • salvin francis

Possible reason(s) why this code - rarely - throws NPE  RSS feed

 
Greenhorn
Posts: 4
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I'm puzzled by the following issue for weeks now. Any input or ideas would be appreciated.

I'm implementing a dragListener in a fragment as the code below shows:



The implementation works on my test devices and for the vast majority of users. However, Google Console notifies me about some users (all running Android 5.0 or Android 6.0, if that's important) having a NullPointerException on line 9, dropped.post(new Runnable(){

I feel at loss about this. For the life of me, I can't understand why the TextView dropped (apparently the culprit) would not be defined - to clarify, the dragListener is possible only on TextViews, therefore View view = (View) event.getLocalState(); can only be a TextView. May I again emphasize that this is only for some users; as I said the code words for the overwhelming majority of users.

It's hard for me to troubleshoot the error, as it seems to only affect a relatively small number of users (and I can't personally replicate it). I wonder whether it's somehow related to something in the native Java code of Android 5.0 and 6.0.

Since this particular DragEvent is only about changing the visibility of the TextView, I could plausibly surround it with a try/catch, but I don't wanna do that without knowing what's the problem - I'm afraid it might propagate further down, to other DragEvents that are much more critical.

Any ideas what could be the source of this error, or what else I could try?
If you need more details or code, I'd be happy to provide more context.

PS.
Here's the logcat - though it doesn't really provide any insights (to me at least)


 
Saloon Keeper
Posts: 10206
216
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to CodeRanch!

Android Developers API Reference wrote:public Object getLocalState ()

Returns the local state object sent to the system as part of the call to startDragAndDrop(). The object is intended to provide local information about the drag and drop operation. For example, it can indicate whether the drag and drop operation is a copy or a move.

The local state is available only to views in the activity which has started the drag operation. In all other activities this method will return null

This method returns valid data for all event actions.


Emphasis mine.

Are you starting the drag from a different activity? Can you show the startDragAndDrop() call?
 
Saloon Keeper
Posts: 5475
143
Android Firefox Browser Mac OS X Safari Tomcat Server VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch.

I don't have any insight into this particular issue, but I have experience evaluating exceptions reports using Firebase Analytics for an app with hundreds of thousands of users. Based on that I can say that there will be NPEs for just a few users in places where you just know that they shouldn't happen. Especially if it's an older Android version (which I assume can have bugs) I might not bother to do anything about it beyond preventing it by a null check, and maybe showing an alert to the user. Obviously, it depends on your circumstances -and on how many exceptions are happening- whether that is an acceptable strategy.
 
Tasos Paterakis
Greenhorn
Posts: 4
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you both for your prompt replies - glad to be here!

Stephan, it shouldn't be possible for the drag to start from another activity. Here are some further details about the code (I tried to omit any non-pertinent parts, let me know if I've left something out)




And Tim, you're absolutely right. This issue shows up 3-4 times a week, for a total number of 10.000+ users. So the numbers are clearly in favor of the code - as you said, you just know that such NPEs shouldn't happen. So, ultimately, it doesn't really affect my app - but it's an interesting puzzle nonetheless!
 
Stephan van Hulst
Saloon Keeper
Posts: 10206
216
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It seems the best way to go is to perform a null check. On line 5 in your original code, you could add something like this:
 
Tasos Paterakis
Greenhorn
Posts: 4
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the tip. Am I right to assume that the following will have the same result? If so, then perhaps this indeed will be the best approach. Though it's impossible to know why the exception is thrown in the first place, at least this will maintain functionality. Thanks for your help, I appreciate it!

 
Stephan van Hulst
Saloon Keeper
Posts: 10206
216
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not a good idea. Exception checking is slow compared to reference comparisons, and you're now also hiding other possible problems with your application.

If you insist on catching the exception, which I don't recommend, at least log the message.
 
Tasos Paterakis
Greenhorn
Posts: 4
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Perfect, it's all clear now. I'll opt for performing a null check, as you suggested. Once again, thanks
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!