If gears fails (a user can decline access), script should fallback to other methods.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use browser with both Gears and navigator.geolocation
2. Decline access from Gears
3. Script will fail

This is because of the if/else chain in the script. It may be better to use
a method like so:

if (!tryGears() && !tryNative() && !tryXXX())

function tryGears(){
if !has gears return false
if gears fails return false
}

That way the script will still go down the list if one of the methods fails.

Original issue reported on code.google.com by cezs...@gmail.com on 4 Jan 2010 at 7:26

[GoogleCodeExporter]

just out of curiosity, is gears given preference to the native function because 
it
has a higher accuracy level?

& it may be better to do this:

function getCoords(){
   return tryGears() || tryNative() || tryXXX() || false;
}

which will just go down the line and return whatever is not false/null.

Original comment by cezs...@gmail.com on 4 Jan 2010 at 7:31

[GoogleCodeExporter]

this an interesting point. fallback to a different method if one fails. do you 
think
that is realistic? if a user denies google gears he might grant a different 
method
the permission? not sure if that is really a likely scenario.

regarding the order/preference. do you think we should try to use
navigator.geolocation first and then google gears? never thought about that so 
far

Original comment by whoiss...@gmail.com on 4 Jan 2010 at 8:39

[GoogleCodeExporter]

if your application only wants the location, it's more clear when a message 
pops up
stating exactly what the purpose is:
"X wants your location"
is more understandable than
"X wants to enable Gears"

but in either case, falling back to other methods can't hurt if its checking
silently. you'd just need to break the if blocks into functions that return 
false.

im not sure on the order of preference. i'd say stick with the native function,
unless Gears is known to be more reliable or accurate when both are available. 
which
is unlikely.

Original comment by cezs...@gmail.com on 4 Jan 2010 at 9:28

[GoogleCodeExporter]

i havent tested yet-- can we count on the prompts (enable gears / give 
location) to
block script when waiting for a response?

Original comment by cezs...@gmail.com on 4 Jan 2010 at 9:30

[GoogleCodeExporter]

i like your rationale for putting native first makes sense, "enabling gears" is 
not
the most intuitive way of asking the user. i will flip the order.

re: blocking and counting prompts, i think it never really blocks, they are all
callback methods and counting prompts could be done.

re: fallbacks in case of a decline would be a major change. let me think about 
that.
i just don't want to over engineer the library for a potentially rare user 
behavior,
most people i know including me wouldn't have a pref for a location provider.  

Original comment by whoiss...@gmail.com on 4 Jan 2010 at 9:50

[GoogleCodeExporter]

how about an array of checks? this would allow extending the script. when a 
service
failed, it could call a function that just ran down the array.

try this code and decline native when your browser prompts you:

var checkOrder = ['dummy', 'native', 'gears', 'dummy'];

var check = {
    'native':function(){
        console.log('trying native');

        // If we don't have the capability, runNextCheck() will automatically try the next
feature
        if(!navigator.geolocation) { return false; }

        // Start running non-blocked call to getCurrentPosition. Notice runNextCheck in the
error callback here,
        // this is to continue down list on failure
        navigator.geolocation.getCurrentPosition(successCallback, runNextCheck);

        return true; 
    },

    'gears':function(){
        console.log('trying gears');

        // Let's assume we have Gears and it worked
        return true;
    },

    'dummy':function(){
        console.log('trying dummy');
        return false;
    }
};

function successCallback() { }

function runNextCheck(){
    if (checkOrder.length > 0 && !check[checkOrder.shift()]()) { runNextCheck(); }
}

runNextCheck();

another advantage of putting the checks in a chain like this is that someone 
could
put less accurate geolocation toward the end, maybe IP based? i might still 
want to
know what city someone is in based on a IP lookup service if the more accurate 
type
has failed. in this case, it'd also be handy to know how accurate the reading
probably is, or atleast which service was eventually successful.

Original comment by cezs...@gmail.com on 4 Jan 2010 at 11:45

[GoogleCodeExporter]

how would that look from a user perspective? if he doesn't want to ask he 
potentially
would have to decline many times? wouldn't that be a bad user experience?

Original comment by whoiss...@gmail.com on 5 Jan 2010 at 12:19

[GoogleCodeExporter]

thats true! i guess i'm assuming different points of failure-- if geolocation 
fails
for gps, TIMEOUT, POSITION_UNAVAILABLE, or whatever other miscellaneous 
problems each
interface has.

PERMISSION_DENIED returned from getCurrentPosition could always just stop the 
chain
by itself. just dont call the runNextCheck() function again.

things like Yahoo's Fire Eagle may be easy to drop in with this technique, and 
one
could easily remove something from the chain if they wanted to for some reason.

Original comment by cezs...@gmail.com on 5 Jan 2010 at 3:11

[GoogleCodeExporter]

one more advantage to having an array of tests is that you can (and should 
possibly?)
make an initial pass to determine which capabilities the browser has.

foreach (checkOrder) {
if the browser lacks the capability, remove element from array
}
return checkOrder

this would allow us to perform UI-level logic based on the users capabilities. 
i may
want to show a button only when the user is geolocation-able, etc.

Original comment by cezs...@gmail.com on 6 Jan 2010 at 9:04