date rollover issues - maybe.

[GoogleCodeExporter]

I have noticed that the date rollover is sometimes not noticed by the
application. I am not certain as to the exact preconditions, for example if
it depends on the time zone or other factors. But roughly, you have to do
the following:

What steps will reproduce the problem?
1. Look up the coordinates for the day in the hashdroid. 
2. "Close" the app, leave the phone running. Wait until the next day.
3. Open the app. The date display should automatically have switched to the
next day. However, after confirming, no query to the coordinate server
takes place, nor has the geohash location switched to the next day.

What version of Geohash Droid are you using?  On what phone?
latest marketplace version currently on HTC G2. 

Please provide any additional information below.
It might have confused these people too:
http://wiki.xkcd.com/geohashing/Talk:2010-01-22_42_-89

Original issue reported on code.google.com by thomas.h...@gmail.com on 30 Jan 2010 at 11:46

[GoogleCodeExporter]

Workaround:
If it happens, you can force the loading of the proper coordinates by fetching 
the
coordinates for a different day first, then explicitly setting the date display 
back
to the current day.

Original comment by thomas.h...@gmail.com on 30 Jan 2010 at 11:50

[GoogleCodeExporter]

I've had this happen a few times during testing, too, but I thought I nailed 
that bug
a while back.  I'll have to look into it a bit more.  Though I found that 
changing
the date on the main screen, then setting it back to today, should force it to
understand the current day, like Thomas said.

Original comment by captains...@gmail.com on 30 Jan 2010 at 5:38

• Removed labels: Component-Location, Milestone-Release0.7

[GoogleCodeExporter]

After doing some more testing, it looks like the wrong date is being sent to
StockGrabber in the main GeohashDroid class.  That is to say, the DatePicker 
widget
looks like it's not giving us the same date and time in the backend that it 
says it
is in the GUI, under these circumstances.  Meaning, if the date is changed 
between
executions of GHD, the widget will update what it looks like, but it won't 
update
what it reports until the user changes the date (or the app is somehow made to 
ignore
it, like by pressing Back from that screen).

This either means I'm not using that widget properly somehow, or there's a bug 
in the
widget itself.  However, I may have a workaround.  Maybe.

Oh, and apparently this bug doesn't happen on the small screen sizes.  I'm 
using a
custom widget there so that it'll all fit, and that's working properly.

Original comment by captains...@gmail.com on 30 Jan 2010 at 6:38

[GoogleCodeExporter]

I just saw this on my Motorola Droid where even hitting back, loading different
coords, and flushing the stock cache didn't help.  The only solution was to 
power
cycle the phone.

Original comment by jste...@gmail.com on 29 Apr 2010 at 2:33

[GoogleCodeExporter]

I'm going to have to look more into the DatePicker class to see if I can fix 
this.  Or 
maybe write a new DatePicker so I know what's going on under the hood with it.

Original comment by captains...@gmail.com on 29 Apr 2010 at 3:25

[GoogleCodeExporter]

Hey, sweet!  Checking over the actual Android API source code, I did indeed 
find the
bug, and it was pretty well what I thought.  DatePicker has a bug in it that 
causes
it to not restore itself properly after the application's been "closed".  I'll 
file
an issue over there, complete with a patch (it's a one-line thing).

Though this doesn't fix the problem immediately.  I'm still looking into just 
how
much I'd have to do to re-implement DatePicker or something like it in case they
don't feel it's worth fixing or the fix could be a long ways off.

Original comment by captains...@gmail.com on 30 Apr 2010 at 2:50

[GoogleCodeExporter]

Got it!  As per SVN revision r395, I've got a workaround in the main 
GeohashDroid
class which should force the DatePicker to update any time it shows up, which 
should
get around this bug.  I'll get another pre-release out soon that has this fix 
in it.

Original comment by captains...@gmail.com on 3 May 2010 at 5:06

• Changed state: Started

[GoogleCodeExporter]

Version 0.8.0-pre2 is now available.  This preview release just works around 
the date
rollover bug.  A patch has been submitted to the Android project to solve this 
on an
API level, too.

Original comment by captains...@gmail.com on 4 May 2010 at 5:20

[GoogleCodeExporter]

The patch has been accepted and should be in the API sooner or later.  In the
meantime, I also released 0.7.5 to the Marketplace, which has the workaround 
(and a
bunch of other bugfixes.  Enjoy!

Original comment by captains...@gmail.com on 6 May 2010 at 3:54

• Changed state: Fixed