[TIMOB-1386] Android: Add property to allow Geo to not be paused in onPause

GitHub Issue	n/a
Type	New Feature
Priority	Medium
Status	Closed
Resolution	Fixed
Resolution Date	2011-04-17T01:56:02.000+0000
Affected Version/s	n/a
Fix Version/s	Release 1.6.0 M07
Components	Android
Labels	android, feature, release-1.6.0
Reporter	Don Thorp
Assignee	Don Thorp
Created	2011-04-15T02:51:00.000+0000
Updated	2011-04-17T01:56:02.000+0000

Description

The default behavior is to preserve battery and pause listeners when they're not being used. If the geo listener is registered at the app.js level and another Activity, even within the same app, causes an onPause event the location events won't fire.

Attachments

File	Date	Size
test_js_files.zip	2011-04-15T02:51:01.000+0000	3233

Comments

Opie Cyrus 2011-04-15

(from [a056f7f7a3a0ddd7ffb6c79e75a3f85cfa15e040]) [#1386 state:fixed-in-qa] full refactor of Geolocation module

refactor of geolocation module in order to streamline logic and support manual handling of pause / resume events and the addition / removal of location and heading events. Updated geolocation example in KS to handle the
pause / resume events so that the location and accelerometer events are not forced to run in the background. Moved out Android OS Location integration to a separate helper in utils. Cleaned up Gesture and Accelerometer modules to be in line with the Geolocation. https://github.com/appcelerator/titanium_mobile/commit/a056f7f7a3a0ddd7ffb6c79e75a3f85cfa15e040"> https://github.com/appcelerator/titanium_mobile/commit/a056f7f7a3a0...
Opie Cyrus 2011-04-15

Refactor can be verified by testing with the geolocation example in KS. Simply put, everything should still work as it did before. As the events are no longer automatically removed on pause you should see the events being manually removed when you hit back or home from the example. Same for add event and resume.

Bill Dawson 2011-04-15

Something seems to be really different. If I go to Settings - Location on my phone (2.2) and enable both wireless networks and GPS, it used to be that when I went to that KS test i could see up in the phone's notification area that it was using GPS (i.e, the antenna got turned on or whatever.) If you go back to the commit just before yours -- a8f1174 -- you can see that that is the case, though there is also a runtime error:

   E/KrollCallback( 1173): (kroll$8) [8,271771] Error evaluating source, invocation: [callMethod Geolocation.(anonymous) org.appcelerator.titanium.kroll.KrollCallback@46472e50], message: Wrapped java.lang.IllegalArgumentException: Expected 2 arguments for log, got 1 (app://examples/geolocation.js#342)
   E/KrollCallback( 1173): org.mozilla.javascript.WrappedException: Wrapped java.lang.IllegalArgumentException: Expected 2 arguments for log, got 1 (app://examples/geolocation.js#342)
   E/KrollCallback( 1173):     at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1781)
   E/KrollCallback( 1173):     at org.appcelerator.kroll.KrollMethod.call(KrollMethod.java:85)
   E/KrollCallback( 1173):     at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:1711)
   E/KrollCallback( 1173):     at script(app://examples/geolocation.js:342)
   E/KrollCallback( 1173):     at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:854)
   E/KrollCallback( 1173):     at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:164)
   E/KrollCallback( 1173):     at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:426)
   E/KrollCallback( 1173):     at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3161)
   E/KrollCallback( 1173):     at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:162)
   E/KrollCallback( 1173):     at org.appcelerator.titanium.kroll.KrollCallback.callSync(KrollCallback.java:139)
   E/KrollCallback( 1173):     at org.appcelerator.titanium.kroll.KrollCallback$1.run(KrollCallback.java:163)
   E/KrollCallback( 1173):     at android.os.Handler.handleCallback(Handler.java:587)
   E/KrollCallback( 1173):     at android.os.Handler.dispatchMessage(Handler.java:92)
   E/KrollCallback( 1173):     at android.os.Looper.loop(Looper.java:144)
   E/KrollCallback( 1173):     at org.appcelerator.titanium.kroll.KrollHandlerThread.run(KrollHandlerThread.java:73)
   E/KrollCallback( 1173): Caused by: java.lang.IllegalArgumentException: Expected 2 arguments for log, got 1
   E/KrollCallback( 1173):     at org.appcelerator.kroll.util.KrollBindingUtils.assertRequiredArgs(KrollBindingUtils.java:30)
   E/KrollCallback( 1173):     at ti.modules.titanium.api.APIModuleBindingGen$8.invoke(APIModuleBindingGen.java:300)
   E/KrollCallback( 1173):     at org.appcelerator.kroll.KrollMethod.call(KrollMethod.java:48)
   E/KrollCallback( 1173):     ... 12 more

