GeoHunter 1.9.1

[Anders Petersson]

I've uploaded GeoHunter 1.9.1 to the webpage:

http://code.google.com/p/geohunter/downloads/detail?name=geohunter_1.9.1.apk

It contains all work from Ville's waypoint branch and some minor improvements. I have made Project waypoints create a new waypoint instead of a geocache.

There's still some small things I'd like to get done before publishing it but I might push this version anyway unless I hear of any bugs with the preview version. I'm going on a week of vacation now.

/Anders

[Jason Blauert]

Am I the only one getting an Error?

I uninstalled my working version (from Ecplise) and installed from the
link provided. Seems to download and install correctly, but I get a
"stopped unexpectedly. Please Try Again" error as soon as I try to
open it.

Uninstalled again and reinstalled ... same thing.

On Aug 22, 4:50 pm, Anders Petersson <and...@gmail.com> wrote:
> I've uploaded GeoHunter 1.9.1 to the webpage:http://code.google.com/p/geohunter/downloads/detail?name=geohunter_1....

[Jason Blauert]

Is this what you need to see from Eclipse when it fails

08-22 22:01:39.183: INFO/ActivityManager(1082): Start proc
org.geohunter for activity org.geohunter/.activity.main.MainActivity:
pid=6625 uid=10032 gids={3003, 1015}
08-22 22:01:40.112: INFO/geohunter(6625): FilterTypeCollection first
setup
08-22 22:01:40.120: DEBUG/AndroidRuntime(6625): Shutting down VM
08-22 22:01:40.120: WARN/dalvikvm(6625): threadid=1: thread exiting
with uncaught exception (group=0x4001d7e0)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): FATAL EXCEPTION: main
08-22 22:01:40.167: ERROR/AndroidRuntime(6625):
java.lang.RuntimeException: Unable to start activity
ComponentInfo{org.geohunter/org.geohunter.activity.main.MainActivity}:
java.lang.ClassCastException: java.lang.Integer
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
android.app.ActivityThread.performLaunchActivity(ActivityThread.java:
2663)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:
2679)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
android.app.ActivityThread.access$2300(ActivityThread.java:125)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
android.app.ActivityThread$H.handleMessage(ActivityThread.java:2033)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
android.os.Handler.dispatchMessage(Handler.java:99)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
android.os.Looper.loop(Looper.java:123)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
android.app.ActivityThread.main(ActivityThread.java:4627)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
java.lang.reflect.Method.invokeNative(Native Method)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
java.lang.reflect.Method.invoke(Method.java:521)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
com.android.internal.os.ZygoteInit
$MethodAndArgsCaller.run(ZygoteInit.java:868)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
dalvik.system.NativeStart.main(Native Method)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): Caused by:
java.lang.ClassCastException: java.lang.Integer
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
org.geohunter.activity.filterlist.FilterPreferences.getString(FilterPreferences.java:
75)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
org.geohunter.GeocacheFilter.loadFromPreferences(GeocacheFilter.java:
124)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
org.geohunter.GeocacheFilter.<init>(GeocacheFilter.java:105)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
org.geohunter.activity.filterlist.FilterTypeCollection.firstSetup(FilterTypeCollection.java:
63)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
org.geohunter.activity.filterlist.FilterTypeCollection.load(FilterTypeCollection.java:
31)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
org.geohunter.activity.filterlist.FilterTypeCollection.<init>(FilterTypeCollection.java:
20)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
org.geohunter.activity.main.MainActivity.onCreate(MainActivity.java:
91)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:
1047)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): at
android.app.ActivityThread.performLaunchActivity(ActivityThread.java:
2627)
08-22 22:01:40.167: ERROR/AndroidRuntime(6625): ... 11 more
08-22 22:01:40.167: WARN/ActivityManager(1082): Force finishing
activity org.geohunter/.activity.main.MainActivity
08-22 22:01:40.675: WARN/ActivityManager(1082): Activity pause timeout
for HistoryRecord{44aa6bc8 org.geohunter/.activity.main.MainActivity}

> > /Anders- Hide quoted text -
>
> - Show quoted text -

[Anders Petersson]

Thanks for the report, Jason. I see now that I made a simple mistake that causes new installs to crash. I've uploaded 1.9.2 that fixes the problem:

http://code.google.com/p/geohunter/downloads/detail?name=geohunter_1.9.2.apk

Sorry for the inconvenience

/Anders

[John Drake]

I noticed what I think is a bug, which resulted from the waypoint branch merge: when attempting to create a projection from a waypoint, the coordinates of the geocache are used as start coordinates instead of the waypoint coordinates.

I am currently testing a patch for this behaviour, which I will send out later.

Cheers.

[Marek Hladky]

I think all actions on "Compass" tab (rmaps, edit,..) works with cache
itself not the waypoint.

Marek

[Ville]

You're both right. Selected waypoint has not been considered in the
compass-view actions. But it's kinda understandable since waypoints,
rmaps and cache projection each were developed at the same time. Anyway
this issue needs to be addressed. I'm not sure if the projection will
support waypoints. I haven't taken a look at the code. Editing should be
straight forward to change so it edits the selected waypoint. And I'd
imagine Rmaps is also quite simple.

There are now selected geocache and selected waypoint in GuiState when
waypoint is selected. That's way by default the parent cache is used
wherever it has not been explicitly corrected to handle waypoints.

I'll try and take a look at the edit for starters if I have time.

Ville

[Ville]

Hi again.

Turns out, it's not that straight forward to implement waypoint support
for said menu actions. Since CacheActions act method takes a Geocache as
an argument we'd need to change it to take in GeoObject to support
waypoints. But most CacheActions are purely for geocaches and not for
Waypoints. That doesn't feel good, but I guess is needed to in order to
support waypoints for some CacheActions.

