I downloaded the app, but I couldn't get it to crash, sorry. But I
did a clean install.
What a did notice, though, was how it only loaded the bus routes (from
the web?) the first time around. Even after I killed the app and
relaunched it, the bus route list was populated without loading. So
you must be storing them locally, is that right?
Not too sure what I am asking here, if you have the previous version
of the app, I'd try to duplicate the problem by pushing the old
version followed by the new one using adb, simulating an upgrade
process.
On Aug 30, 12:07 pm, TreKing <treking...@gmail.com> wrote:
> 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
