Make logging control Dialog an Android Activity

[GoogleCodeExporter]

Logging control (start/stop/pause/resume tracking etc) is currently invoked as 
a Dialog within the LoggerMap Activity. When OGT is used by other Android apps, 
these apps have to provide their own Dialog/resources to implement logging 
control.

Other components of OGT are already directly usable as Activities (e.g. 
LoggerMap and Export), Service (LoggingService) or Content Provider 
(GPSTrackingProvider).

The proposed extension is to make a new Activity lets say GPSLoggingControl. 
This activity would basically use the existing logging control Dialog. The 
existing LoggerMap could either invoke the GPSLoggingControl or both Activities 
could use the same Dialog. An added advantage is that OGT may be used without 
network. 

IMO this enhancement will make OGT even more modular and more widely usable.

Original issue reported on code.google.com by jus...@gmail.com on 22 Jul 2010 at 3:32

[GoogleCodeExporter]

Great to see you are working on this ! Possibly this can be of some help: I am 
running the latest r620 SVN version in the emulator/debugger. This is what I 
observe:

- LogCat: "WARN/OGT.GPSLoggerServiceManager(387): Remote interface to logging 
service not found. Started: false"
- this is caused by calls on GPSLoggerServiceManager.getLoggingState() called 
by several (Activity) methods like LoggerMap.moveActiveViewWindow()
- when starting the ControlTracking Activity I see all dialog options disabled 
since getLogging returns -1
- again the same LogCat" "WARN/OGT.GPSLoggerServiceManager(387): Remote 
interface to logging service not found. Started: false"

Diving into this, I think in both cases the issue is caused by the asynchronous 
nature of binding to the remote Logging service within the 
GPSLoggerServiceManager. This is because I observe that onServiceConnected() is 
called but AFTER the call to getLoggingState(). Within the LoggerMap on a 
second resume() all goes well but ControlTracking recreated/resumed each time 
so it always happens.

I think solution should be sought in making the binding process blocking, i.e. 
block until the callback onService(Dis)Connected() is called. This can be 
effected by using a wait()/notify() Java idiom. Like in 
http://tinyurl.com/3x9u2t9 

I hope this helps you out...I see you have put in a lot of work the last days.

Original comment by jus...@gmail.com on 27 Jul 2010 at 9:57

[GoogleCodeExporter]

Great idea, I was thinking of building an extension to the service listener in 
the service manager but a wait/notify is way easier to build.

Original comment by rcgr...@gmail.com on 28 Jul 2010 at 8:10

• Changed state: Fixed

[GoogleCodeExporter]

The general direction is ok. Today I experimented with a wait()/notify() as 
well but had some problems. The main issue is that the callback, 
onServiceConnected(), runs in the same (main) Thread as the Activity and thus 
the bind() request. Since wait()/notify() only works with separate Threads this 
can't be solved generically within GPSLoggerServiceManager. The Android 
examples always show an explicit continuation within onServiceConnected(). 

r625 for ControlTracking worked ok initially (the menu showed a "Start 
Tracking" option) but the solution needs some polishing. When I ran r625 in the 
debugger the dialog still showed empty options (logging state was Unknown). The 
reason is I think timing. Since the bind() is performed in 
ControlTracking.onCreate() and the potential wait() in 
ControlTracking.onResume() it worked by chance since the bind() completed 
somewhere between onCreate() and onResume().

So I moved the wait() conditionally to ControlTracking.onPrepareDialog(). Now 
the dialog works in all cases (directly and in debugger). Only in the debugger 
the wait() is hit, I think because of the timing.

See my attached version of ControlTracking.java . Also I added a maximum time 
for wait(). A "fail" dialog is still needed.

This is an interesting (nasty) issue, mainly because the onService*() callback 
comes within the same Thread as the bind(). This is not what I would expect but 
on the other hand "remote" is not really remote like over a network.

So the only way to make GPSLoggerServiceManager generic is to provide it with 
user-defined callback objects that are invoked by a wait()-ing Thread within 
GPSLoggerServiceManager.

Original comment by jus...@gmail.com on 28 Jul 2010 at 11:36

• Changed state: Accepted

Attachments:

• ControlTracking.java

[GoogleCodeExporter]

Original comment by rcgr...@gmail.com on 3 Aug 2010 at 7:05

• Changed state: Fixed