I would bet any money that this is very clearly going to be a race
condition somewhere. Your code using a static Map and the user
symptoms are a dead giveaway.
I think the install/reinstall and clearing the user data are red
herrings. The app might work again for the user if they just ran it
again.
On Aug 27, 4:40 pm, TreKing <treking...@gmail.com> wrote:
> 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
