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