Toast rather than crash when sharing giant traces

[stkent]

Fixes #25.

@pedrovgs unlike #30, there are several fairly different ways this issue could be addressed. I've included one in this PR, but am more than happy to discuss and make changes if you'd prefer a different solution. (For example, we could build an automatic retry with truncated traces into the shareTraces method.)

[pedrovgs]

Hi @stkent, sorry for the late response.

I think this implementation good but we should not show an error to the user if the trace is too long. We should measure the max trace size taking a look at the original implementation and don't try to send more traces than the one we can share depending on the OS version. What do you think? Can we update this PR implementing this change?

[stkent]

I'm not sure there's a known per-Intent limit available for us to read at runtime (see e.g. http://stackoverflow.com/questions/12496700/maximum-length-of-intent-putextra-method-force-close). The empirical "type-then-catch-the-exception" method is a way of working around that uncertainty. If you know something I don't, however, please point me to a reference in the docs!

[pedrovgs]

After researching this issue seems that there is a limit depending on the Android SDK being used and device close to 1 MB of bytes being sent using a Parcelable instance.

Here you have some references:

• https://developer.android.com/reference/android/os/TransactionTooLargeException.html
• http://stackoverflow.com/questions/11451393/what-to-do-on-transactiontoolargeexception
• http://nemanjakovacevic.net/blog/english/2015/03/24/yet-another-post-on-serializable-vs-parcelable/

Based on this information, I'd catch the exception and if the limit is exceeded we should try to share just the last 100kb of traces. Even when the limit seems to be 1MB there is a blog post saying that it could be closer to 500kb so I think the last 100kb should be enough information. What do you think @stkent? Can we update this PR implementing this behavior?

[stkent]

Awesome, yes, I think that behavior should be possible! I'll try today and let you know how it goes :)

[pedrovgs]

Great! Let me know once the code is ready and I'll take a look again 😃

[stkent]

@pedrovgs let me know what you think of the updated suggestion!

[pedrovgs]

Using this substring call you are going to take the first part of the traces but the most relevant one is the last part of the traces content. Am I wrong?

[stkent]

Good catch, fixed!

[pedrovgs]

Great @stkent! Thank you so much for your time and patience 😃 I'm merging this PR and releasing a new version!

[stkent]

No problem, thanks for maintaining a great library!

[pedrovgs]

I've just released the new version!