You may be right, although the crash reports that I have all suggest that they were triggered from direct calls to GoogleAnalyticsTracker.trackEvent() in my code leading to "java.lang.IllegalStateException: no transaction pending". Judiciously sprinkling try-catch blocks is a great way to further "uglify" source code, so maybe I'll just live with the occasional crashes until Google fixes the problem, given that thus far only 3 out of 5000 app runs gave me crashes.
Thanks On Dec 31, 2:26 pm, H <m...@howardb.com> wrote: > You could stick a try/catch block in, but I doubt it would catch *most* of > the bugs. Remember that your request for a track simply gets added to the > database at that point and then some time later the dispatcher picks > requests up from the database and sends them (although if you ask it to > dispatch immediately you might catch them, but due to the use of handlers, I > still doubt it). So your try/catch in your code would only catch errors from > the first part and not the second. > > From the ACRA reporting in my app for the previous release of the analytics, > the vast majority of my errors were coming from the latter part of the > process where it was trying to read back from the database or failed during > the sending part or failed when removing entries from the database. > > The analytics team did state they fixed a load of bugs in this latest > release. I don't know if it's against the rules or not, but I decompiled the > latest release and built it natively into my app and that allowed me to > stick in a sprinkling of my own try/catch clauses around spots that I > thought looked tetchy. I haven't released this yet.. -- 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
