Android - Architectural Decision

Background

I am writing an application which has two distinct functions.

1. Load a GPX file and direct the user to follow the route defined in the file, by pointing the correct direction of travel and distance. Then marking the waypoint as reached and selecting the next as and when necessary.
2. Display the route on the standard maps widget.

Current Thinking

My current design is to have three tabs: menu, location, map. Where menu is used for loading the gpx file and amending settings; location gives the current location and direction to travel; and maps is of course the map widget with the route overlay.

So this gives four activities (the main app, and the three tabs).

I am going to need some routine to take the current location and apply logic to it to work out the current best position. Another routine to keep track of the route and what waypoints have开发者_运维百科 been met. My thinking is to have two separate threads (one for location,one for route tracking) spawned from the main activity which have methods which can be called by any of the activities e.g. get position. The route tracking should also use some callback mechanism or event mechanism to inform the UI when a waypoint has been reached.

This way the user interface can update as and when needed, but also responds to events driven from the location data.

Question

Does this seem a sensible set of decisions or is there something I haven't considered which will take me by surprise. Writing for a mobile phone is significantly different to my usual fare (having a UI makes a big change).

It might make more sense to have the location and route tracking logic implemented as bound services, rather than as threads spawned by one of your activities. See the Services guide topic for more info on how to set up and use a Service in your application.

Other than that, your approach seems pretty sound to me.