Since ACRA.init can only be called once and ACRA.getConfig() and ACRA.getConfig().setFormUri(uri) are both deprecated.Is there any correct way to change formUri programatically, once ACRA has been already initialized?
In our development app we are testing against several environments and we have different formUris to store ACRA errors, so each time we change to a new environment we must reconfigure ACRA to send all the errors to that formUri.
Right now we are using ACRA.getConfig().setFormUri(uri).
But we are afraid that this won't be possible in the nearby future, so is there any alternative?
There are no plans to allow ACRA to be initialised multiple times. It would introduced unnecessary complexity into a component that you need to be as rock solid as possible.
But you still have the capability of setting the formUri programmatically. You can just set it only once.
You clearly have some event at runtime that knows/determines which environment you are in. So you could set a SharedPreference at that point outlining the target formUri. Restart the app and have the formUri come from the SharedPreference.
NB this is an extremely unusual use case. Why do you have a separate formUri for the different environments for the one app? Why not have a single error repo and filter reports based upon some attribute in the report, such as environment?
IMHO having separate error reporting servers for even dev and release versions of an app is a nett negative as it means there is one more thing that you have changed between dev and release that you didn't need to. Less moving parts, less complexity == greater robustness.
But we are afraid that this won't be possible in the nearby future
You are right, 4.9.0 removes setFormUri
So is there any alternative?
Currently not. You can watch the discussion here.
The 5.2.0 version of ACRA will allow re-initialization, so the correct way will be to alter the configuration re-initialize.
Specifically, ACRA.init() will succeed but emit a stern warning for all inits after the first time, but it will throw away the old configuration and take settings from the new one.
Related
Is there a way I can get the hierchary view/layout of other running android apps? If that's not possible, could I possibly unpack the app's .apk file and get the information there? For example, there's a setting in developer options that allows you to get the bounds of every elememt on the screen like so
EDIT
I have come to realize that this is not allowed and goes completely against the Android SDK. I apologize for this error and will look more closely in the future.
I have found out that Google blocks any of this because it would require me to inject my own code into other apps, which is not allowed due to malicious behavior in past apps.
So I have an android application that has a myriad of activities (intents?) which all do their own thing. We were wanting to create a sort of debug log though, one where you can see what the user has been through and error that occurs. You may have had to send one before if you've run into a bug with a program you've used.
My initial thoughts are to just create a class where I can send information/data to and it just writes it onto a text file. It would need to be accessible across all the activities so that I can easily write to it and re-use it.
I do wonder whether that's a good way to go through, noted that it doesn't really save any actual errors but only data I tell it to. And I'm not sure if its a great idea to be constantly opening->writing->closing a file for a debug log.
Is there a smarter way? Or a common pattern that would be good to use?
Thanks so much!
Sentry's Android SDK, will automatically report errors and exceptions in your application.
The Sentry SDK catches the exception right before the crash and builds a crash report that will persist to the disk. The SDK will try to send the report right after the crash, but since the environment may be unstable at the crash time, the report is guaranteed to send once the application is started again.
You can see full documentation here
Why and when should I use the android Logging? Should it be used only for debugging purposes? It seems to me that if kept in a production application, it would slow it down considerably.
One key part of my question, is WHEN it should be used...in what cases should I need it? Are there any 'best practices' for using this?
This may be a very stupid or amateur question, but I've never understood the need or felt compelled to use it. I may be missing something.
http://developer.android.com/reference/android/util/Log.html
Also - I already know that logging for errors/verbose/info/etc are different, and some are discarded when not debugging. Please don't reiterate the information that's in the class overview without giving me an explanation why. Thanks!
I agree with you, I never really used it either. I much prefer debugging over log reading (and unit-testing over debugging), when trying to figure out what's happening and getting an error.
Some people argue it can be useful to log "additional details" when your application crashes and get an exception, but I usually reply to them that the exception itself should hold that additional details when necessary, and expose them in its getMessage. Thus, the default stack trace that's included in the LogCat is more than enough to see what's going on.
But anyway, it's always nice to have the possibility to log something, even though I haven't found it really useful so far, you never know when it might help :)
Regarding my comment, see Preparing for Release. (Showing logging should be removed before release, hence not being used in production).
Turn off logging and debugging
Make sure you deactivate logging and disable the debugging option before you build your
application for release. You can deactivate logging by removing calls to Log methods
in your source files.
I used logging the other day, I fired off another thread to do some work but I needed to check some data being produced in the thread, without logging or displaying Toast's, how could I get the values? I'm tried debugging/stepping through code in Eclipse before and just run into several problems.
With logging, I can log each value, view the logcat and know exactly what my code is doing.
You usually debug only when you know there is something wrong. (And when you know, you might write additional test cases.)
With logging (at the INFO level, for example), you can add some additional information to trace the data in the app. This allows you to find out that there is something wrong.
Thus, it adds a higher-level overview.
Additionally, it can be easily disabled, does not slow the app down significantly (if done right), and might thus offer another avenue of approach to see if everything works correctly, with few disadvantages and some advantages. (See also Logging vs. Debugging, especially the links in #smonff's answer.)
Is there a way to report Bugs, similar to the Android Feedback Client, but without registering my application at the market. I'm still working on the application and some users are alpha testing it so it would be useful to receive reports/ stacktraces etc. Is there a common way or an application for that?
You can look at ACRA Project - http://acra.googlecode.com/
You can use Instabug which lets you report bugs right from the app by shaking the phone. It sends you all the device details, network logs, view hierarchy inspection, as well as the steps to reproduce it. It takes a line of code to integrate.
For full disclosure. I work at Instabug.
I've used acra and it works well: http://acra.googlecode.com/
see: How do I obtain crash-data from my Android application?
I have used Android Remote Stacktrace before, it was very easy to setup, but when I set it up I don't think it had as many options as A.C.R.A does - I haven't used either in a while so I'm not sure which is better.
So, I have found a bug in a specific sdk that causes it to fail on some Android phones after re-installing a new version of an app which uses the sdk (via adb install -r, and presumably when a user gets an update that has been pushed to the Android market). Is there any way to force an application's data to automatically be cleared upon update of the app? I realize there are different ways that data could be stored, but I just need to essentially simulate an invocation of the "Clear Data" button that'd you find when browsing to the application in the "Manage Applications" section of the Settings (i.e. I just want all data gone).
I am an Android noob and am doing minimal Java coding on this project, so I am basically looking for the simplest solution here. I suppose I could settle on storing a "currentVersion" to disk and then checking it upon launch every time to see if the real current version matches the version that was written to disk on the last launch. Is that the only real way to do this? If so, what's the simplest way to do so?
Thanks!
Is there any way to force an application's data to automatically be cleared upon update of the app?
No, at least for my definition of "automatic".
I suppose I could settle on storing a "currentVersion" to disk and then checking it upon launch every time to see if the real current version matches the version that was written to disk on the last launch. Is that the only real way to do this?
I'd name it lastKnownVersion, but otherwise this approach seems sound and probably is your only viable option.
If so, what's the simplest way to do so?
Ummm...do exactly what you said. Use Java I/O (storing the file somewhere inside of getFilesDir()), or SharedPreferences.
Bear in mind, though, that your users may get rather frustrated if you blow away their data on an app update. Personally, I'd rather we find a better solution to your original problem ("I have found a bug in a specific sdk that causes it to fail on some Android phones after re-installing a new version of an app which uses the sdk").