But if I test after your commit, the first time I go into the Geo test in KS, the GPS antenna indicator does not show. If I go back to the previous screen, and then go into the test again, this time the GPS antenna indicator shows (and that runtime error above occurs).

So it seems like the GPS is not being used anymore when you first go into the test.

Bill Dawson 2011-04-15

(from [c27ef5302c68121f1252fe308e2e6eed7ae4dd34]) [#1386] In KS geo test change all Ti.API.log() to Ti.API.info() because log requires two args when only one was supplied. https://github.com/appcelerator/titanium_mobile/commit/c27ef5302c68121f1252fe308e2e6eed7ae4dd34"> https://github.com/appcelerator/titanium_mobile/commit/c27ef5302c68...
Bill Dawson 2011-04-15

My commit above fixes that runtime error -- it wasn't related to your (Opie) commit. But my underlying issue -- the change of behavior I note -- is still relevant.
Opie Cyrus 2011-04-15

I have been doing some testing on this and I am unable to reproduce the issue on my Droid 2 (2.2) the way you describe. I can reproduce the problem if I turn off both GPS and the "use wireless networks" settings.

If either GPS or the "use wireless networks" setting is enabled (or both) then the geo test works in general. There is a piece of odd behavior though that might be what your seeing. I have noticed that sometimes if I am leaving and going back into the geo test several times (seems random) I will get an error stating that the "gps is currently unavailable". Once I get this error, I am not able to get any more proper updates for GPS unless I leave KS and then come back in.

I have also noticed that sometimes when that happens if I go into the regular google maps app on my phone then back into KS things work correctly. Part of this feels like a race condition between the cold start of the GPS versus the call to register with the Location service.

Will update as I dig deeper.
Opie Cyrus 2011-04-15

After further testing, I have found that even when the GPS reports itself as temporarily unavailable when it comes back it does start sending the correct updates. In short, unless I turn off both location features I am unable to get the geo example to stop working.

Tomorrow I will try and get this on another test device and see if the behavior can be repeated.
Opie Cyrus 2011-04-15

This looks like the GPS is not yet warmed up when the provider is being selected and specified when requesting location updates. Might need to make periodic calls to update the active provider. This might also apply to the case where your original supplied provider goes away after you start listening.
Opie Cyrus 2011-04-15

(from [f9036efc1f4a524603bffb8bb5ad759667a339d0]) [#1386 state:fixed-in-qa] update geolocation module to switch providers

Updated the geolocation module to check for updated location provider with each new location update. While not a perfect solution for handling the switching of the location providers, this will allow the provider to switch based on availability without forcing the user to register again. Further discussion is needed regarding a more complete solution for handling location switching and response time. Also modified geolocation to completely decouple the TiLocationHelper / TiCompassHelper from the proxy. Updated KS geolocation example to set gps as the preferredProvider and correct a bug in the pause / resume handling of location event listeners.
https://github.com/appcelerator/titanium_mobile/commit/f9036efc1f4a524603bffb8bb5ad759667a339d0"> https://github.com/appcelerator/titanium_mobile/commit/f9036efc1f4a...
Bill Dawson 2011-04-15
tested on 2.2 device, Titanium 1.6.0 6e8d5788

With an app consisting of the attached JS files, I was able to confirm...
- That the original stated reason for this ticket is fulfilled: backing out of a heavyweight window (i.e., causing an activity pause) does not any longer "turn off the antennae", so to speak, unless you explicitly remove the "location" event listener, such as in the window's "close" event. So that works perfectly.
- That my earlier "complaint" about the behavior difference concerning GPS not getting turned on is now resolved. I checked the GPS option in Settings - Location on my phone, and indeed the GPS antenna turns on when running this test.
Gui 2011-04-15

It seems this fix introduced a new problem : I am unable to get rid of GPS in background, only if Geolocation is used with a mapView. It works as expected as long as you don't use the mapView, like in KitchenSink. But when mapView is added to a window, I can't stop GPS in background even with userLocation=false and removeEventListener('location'...) in the catched onPause event.

JSON Source