Anyone have any better ideas?

Ville

p.s. I guess radar-will also show parent cache even if waypoint is selected.

[John Drake]

On Aug 24, 2010, at 19:20, Ville wrote:

> Anyone have any better ideas?

Here is an initial patch for the waypoint projections, although I have not yet thoroughly tested it.

If it works, it may be feasible to use the same approach in the other areas.

[John Drake]

I was getting an FC when processing some gpx files. The attached patch seems to (at least superficially) solve the problem.

Apparently in some cases, the parent of a waypoint was Null. I simply added a check for this.

Cheers.

[Anders Petersson]

How about changing

public interface CacheAction {

    public void act(Geocache geocache);

}

to

public interface CacheAction {

    public void act(Geocache geocache, Waypoint waypoint);

}

Each CacheAction can decide if to act on the waypoint (if it is != null).

/Anders

[John Drake]

That works for me too. When I created my patch, I didn't think that a lot of other actions would need this.

Cheers.

[Ville]

Sounds reasonable. The Johns way wouldn't have worked for edit cache since the edit can be triggered straight from the cachelist and it shouldn't matter if waypoint is selected or not.

But adding Waypoint to act might just do the trick. What about

public interface CacheAction {
   public void act(Geocache geocache);

   public void act(Geocache geocache, Waypoint waypoint);
}

So you don't have to edit every class that calls act(Geocache). First being equal to act(cache, null).

Ville

[Ville]

Ok, there was like 3 or 4 places where the act(Geocache) was called, so maybe it's not worth changing all the actions. =)

Ville

[Ville]

So I did the change that Andres proposed to the CacheAction and committed it to trunk.

I also fixed the EditAction and changed the EditActivity to use the Waypoint.ID-way (the Johns way in the patch) instead of the EditActivity.TYPE_KEY / WAYPOINT_TYPE since it was cleaner and easier way to differentiate between editing caches and waypoints.

I guess remaining thinks to fix are:
 - Projecting from waypoint (Johns patch with little modifications)
 - Opening rmaps
 - Opening radar
 - Navigate

Ville

[Anders Petersson]

Perfect.

I've fixed Navigate, RMaps and radar.

/Anders

[John Drake]

I'm working on the waypoint projection. :-)

[Anders Petersson]

I don't know what was going on here. I've just committed your work-around.

/Anders

[John Drake]

Here's my patch for the waypoint projection. I've added two additional items:

1. The projection description will get the description of the waypoint, not the original cache, if it is a waypoint which is being projected.

2. After projecting a waypoint, the compass is set to the projected waypoint. (Diff for MainActivity.java)

This will save time in most cases, because the user normally wants to immediately navigate to the projection (although not always).

It has the disadvantage though of being perhaps surprising behaviour for the user. Someday I may add a user choice for this.

In the meantime, feel free to ignore item #2, if you are uncomfortable with committing it.

Cheers.

[Ville]

I think this may have to do with the fact that when loading a Waypoint, GeocacheFactory.getFromId(id) is used to get the parent cache. getFromId simply returns a cache from memory and if said caches has not yet been loaded, it returns null.

This isn't normally a problem since you can only get access to a Waypoint through a parent cache => the parent cache is always loaded when getting caches. But when you update caches and waypoints from gpx, the caches are not stored in memory. So the parent ends up null.

Which would be better fix?
 - To load the geocache from db in GeocacheFactory if it isn't in memory (DBFrontend needs to be passed to GeocacheFactory)
 - Check if wp has null parent and load and set the parent in DBFrontend.loadWaypointFromId. (Wp needs to have setter for parent).

Or is there some better way anyone can think?

Ville

[Anders Petersson]

Thanks for the explanation Ville.

In fact, the parent Geocache object isn't really needed in the waypoint. I have changed this so Waypoint only contains the id of its parent and reverted the one-line fix from John.

(One reason to keep the object reference would be to save memory)

/Anders

[Anders Petersson]

Ok I've committed it all. Haven't tested though...

/Anders

On Aug 25, 2010, at 21:58, Anders Petersson wrote:

[John Drake]

On Aug 25, 2010, at 21:58, Anders Petersson wrote:

> I've fixed Navigate, RMaps and radar.

Did you commit this? Currently when I choose a waypoint, and then choose the radar, I still seem to get the coordinates of the main cache.

Cheers.

[Anders Petersson]

Yes I committed it but apparently some more changes were needed. Try now. :)

/Anders

[John Drake]

On Aug 27, 2010, at 21:57, Anders Petersson wrote:

> Yes I committed it but apparently some more changes were needed. Try now. :)

Thanks, that works much better. :-)

By the way, I'm working on two things right now:

1. Direct selection of waypoints from the compass tab. (Almost finished)

2. In the details tab, a warning dialog before a waypoint is deleted. (While testing, I accidentally delete a waypoint which I meant to select.)

Cheers.

[John Drake]

I've attached a patch which will prevent clumsy people like me from deleting Waypoints by accident (which I have already done). :-)

The patch adds a "quick and dirty" alert dialog to confirm the delete operation. As such, you may not necessarily like the style of the change. I'm open to suggestions.

Cheers

[John Drake]

The attached patch adds a "Waypoints" button to the compass tab. When the user selects it, the device displays a single select alert dialog (radio buttons) containing all the related waypoints. The user can then select one of the waypoints from the list and immediately view it on the compass tab.

I have found this to be a rather convenient method of navigating from one waypoint to another.

The patch also contains the waypoint deletion warning, which I submitted previously, as both patches make use of some of the same code.

Cheers.

[Gordon McDorman]

Please ignore the last patch which I sent: I forgot a file. ;-)

This patch should be better. :)

Cheers