I didn't really want to use global variables but I couldn't find a place to put a non-static member that would be accessible from TrackManager, TracklistAdapter, TrackDetail and DataHelper. Is there a better way?

Thanks, I'll have a look tomorrow it's bed time for me ;)

For the GPS the emulator has controls to simulate GPS events either via the command line or DDMS. It's a bit rudimentary but it beats walking in the snow.

That doesn't look too bad for a first shot at Java ;) The most problematic parts are:

• Storing of data inside the DataHelper class. I don't think that's necessary because when you need the statistics of a track you're always in a context of a single track, so you can just build a new TrackStatsitcs object for you track and use it
• Copying of OSMAnd code, I'd prefer if we just their library directly unless there's a good reason not to.

Thanks for replies! The rest was quite obvious.
If you'd like mo to rely upon osmand, can you please tell me step by step how to do this? Because I have no idea :)

Here's a new version. I don't really like that TrackManager and TrackDetail don't share TrackStatistics, it causes an unnecessary delay upon opening details for a long track. Is there a way for TrackDetail to have a reference to TrackManager who created it? This way, I could use TrackManager's getTrackStatistics() similar to what I now do in TracklistAdapter. TrackDetail appears to be created indirectly through Intent so I don't know how to pass a parameter to it.

Hi Nicolas, how're you doin'? :)

I've found a way to share data between TrackManager and TrackDetail spawned by it. Actually it's the same way you pass the track ID to TrackDetail, I just pass total distance, total time, etc. along with it. With that, I'm totally satisfied with everything, but are you satisfied with the code?

Sorry I'm lacking the time to review the code, I'll try to get back to it as soon as I can.

I think that looks pretty good, it's just the dependency between TracklistAdapter and TrackManager that concerns me a bit. Since it's all cast at run-time, it would be easy to miss when calling TracklistAdapter from somewhere else.

Perhaps the map of statistics could be passed in the constructor of TracklistAdapter instead, when we create it there ? It has the benefit of making the dependency explicity: "If you want to use TrackListAdapter, you have to provide a map of track statistics".

Perhaps the map of statistics could be passed in the constructor of TracklistAdapter instead, when we create it there ?

Yep, only I encapsulated the map into a new class to avoid duplicating the code of what is now TrackStatisticsCollection.get

C'mon you can do this, it's so close! Let's do this in the name of the free software movement!

This PR could be the reason to close #38 ? :)