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?
Related
I was working on a Android App which it's main activity contains a PullToRefreshGridView showing some items. I've toggled a breakpoint on my Adapter getCount() method and for my surprise i found out that it is being called a lot of times.
I've tried setting a lot of breakpoint throughout my code, but the debug process did not stop in any of those.
Is there any method or tools that could help me find the snippet of code that is causing this ?
Thank you!
Whenever I'm writing an Android app and making a Toast, I tend to call Toast.makeText() but then forget to call show() and get mad at myself later. Since there is no reason I would ever call Toast.makeText() and not mean to call show(), is there a way I can make Eclipse show a warning if I do that? Thanks
for clarity: I want Eclipse to show a warning anytime I call "Toast.makeText(blah, blah, blah)" instead of calling "Toast.makeText(blah, blah, blah).show()".
You mean like this?
Lint warnings can do lots of handy things - page through them and see what suits you!
(Note that I've searched online for the warnings I'm describing below, and have come up with next to nothing about them.)
I'm working with API level 10. I have a preference screen (XML-based), and one of the options in there creates a custom ListActivity as follows:
PreferenceActivity contains an option that creates a...
ListActivity which is a dialog that employs...
setOnClickListener() which contains an onClick() method that (right before calling finish()) will startActivity() a new Intent...
sub-Activity which starts up an...
AsyncTask which does variable time work which when done calls...
onPostExecute() which calls finish()
The thing is, it works... but I'm getting a raft of warning starting with:
10-16 21:59:25.010: WARN/WindowManager(170): Rebuild removed 4 windows but added 3
10-16 21:59:25.010: WARN/WindowManager(170): This window was lost:.....
Curiously, this raft of warnings ONLY comes up when the task executes quickly! When I added a Thread.sleep() call to my AsyncTask to artificially inflate its runtime it worked and threw no warnings whatsoever. In fact, as long as it takes more than (roughly) 500 ms to run it works fine. (Note that I tried using startActivityForResult() to no greater effect - the same problem occurs.)
The goal is that the user selects a preference item, they change its setting, some processing takes place, and then the user is left back at the preference menu they started on.
I'm betting it's a race condition... the order in which the windows are destroyed varies depending on that run-time... and I get the impression that when the sub-Activity closes before its parent ListActivity the warnings get thrown. But sprinkling a 1s sleep() in isn't a reasonable solution unless this is some sort of Android bug (unlikely, but then again I've reproduced a couple of those today already).
So, what's the flaw in this my that leads to this stream of warnings? It'd be nice to say "on preference, do this, then do that, then finish" but I think what I'm doing is the equivalent. Maybe not... thoughts?
Edit: I decided to try doing this ListActivity as a custom Dialog... that was one of the more painful things I've tried to do lately (getApplication() doesn't work and lots of other things seem to go wrong... it may be inexperience to some extent, but dialogs really weren't meant for this either...
Try the following two things:
Dismiss your dialog before calling finish() on its parent activity (PreferenceActivity).
Make sure you are starting your AsyncTask later in the sub-activity's lifecycle. I'm specifically thinking you should launch it in onResume().
My best guess is that the AsyncTask is calling finish() on the sub-activity, before the sub-activity has had a chance to fully start up. Why that would matter? I'm not sure. Something to try though. Good luck!
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.
Hoping someone can assist with this what seems to me a peculiar problem.. My mind is pulsing a little here as it's blown my understanding of the Android Activity Lifecycle.. Let me try to make things clearer.
Problem: I'm receiving a 'StaleDataException' during the 'getView' method of a custom adapter (extending BaseAdapter) that I use on an activity to populate a GridView. Sounds straight forward so far.. When I first go into the activity, the adapter is working as expected and the grid is populated.
I have a button on the activity which fires off an Intent to allow the user to take a photo, and comes back via 'onActivityResult' saving the image to a database. This all worked also. In fact I wrote that portion first, then added the adapter & gridview afterwards.
Now the StaleDataException is occuring when I've gone to the camera to take a pic, and then click OK to return... I have lots of Log statements in most events on my activity, and very bizarrely the StaleDataException is occuring before ANY of these events are triggered... before OnActivityResult/OnResume etc.
SO I'm quite confused as to why the Adapter is being accessed before I've properly returned to my activity and before onActivityResult/OnResume have been called..
Debugging the steps that lead up to the exception, it all occurs on this line :
String contentType = dataCursor.getString(dataCursor.getColumnIndexOrThrow(DbStatics.ACCIDENTS_MEDIA_KEY_TYPE));
What's also baffling me is the dataCursor is actually Open and the first call (getColumnIndexOrThrow) is also returning a value.. so its the getString() which leads to the exception.
So I hope that's clear enough... and really really hope someone might be able to shed some light on what's going on..
Many Thanks,
I recently encountered exactly the same problem in almost exactly the same scenario.
(I'm using a Gallery rather than a GridView)
In my case, my code worked fine for months - until I recently updated my N1 to 2.3.
My solution (after much brain pulsing of my own) was to not call startManagingCursor on the cursor I pass in to my adapter.
Instead, I manage the cursor myself.
That seemed to clear the problem up for me....though I couldn't tell you why...maybe someone more experienced can shed some light.
Hope this helps you.