Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CADD510139 for ; Mon, 13 Jan 2014 20:28:27 +0000 (UTC) Received: (qmail 84214 invoked by uid 500); 13 Jan 2014 18:56:52 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 83896 invoked by uid 500); 13 Jan 2014 18:56:22 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 83278 invoked by uid 99); 13 Jan 2014 18:55:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Jan 2014 18:55:04 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FH_RANDOM_SURE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bowserj@gmail.com designates 209.85.223.182 as permitted sender) Received: from [209.85.223.182] (HELO mail-ie0-f182.google.com) (209.85.223.182) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Jan 2014 18:55:00 +0000 Received: by mail-ie0-f182.google.com with SMTP id as1so8523883iec.41 for ; Mon, 13 Jan 2014 10:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Z/+2/2sEwXy1rZ30WP7Y02TnsX9crpzaz7BgbcQ75tI=; b=p7R4k8Z9R3ytn1euvwHIVLedU/mp8YxivWxYXigTCUCHtVPnoLqQ+9mntm+Cvn/UJA phKC9VGo/V5Q5xPhG8YkbP2NbBDfdOTGaG75P08JzV3AIL48ZUn/bWhxow3AX1xAwmik BrGbeFv+iQM0n4tqswbeeiWJkAE2qpTo4OhA2w7uMzvnq3xPErIo07ggeJ4PuRUnKLPq Rud3UrPAIx9UUpC+sukMJGbC2e2E8be9X3aU3EkUKzyEjflU7zNVGB1gv7pmXKfWXe7U ehmWW8qoEMyW0ivHqFqoVEIaMCDeKl4ZFXaVYDaju4plcSBJBWGK5sjuCLpZ5WMMPX7A N7KQ== MIME-Version: 1.0 X-Received: by 10.50.128.72 with SMTP id nm8mr20440795igb.10.1389639279609; Mon, 13 Jan 2014 10:54:39 -0800 (PST) Received: by 10.50.87.38 with HTTP; Mon, 13 Jan 2014 10:54:39 -0800 (PST) Reply-To: bowserj@apache.org In-Reply-To: References: Date: Mon, 13 Jan 2014 10:54:39 -0800 Message-ID: Subject: Re: [Android] Deprecation of Geolocation on Android From: Joe Bowser To: Lindsey Simon Cc: dev Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org So, an update on this. 1. Our users don't know how GPS works! I can reproduce Geolocation errors only by disconnecting my WiFi and by not having a SIM in the phone and expecting my GPS to magically get the signal from inside my office (It takes 2 minutes at least). I can't change the laws of physics, so this is working as intended 2. Our GPS doesn't work any better or worse than Web GPS 3. We'll still have people filing bugs against the Geolocation plugin that I can't reproduce, I'd rather close them as Web GPS problems than "You've never used GPS before, I can't reproduce" problems. I think we should deprecate the code for the time being, since there isn't actually anything wrong with it other than the fact that it has a 60s callback (which was considered reasonable in the old days of 2008 when batteries died more quickly). On Sat, Jan 11, 2014 at 12:33 PM, Lindsey Simon wrote: > +1 to nuking it. > > Anyone depending on it for really old versions of Android is likely not > doing anyone a favor (themselves or their users) - and (I think) it adds to > new developer confusion. Then again, having a plugin that only adds the > permission bit sort of does that too. > > > > On Fri, Jan 10, 2014 at 7:26 PM, Michal Mocny wrote: >> >> Adding support for play services based geolocation could come as a value >> add later. If the current implementation is broken and no one wants to >> work on it (seems to be the case since it hasn't been fixed yet), then >> Joe's suggestion to just drop it now and leave a no-op plugin that adds >> permission only sounds like the right thing short term. >> >> Joes first email claims Web Geolocation supports all current versions of >> android (http://caniuse.com/geolocation claims android 2.1+ though I >> didn't >> look in to possible quirks). >> >> -Michal >> >> >> On Fri, Jan 10, 2014 at 8:43 PM, Andrew Grieve >> wrote: >> >> > Is the plugin still needed on older android versions? e.g. we might >> > want to have it be a no-op based on the android version instead of >> > deleting it? >> > >> > Android geolocation seems to have gone Play Services, so another >> > option would be to make the plugin use that instead of the OS >> > geolocation in order to provide some utility. >> > >> > On Fri, Jan 10, 2014 at 4:14 PM, Jesse wrote: >> > > The index.html issue was iOS, not sure if it still exists. >> > > >> > > Windows Phone 7+8 use the browser based geolocation as they have >> > > implemented the spec, However because of the way permissions are >> > managed, >> > > there is a native do-nothing stub that simply signal that Location >> > Services >> > > are required. >> > > Windows8 does some massaging of the api to the WinJS version, and adds >> > the >> > > permissions to the project. >> > > >> > > I just spoke ( physically ) with Joe, and with this change, the >> > geolocation >> > > plugin would still exist for Android, it would just add the permission >> > > to >> > > the app. So, Android's plugin would be almost identical to WP7+8 with >> > this >> > > change. >> > > >> > > +1 from me, assuming everything will just work. >> > > >> > > >> > > >> > > @purplecabbage >> > > risingj.com >> > > >> > > >> > > On Fri, Jan 10, 2014 at 3:40 PM, Joe Bowser wrote: >> > > >> > >> It never did on Android, you can see this in Mobile-Spec. >> > >> >> > >> On Fri, Jan 10, 2014 at 3:39 PM, Brian LeRoux wrote: >> > >> > Does the permission dialogue still ask for index.html ? >> > >> > >> > >> > >> > >> > On Friday, January 10, 2014, Joe Bowser wrote: >> > >> >> >> > >> >> Due to numerous issues found in Geolocation, combined with an >> > increase >> > >> >> in reliability of the Web Geolocation, I'm wanting to see us EOL >> > >> >> the >> > >> >> Geolocation plugin. >> > >> >> >> > >> >> Reasons for this include: >> > >> >> * Support for Geolocation on all currently supported versions of >> > >> Android >> > >> >> * Numerous issues with the current Geolocation plugin that may >> > >> >> involve a full re-write of the Geolocation plugins. >> > >> >> * The Web Geolocation may be more energy efficient than our own >> > >> >> Geolocation polling. >> > >> >> >> > >> >> What do people think about deprecating this plugin and >> > >> >> recommending >> > >> >> that we use the browser's implementation on Android? >> > >> >> >> > >> >> Joe >> > >> >> > > >