Over a million developers have joined DZone.

Stupid Mistakes Devs Make, Part I: Taking App Messages at Face Value

· Java Zone

Learn more about the advantages of moving from a monolithic to microservices architecture.  Brought to you in partnership with IBM.

This is a new series about programming blunders I make. Stuff that keeps me looking for solutions in all the wrong places while the answer most often is glaringly simple. If only I knew that right away!

I am sorry for the generalization in the headline – of course it’s only me doing stupid stuff like that ;-)

Mistake of the day

Yesterday I was happily coding the sharing action for my upcoming app. This particular ShareActionProvider of the app lets users share a picture of their progress with keeping bad habits in check. I create an image and make it available to other apps via a content:// Uri. Nothing spectacular about that.

You might know that the Email app asks your ContentProvider for the display name and the file size of the shared image. The image in question is about 20K in size. That’s far from being an overly big picture. Nevertheless I got the message that the attachment was too large:

Toast showing that the attachment was too large

Toast showing that the attachment was too large

This left me wondering, what might possibly be wrong. I looked at the log messages. Check. I looked at the size of the stored image. Check. I debugged into my content provider to see that it reported the correct file size. Check. Starting to go out of ideas I even adb pulled the file and opened it in an image viewer. Check – it indeed was an image. I had another look at logcat. Check. All fine. So what the heck… My curse level had increased considerably! Never a good sign.

But wait a moment. One of those checks above was not correct. Actually two of those were not correct. And – to be honest – just assuming that the message of the Email app was correct, probably was the first mistake. It totally misled me – and even worse: I let it do that.

Finally I looked a bit more carefully. It turns out that I stopped debugging my content provider too early. And that I grepped logcat too rigorously.

My content provider crashed shortly after the line where I stopped debugging, assuming everything to be perfectly fine. This assumption proved to be very wrong, since my code ran into a ClassCastException :-(

And I didn’t see it in logcat because I renamed my package a few days ago, but didn’t rename my logging tag. The tag was the final part of the old app package name. And I grepped only for this tag – which proved to be very stupid! With this clever way of grepping any hints of stacktraces were gone.

Finally: I didn’t notice this problem in any tests, because I do not work test first and simply had no tests for the sharing part of my provider.

BTW: I do neither get the “File too large to attach” message on an old API level 8 device, nor on my GNex or my N5. Alas I had my Nexus 7 used for testing, which I update rarely since it’s a testing device only. The Email app seems to have been fixed. So with any of my other testing devices, I probably wouldn’t have had the same problems. It was just one of those days :-(

Lessons learned

Actually running into stuff like this is not all bad. Okay, granted: It is. I wasted too much time with it. But the good part is, that it’s just another lesson along the way. And a lesson I probably won’t forget that soon.

For this day my takeaways were:

  • Do not trust messages of other apps
  • Do not rename packages without renaming logcat tags as well
  • Stop being so sloppy with your tests

That’s it for today. The next post in this series will have the name “Be careful with that package name, Eugene”. Obviously it nicely fits the scheme of this post since it’s just another package name mishap.

Have you experienced anything like that? If so, please let us know in the comments. Don’t let me be the only fool around :-)

From Idea to Application gives you the architecture to quickly build, manage and run a range of applications (web, mobile, big data, new smart devices, etc.) on an open-standard, cloud-based platform. See why developers are using IBM Bluemix. Brought to you in partnership with IBM.


Published at DZone with permission of Wolfram Rittmeyer, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}