Thanks for the continued help.
On Fri, Aug 27, 2010 at 2:22 PM, Dianne Hackborn <hack...@android.com>wrote:
> The first thing I would look for is any code writing data that could cause
> problems if it was killed in the middle of executing.
That makes sense, but that's also why I'm confused. The main issue I've had,
for which I have nearly 30 reports now in each version of my app in the dev
console, has nothing to do with data access. Unless I'm really missing
something.
I have a base class reference that should be set to the appropriate instance
of a derived class type based on user selection.
These derived type instances come from a manager class, of sorts, that holds
the instances. There is one static instance of this manager class in the app
since it's global, constant data. So it should be initialized, along with
it's internal data it manages, at all times. None of this involves any data
access.
Some pseudocode if it helps:
// In "Manager" class
public Manager
{
private Map<String, BaseRef> refs = null;
public Manager()
{
refs = new TreeMap<String, BaseRef>();
// Explicitly add derived instances of BaseRef
refs.put("Key", new DerivedInstance());
// add more ...
}
public BaseRef get(String key)
{
return refs.get(key);
}
}
//In Static access class
public StaticClass
{
private static Manager manager = new Manager();
public static Manager getManager() { return manager; }
}
// Then, finally, in the class where the crash occurs
BaseRef baseRef = StaticClass.getManager().get(userSelection);
"Userselection" is the value chosen by the user from a list pre-populated by
the Keys in the Manager class to begin with.
So if the user was able to make the selection, the key was there at the
start of the Activity, and in the manager where it originated from.
baseRef, which is obtained from that single manager's list (which is
essentially hard-coded), is later used elsewhere and ends up being null.
There is no file data access involved anywhere in this Activity besides
using SharedPreferences for exactly one option.
Also, now that I've typed this out, this goes against the idea that statics
are the problem since I would have had the null pointer at the point where I
try to access the Manager class. Instead, it appears to be valid but for
some reason its internal data, which is set on construction, is not.
It's worth noting that I've seen this problem to a lesser extent before I
added this manager class stuff, but since adding it last week, the problem
seems to have exploded with a fury. But again, not sure if that's a result
of a larger user-base over two months since last major update.
I think at some point I'll start polling my users to see how many of them
continue to see the issue after updating. Since I've instructed them, in
nice big letters, to try uninstalling first, I expect not to hear any more
complaints for now, but I'd rather fix the problem than band-aid it like
this.
-------------------------------------------------------------------------------------------------
TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago
transit tracking app for Android-powered devices
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
