From the crash logs that I am getting from the Android market, I can see
that some of my users are getting Force Closes caused by
NullPointerExceptions when my code tries to access views that are in my
application. In one example, my activity makes a call to findViewById()
in onCreate() after I call setContentView(). I get an NPE when I try to
access the view after the call to findViewById() (still in onCreate).
What has me really scratching my head is that this does not happen all
of the time (in fact most of the time the code acts as I would expect),
but enough to have me concerned.
I could add code to always check for null and avoid the NPE, but I
would like to understand what could be causing the sporadic behavior.
Does anyone know what could be causing this?
Rename that view may be you can find the view as expected.
Related
I have an app where I use Butterknife, and recently I found a fragment where I had failed to call unbinder.unbind() in the fragment's onDestroyView(). I fixed the problem but it made me start thinking.
What kind of errors can this cause and why? I don't have a particular error right now but I would like to know what to watch out for in the future, and the website for the library doesn't specify the problems this could cause.
Imagine you have a retained fragment and you have initialized a view using #BindView.
An orientation change happens, which results in destroying activity instance, but not this fragment, because this fragment is a retained fragment, which means, that the field that you have initialized is still there (not null) and is holding a strong reference to the view of the previous activity, which results in leaking of the activity.
Although this might take for some small amount of time (because eventually you are going to perform another ButterKnife.bind() in onViewCreated(), right? But who knows, maybe you won't), still it is better to release resources as soon as you do not need them and let the GC do its job.
I've also thought about this question some time ago and other than this I couldn't come up to another scenario where unbind() would be strongly necessary.
Im just coding the Android application which I thought of in order to learn the SDK a little more and ran into a problem when trying my program with the emulator. The application installs normally and then closes only to give me a logcat saying theres a NullPointerException in the main class. I cant manage to find it anywhere and research says that theres an object being used without it being initialized? I dont think this is possible as if it were the case, Eclipse would give me an error, but in this case it is a runtime exception. I do not have a lot of programming experience especially in Android and this bug is stopping me from seeing if the rest of my program works!
Heres the Source
and heres the Logcat
Thanks in advance for any help
The error occurs on line 80 in your onCreate method in IOweYou.java. You can see it on line 19 in the stacktrace you posted.
08-03 07:11:35.068: E/AndroidRuntime(681): at com.andrei.iou.IOweYou.onCreate(IOweYou.java:80)
Is localEL properly defined?
EDIT:
make your activity extend ExpandableListActivity instead of activity. Then remove setContentView. And change
localEl.setListAdapter(mAdapter);
to
this.setListAdapter(mAdapter);
and your list will show. However clicking on the item will still make it crash but its a start!
EDIT2:
here is an example I found.
http://smartandroidians.blogspot.com.es/2010/04/expandablelistactivity-in-android.html
I think the problem is that your ExpandableListActivity localEl has been created but not launched. When you call localEL.setListAdapter(mAdapter); it internally calls its setContentView, as is shown in the log. Probably getWindow() returns null because the activity has not yet been initalized.
Without knowing much of what you want to do, perhaps your activity should instead inherit from ExpandableListActivity?
So I have a strange problem, and I'm not entirely sure what all information I should provide, but I'll do my best -- just let me know if I need to add more info. I'm having an issue that when I finish my Activity and return to the previous Activity (or launch it with a new Intent -- the problem seems to be centered on finishing the Activity) the UI performance drops drastically for about six or seven seconds, then returns to normal.
From LogCat, this warning appears consistently:
07-11 22:09:42.594: W/ActivityManager(292): Launch timeout has expired, giving up wake lock!
07-11 22:09:42.601: W/ActivityManager(292): Activity idle timeout for ActivityRecord{42bf6e00 com.kcoppock.sudokubeta/com.kcoppock.sudoku.SudokuBoardActivity}
As soon as the activity times out, UI performance returns to normal. Until that point it is very sluggish. I have no code that I am aware of that could be blocking the main thread, and I've even gone so far as to comment out my entire onPause() method to see if it makes any difference, and it does not.
The Activity does not spawn any background threads, does not perform any network activity, the only disk access it has is some accessing of SharedPreferences. The previous questions I've been able to locate are about idle timeouts for HistoryRecord, not ActivityRecord.
Any ideas what would cause this? Or how I could go about determining what is blocking the UI thread, if that is what is happening?
EDIT : Okay, just tried commenting out everything except super.onCreate() and setContentView() -- the problem still persists. It doesn't occur with any other Activities but this one, but there's NOTHING TO this one. :/
Oh geez. One of those things that's pretty hard to diagnose outside of trial and error, but I've figured it out. For reference, should anyone else have this problem, it came down to a custom view in my layout. I had added a ViewTreeObserver.OnGlobalLayoutListener() to do some layout modifications after the layout pass, but within that listener I modified the layout and thus caused another layout, essentially creating an infinite loop (but somehow not causing an ANR). My solution was like so:
private class BoardLayoutListener implements OnGlobalLayoutListener {
#Override
public void onGlobalLayout() {
//...do stuff here
//REMOVE this listener so that you don't repeat this forever
ViewTreeObserver obs = SudokuBoard.this.getViewTreeObserver();
obs.removeGlobalOnLayoutListener(this);
}
}
This solution is quite ironic, considering my second highest rated answer on StackOverflow specifically deals with this. :P
sigh
I've had the same issue today but as it turned out to have a different cause and solution I decided to add the information here just in case it might help someone else.
In my case problem was caused because I had the following line inside my onActivityResult() method:
android.os.Debug.waitForDebugger();
I Just deleted the line and the problem was gone.
This line is usually used to synchronize the debugger with the OS threads but I just figured it shouldn't be used anywhere. Oddly the problem would not appear until I had my phone disconnected from the desktop.
Regards
In my app I needed to call findViewbyId() from both onCreate() and from WebChromeClient.onCompletion(). To avoid findViewbyId() returning null I resorted to calling Activity.setContentView(int viewResID) before calling findViewbyId().
It works, but now I am wondering whether I may have created a "time-bomb" in my code down the road.
Are there any caveats that I need to keep in mind when doing something like this?
There is no problem in doing so. You have to reinitialize references (every findViewById needs to be called again) and it might be troublesome if you do it A LOT of times, but it is not a time bomb at all.
My app may launch a sub-activity for a specific purpose. When that activity finishes, I get the results in onActivityResult. These results are then processed in the subsequent onResume. This consists of a setContentView and also starting an AsyncTask that puts up a ProgressDialog.
This all works well when initiated the normal way, which is via a user request (i.e., menu selection) after the app is up and running. However, under some conditions I need to do this right as the app is starting up, so I initiate this sequence right from my onCreate. What then happens is that I get fatal ResourceNotFound errors within any o/s call that implicitly calls the layout inflater. I got around this with setContentView by pre-inflating the view in my onCreate method, but the AsyncTask's onPreExecute still fails on ProgressDialog.show() as it "fails to find" Android's own progress_dialog.xml!
Anyone know what's happening here?
I suspect it's something to do with the timing, where this is occurring before the main activity has even had a chance to display its screen. These calls are all being made on the main UI thread, but maybe something hasn't completed within the o/s under these conditions.
As a closeout, the problem turned out to be totally unrelated to what I described in my post. Turns out it was due to blindly using some code that had been posted in some online forum showing how to get and use AssetManager. Trouble is, at the end of the block of code he had put "assMan.close()". Well, this closes the asset manager for the entire activity and resources can no longer be accessed!
It took a while to find it since it was not something that I did via my own understanding.