I am not familiar with omniture tracking, so hoping that someone who has worked on that would be able to help. What I want is to track the number of times an error dialog is displayed. For example if my app shows time out error dialog, it should be tracked in site catalyst.. Can anyone tell, how can we do this?
Check out SiteCatalyst's Android AppMeasurement User Guide for general details on implementation methods.
To track error messages, you will want to create a custom variable (a prop or eVar) and dedicate it to error messages. Then, whenever an error message is fired, define that variable and send an image request. It'd probably be a good idea to define other variables at the same time (such as the current page) so you can get additional dimensions on when/how they're firing.
The pageType variable is usually used for error handling in JavaScript tracking libraries, however this has been removed in recent Android libraries.
Related
This problem sounds really weird and it looks is somehow my mistake but isn't
I use crashlytics to keep logs and track exception of the usage of my app
for that i created a lib in the log4j interface which simple calls the crashlytics methods for log events.
On the first version of my lib i add an extra Crashlytics.logException() to every logger.error() in my code. After using it for a while i noticed that this behavior wasn't what i want and I removed the Crashlytics.logException()
BUT CRASHLYTICS KEPT SHOWING EXCEPTIONS ON THAT
I'm really confuse with that and for a long time i thought i was doing something wrong, but after debuging the code thousands of times i came to think that there is something beyond what i see
there is no metion of Crashlytics.logException() in my code, and somehow i still manage to see many errors in my crashlytics dashboard
can someone help me with that?
what events might generate a non-fatal issue on crashlytics dashboard
attach:
- https://pastebin.com/Rbu1ySpd this is the core class of my log lib
- whenever i want to log an even i do `logger.log("something");' in a very log4j way
I've just started work with Koltin and my question might be a little strange to someone who have more experience,
but how can i see fatalExceptions in logcat? For example, i have an app that is already developed by another dev,
there is an error in one activity - after pressing the button apps crash and restart to main activity.
I don't see any usefull informations in logcat(in fabric also!), moving on trough whole code from listener to fragment and many classess is very time consuming. There must be some way to figure it out quicker, right?
Exceptions should be shown/thrown in logcat, same as with Java.
If the exception is thown within rxjava or a kotlin coroutine, make sure you have defined an error handler, otherwise the exception might get swallowed.
Then make sure you have selected the right app in logcat and that no filter is active.
Also make sure there is no other global Exception handler defined besides fabric.
I'm extremely curious how there is 0 code written within the application and all that is required is to use the library
compile 'com.google.firebase:firebase-crash:9.0.1'
in order to get firebase crash reporting working.
Is the initialization always a one time thing like how the application class' onCreate is always called just once?
What do I do if i want to enable crash reporting only after a certain event?
Update: There is now a comprehensive blog post about how Firebase components initialize.
Firebase Crash Reporting (in addition to other Firebase components) initialize in a ContentProvider that's included into your app automatically. ContentProviders are instantiated first, then your Application subclass, then whatever component was invoked (Activity, Service, BroadcastReciever).
When your project depends on an Android Library project (aar file), all of its manifest entries are merged into your app, so you get this ContentProvider for free simply by declaring declaring the dependency on firebase-crash.
I gave a talk at Google I/O 2016 about how this all works. Jump to 16:22 for the beginning of the content specific to crash reporting.
Unfortunately there is currently no way to programmatically enable or disable crash reporting, but that is coming soon.
So basically when I'm using Firebase Crash Reporting then I'm forced to do initialization in ContentProvider. My app have 2 processes because of this and if I do init in Application.onCreate then it's called twice - once for each process. But other processes don't care about my init code so I don't want to do it twice. So I can use a ContentProvider or check current process name.
Or maybe there is anything else that I'm missing?
I'm building an app that sometimes crashes, I want to know that it crashed in the next time I opened it so I can suggest to the user some post-crash options.
How can I detect the crash?
Also I want to be able to save the user's work before it crashes, I means real time detection of crash, can I do it without knowing where it crashed?
You will need to know where it crashed in order to set the try/catch blocks in the right place to, er, catch the crash and save the data or whatever you have in mind.
This is known as "graceful" termination if you want to consider it in more detail.
Unfortunately neither Java destructor/finalize methods nor lifecycle methods such as onDestroy are anywhere near as robust as try/catch blocks so I'm afraid that is your only option, and how many of us deal with exception prevention. No-one would wittingly provide a user experience that crashes, much less with loss of their data.
Take a took at the ACRA library. You can configure it so whenever a crash happens you can control it and even send the crash log by email
You can use try/catch blocks, then send details on the Exception in your catch.
There are implement UncaughtExceptionHandler as mentioned in these answers and write crash report in some file or use it another way.
ACRA is already mentioned.
However for paid version, I found BugSnag is very good at this.
Or if you want to take the extra mile, try AppSee.
AppSee even has video recording session of how the crash happens. It is from tapping that button on the second list, the menu button or even when the user slides left in your viewpager.
My Android app uses the AWS Java SDK for uploading user photos to S3.
Whenever a user's phone's clock is 'skewed', this causes all transfers to fail. This is a well documented aspect of S3:
http://aws.amazon.com/articles/1109?_encoding=UTF8&jiveRedirect=1#04
It appears that the upstream S3 service reports this error quite clearly:
HTTP Status Code: 403 Forbidden
Error Code: RequestTimeToo-Skewed
Description: The difference between the request time and the server's
time is too large.
However when using the Java SDK, it seems as if the informative 403 code is lost ... and I have only an opaque "TransferState.Failed" to go by (which incidentally is the same error if internet connectivity is lost, if it times out, etc...).
As far as I can tell from the docs:
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/index.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/TransferProgress.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/Transfer.TransferState.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/Upload.html
There is no way to get the additional "RequestTimeToo-Skewed" metadata about a transfer failure.
Am I missing it? Is there any way to get additional error information when an S3 transfer fails using Amazon's Java SDK?
UPDATE #1:
A commenter kindly highlighted that I should clarity two points:
I am actually using the AWS SDK for Android (which seems very similar to the Java SDK, but is nonetheless distinct)
I am using the TransferManager class to perform my upload. Apparently, this is a high-level class that wraps the lower-level AmazonS3Client ... and this lower-level class should expose the error reporting I need, but I am still investigating the exact tradeoffs involved between TransferManager and AmazonS3Client. As far as I can tell, there is no way to get progress information via the (synchronous) AmazonS3Client.putObjectRequest which would be a blocker for me...
UPDATE #2:
My sincere thanks to Jason (of the AWS SDK team) for stopping by and helping me out here. The important information is, indeed, available as properties on an AmazonS3Exception if you use certain methods. The docs had originally confused me and I thought that a manual Thread.sleep() loop was required to poll status (and thus I could not leverage waitForCompletion or waitForException), but if you use ProgressListener on PutObjectRequest you can get full progress callbacks and the error-fidelity of AmazonS3Exception.
these two methods should help you out:
Transfer.waitForCompletion()
Transfer.waitForException()
If you detect that your transfer has failed based on a transfer progress event, you can simply call Transfer.waitForException() to be returned the exception that occurred. That exception will be an AmazonServiceException in this case, with all of the info that you need to see that the real problem was a clock skew issue.
Alternatively, the Transfer.waitForCompletion() method will unwrap the original exception from an ExecutionException and directly throw the original exception, just as if it'd all been happening on one thread. This might be a more convenient approach if you want to use a catch blocks to catch different types of errors cleanly and elegantly.
I disagree that the "catch Exception" block is "brutally broad". The point of that code is to catch any error that happens, mark the transfer as failed and rethrow the error so that the application code can know about it. If it were less broad, then that's exactly the case where exceptions could sneak through and transfer progress wouldn't be updated correctly and would be out of sync with reality.
Give those two methods and shot and let us know if that helps!
Well, I have debugged Amazon's SDK and I'm sorry to say that this information is being swallowed internally. Perhaps I will try to submit a patch.
Details: an AmazonS3Exception is being thrown internally which does in fact accurately report this exact error scenario, but a brutally broad try catch ( Exception e ) consumes it and washes away the specificity.
Here is the guilty try-catch:
https://github.com/aws/aws-sdk-java/blob/master/src/main/java/com/amazonaws/services/s3/transfer/internal/UploadMonitor.java#L145
Here is a screenshot showing that an AmazonS3Exception is correctly thrown with the right info...