On Sun, Aug 29, 2010 at 8:24 PM, William Ferguson <william.ferguson.au@
gmail.com> wrote:
> What's the taskAffinity?
>
Whatever the default is - I've never touched this.
I suspect that clearing the data is changing the behaviour because this
> speed up / slows down one of the threads, thereby (generally) avoiding the
> race condition.
>
I have a feature that auto-backs up all user data to the SD and restores it
if the local data file is gone. So even if they clear the local data, it's
restored on the next app start up. So regardless, all user saved data is
there before and after they clear the app's local data storage to alleviate
the problem.
And the crash does not occur in the first activity, where data is usually
loaded. I say usually because it's lazy-loaded (so if the user navigates
away from the second activity and comes back much later, it's possible the
memory got wiped). But this occurs in onCreate in the main thread of the
second activity, and this activity does not try to do anything with the user
data until after the point at which the crash occurs.
> I'd be tempted to
> 1) synchronize the method
>
Probably a good idea, I'll be doing that =)
> 2) make the static instance an instance of your Application class.
>
I started using a custom Application class a while ago and quickly got tired
of having to cast up each time I needed to do something with it. I'll try a
better implementation of a Singleton first.
On Mon, Aug 30, 2010 at 6:16 AM, Zsolt Vasvari <zvasv...@gmail.com> wrote:
> I think what's happening then is that some kind of race condition corrupts
> your app data, after which the crash will occur every time.
>
But the main activity that starts up and loads the user data each and every
time does not crash, and the point at which the crash happens is NOT using
user data - it's using a hard-coded reference which is explicitly set in
code. That reference, somehow, ends up being null, even though previously it
was (probably) used in the user-data loading process. WTF!?
> - It started to happen after you introduced static maps.
>
Weird stuff after updating like this has happened before, though this time
it's much more widespread and consistent.
Also, note that the map itself is not static: there is a static instance of
the class that contains a map. Don't know if that makes a huge difference,
but it's worth pointing out.
> - You admit using such maps in multiple threads
> - java.util.TreeMap is not thread safe.
>
Yes, but the map is initialized ONCE in the main thread and never altered
again. I'm not adding or removing anything from it at any other point. It's
there strictly to get access to the pre-defined derived-type instances I
need to use depending on the user's selection. Also, no thread is started
until after this map is initialized.
> What I would do is wrap TreeMap around
> a java.util.Collections.syncronizedMap (not 100% about the name) and then
> release an updated app and see if the crashes go away. I know it makes your
> users the testers, but if you cannot duplicate it, there is not much to
> lose.
>
Indeed, anything is worth a shot at this point! I'll try that when I get a
chance and post back what I see.
IF YOU'RE REALLY BORED and want more context to the problem, you can check
out the free version of my app. From the main screen use the menu and select
"Trek Tracker" to open the second activity where the crash occurs. This
screen is series of drop downs for the user to drill down to the stop they
want bus predictions for.
The first option is the transit system - these are the hard-coded values in
the map: the strings the user sees are the keys, pulled directly from the
map, and they point to the derived type which handles the logic for getting
data for that system. All of these options are loaded in onCreate and pulled
directly from the map - if this part is working, that map should be
completely valid at this point.
Next the user selects a route, direction, and stop, each populated
dynamically based on the previous selection. Once the stop is selected,
that's all the data I need to get bus arrival predictions, so at this point
a thread is spawned with the users's selected data to load the predictions
every minute or so.
This is where the crash occurs. The background thread tries to use the
reference to the transit system it got from the very first selection, which
I swear should be valid at this point, and throws a NullPointerException. So
somehow, that reference which is EXPLICITLY set with "map.put("Key", new
Derived())", ends up being null and then only in this activity.
Thanks for the continued help folks. This is a head-scratcher.
-------------------------------------------------------------------------------------------------
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
