I am using kind of results search engine, problem is to remember the searching criteria i made singleton static class which keeps only one instance.
In my application there are lots of class level private variables, lots of public static variables, a big util class which contains only static final methods.
problem is my application get crash any time any where any spot and interesting thing is crash code always surrounded by try{} catch(Throwable e){} block but never catch, i think it may be memory full issue.
I want to discuss one sample case, on the result page i also display result related image, i download image from web and using drawable i place image in the imageview, i created static hashmap to reuse images, some time after downlaod 5 images application crash some times click on a result get user to new detail screen get crash and all code surrounded by try catch block, i am new to mobile program this thing has become night mare to me.
Last thing, On emulator hardly application crash but when i try to test the application on device, i am using samsung glaxy android supported to test the application it goes smoth and suddenly it start getting crashed, and after crash android relaunch the activity that throws null pointer exception on every click and caught by try{}catch{} block i think after crashing android dealocate all objects only keep the UI objects thats why when after crash i auto launch the activity clicking causes null pointer exception.
how can i stop relaunching crashed activity ????
Here are some suggestions that might help track down your issue(s):
introduce logging - use Log to log useful (debugging) info
avoid empty catch blocks - use Log.e() to log your exceptions
reduce functionality to a minimum for debugging
In order to get a useful answer on Stackoverflow you'll have to do all of the above and provide a more detailed problem description (e.g. a specific stacktrace in your logcat output).
Also, there is an article about Avoiding Memory Leaks that might be interesting to you.
Related
I started a few months ago to program in android doing my first app that consists of taking orders like a waiters app.
As it was the first app you can imagine that i wasn't aiming for the optimization but that was a big mistake. I've deployed app in some restaurants and till this moment all was going well.
The issue:
Now the app was installed in a restaurant where they take a lot of orders for a single table they can get up to 10 minutes where they take orders and yesterday i've got a call where they said that the app was crashing on tables with a lot of people.
Now i'm trying to simulate what happened in my company.
The App:
The app consist of the Main screen where the user can choose to enter in settings or in the orders then there is another "login" activity and then the "main" where there is an alert that asks for the number of table then the waiter takes order and send it.
After sending i'm just "resetting" the activity or better by clearing the recyclerView out of items and settings all values to 0 but i think that it's produce a "little" memory leak.
Conclusion:
Now i would have as more as possible suggestions on how can i improve my app performance or better how could i prevent memory leak or even if it's possible to "recreate" the activity in someway after the waiters send the receipt so i could "save" some memory or idk.
Actually here is a screen of profiling, i don't know it it's could help
Good practices to avoid memory leaks IMHO:
avoid storing android context statically in helper or data classes
remember to unregister broadcast receivers once their job it's finished. A good practice is to register inside onResume() method and unregister inside onPause() method
prefer the usage of LiveData for your "model" classes
use LeakCanary library to detect any potential leak
be careful with the usage of static variables, remember to set them to null once are no longer useful to the application, that way they would be eligible to be garbage collected.
You can find an interesting article about this topic on Medium
First of all you seem to not have a CrashReport library on your app. So first thing to do is to add Crashlytics to your app.
Get clear, actionable insight into app issues with this powerful crash reporting solution for Android
Then if you think you have leaks on your app, I suggest you use CanaryLeak
A memory leak detection library for Android and Java.
Once Crashlytics in place you will know where the issue comes from. It can give you as far as the line of code that crashes your app.
Do you have any subscribers to events which is not unsubscribed? This is a common pitfall for memory leaks. I suggest that you use a memory profiler to profile the memory usage. This article gives you an introduction if you are using android studio:
https://developer.android.com/studio/profile/memory-profiler
As highlighted by the others, without specifics, it is hard to know what is the cause of the memory leak.
I wrote apps for Android tablet at restaurants in Beijing (Lily's American Diners), and I struggled with leaks for a long time. The problem is you have tablets Android tablets running for 14 hours a day so you have to have very robust architecture so things do leak and get torn down by the OS.
1) Canaryleak and Crashylytics are good ideas. I used ACRA.
2) Try to avoid popups, global variables, all the obvious things.
3) I use a background service to handle uploading data to the server, downloading menus from the server, printing to POS printers.
4) For network operations, use OKHTTP, it makes all the Async network operations cleaner.
5) For image loading, use Square Picasso. it makes all the image cashing cleaner.
6) In your lifecycle architecture,minimize activities. I use 1 single instance activity for the splash screen initial load and 1 single instance activity if they choose to do the manager operations, setttings, etc., then, there is 1 activity that runs the whole day long and handles everything. Within that activity, I use a ViewFlipper to quickly change "pages" (views) for each of the following operations:
a) choosing items from the menu
b) showing the ticket of selected items
c) showing large pics of the dish or special options for each dish
d) showing a successful sent order
e) showing an unsuccessfully sent order
f) showing the choose table screen for customers or waiters, whoever does it.
g) showing daily specials
The other big issue is persistent storage so orders and menus don't get lost, etc during the long running operation of these kinds of apps. i made extensive use of shared preferences.
Good luck.
There are many different possibilities, for example:
Database remains opened
Data cannot encapsulate properly.
From Shared Preference
These are common possibilities from where the data may leak.
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.
I am creating an android application. It holds a downloading process from server. It's running fine until the application runs and maintains the data without any crashes, but now I am stuck up with the problem as described below
When the application minimizes by pressing home button and after a long time, when I open the application all the data in the application are deleted. It gives me a "Null Pointer Exception"; even the ArrayList value are deleted and it gives a 0 sized arraylist.
I am opening the application after maximizing from the home screen through OnResume only, but it didn't call itself.
I don't know why this problem occurs. Can anyone please suggest me a solution and point me what am I doing wrong?
Yes, it's true - as #paradx said - that the Garbage Collector throws away the data while the app is in background. Finally I found a solution based on #paradx suggestion, as data are stored in SQLite or savedInstanceState
Just pass some of static values through the
intent.putExtra("static key","static value");
Then static hashmap are written in a file and retrieved for later use. Now the application does not crash for this problem.
I have posted this solution so that someone might use it.
My guess is, that the garbage collector throws away your data while your app is in the background. try saving your data either to the built in SQLite database, or to the savedInstanceState bundle in the onSaveInstanceState() lifecycle method and load it back in the onRestoreInstanceState() method.
Did u use the apache HTTP client or the UrlConnection?
See Apache http client or URLConnection
Maybe the wrong use could lead to such an NPE.
Could you also please post your logCat output?
I have a multi-Threaded android application. One of the things my application does is saves various data to a database on a server via webservices. I was trying to figure out why things were not saving to the server correctly, and saw in one of my log files, that the application objects onCreate() method and constructor were called in the middle of one of the requests going up to the server. These request are in the background and are sent via an intentservice.
I have my application set to catch unhandled exceptions and log them, and I did not see anthing in there. The application onCreate() and constructor was called, the application was kicked back to the main/first screen, the user then had to re-login, and it seems that the database was wiped(which is something else I am wondering about).
So, my main questions are: Why did the application object onCreate() and Constructor get called(why did the application get killed), why did the database get wiped when the above happened because if I do a force stop from inside of settings, applications, it never kills my db.
two words: low memory
I have the same problem. No solution for now. Try to take advantage of the onLowMemory() method, maybe the OS will spare your app.
My application object gets restarted randomly (not any time) when I am coming back from an external application (ex. camera or gallery) for onActivityResult().
Hope that helps someone.
If the application is not a service, but a 'normal' application that calles your intentservice, it is subject to the normal application lifecycle: this means it will get killed when in the background.
Look for the explaining image on this site: http://developer.android.com/guide/topics/fundamentals/activities.html
Take note of the red "Process is killed" part on the left, an the subsequent "onCreate()" afterwards.
I've actually seen very similar behaviour that was caused by a NumberFormater trying to parse a null String. After the call to parse(), the application simply reset itself back to the splash screen with no errors at all. Wasn't fun to track down, pretty much stepped through half the code base trying to find out what was happening - the debugger disconnected and the app restarted when stepping past the parse call.
I'm working with a fairly complex data edit activity in Android that makes use of the bundle object a lot when saving form data.
In general this works pretty well and I haven't experienced any data loss. However I have a strange intermittent bug that I can't seem to find the direct cause of.
It happens when I send an intent to the gallery (using startActivityForResult) to enable the user to select a profile image. A small (96x96) bitmap is returned in the bundle, and I save this data to their profile. This works flawlessly about 90% of the time, however on some occasions instead of returning with the image saved in a bundle, it will return a bundle that cannot be parsed. This occurs fairly frequently if I leave the device sitting in the gallery select mode for several minutes. (>5 minutes of idling).
When I attempt to access any functionality of the bundle at all I get the following runtime exception:
java.lang.RuntimeException: Parcel android.os.Parcel#44a06078: Unmarshalling unknown type code -8913000 at offset 392
Things of note:
o When this error occurs it appears that the edit activity has been destroyed and needs to be recreated. (Before the error occurs it progresses through onCreate, onStart and onRestoreInstanceState (Where the crash originates)).
o This appears to cause it to skip the "onActivityResult" section (or at least never reaches that far.
o The bundle object retrieved in onRestoreInstanceState is not null, but any other access to the object (including checking if its empty) result in this crash.
o By checking the bundle source code, I found that the crash seems to originate from the bundle performing an internal type check using a stored int flag. The error occurs when the int flag comes up with a type not in the list (so far it consistently has been -8913000).
o I've only seen this error on froyo so far (2.2)
Has anyone encountered a similar error to this? Does anyone have a suggestion on where to look next?
In the mean time I'm going to try to put together a slimmed down version of this section of code that might be post-able, and see if that still reproduces the problem in question.