Search Results

获取经纬度

Base Localization for Purpose Key of NSLocationTemporaryUsageDescriptionDictionary : Not working. But, Base Localization for NSLocationWhenInUseUsageDescription : Working. Base Localization: English CFBundleDevelopmentRegion: en_US When iPhone Language Setting is Not English, I can see "AAA" in the location authorization request dialog. However, in the temporarily use location services with full accuracy dialog, I can see "....". Why Base localization for purpose string in NSLocationTemporaryUsageDescriptionDictionary doesn't work? Info.plist <key>NSLocationWhenInUseUsageDescription</key> <string>....</string> <key>NSLocationTemporaryUsageDescriptionDictionary</key> <dict> <key>MyPurposeKey</key> <string>....</string> </dict> InfoPlist.strings (Base) NSLocationWhenInUseUsageDescription = "AAA"; MyPurposeKey = "BBB"; InfoPlist.strings (English) NSLocationWhenInUseUsageDescription = "aaa"; MyPurposeKey = "bbb";

How will I be able to translate location purpose strings? Will it use InfoPlist.strings, or Localizable.strings? I assume that the purpose key will not be shown to the user. If I have my Info.plist set up as such: &lt;key&gt;NSLocationTemporaryUsageDescriptionDictionary&lt;/key&gt; &lt;dict&gt; &lt;key&gt;Purpose1&lt;/key&gt; &lt;string&gt;Purpose1TranslatedPhrase&lt;/string&gt; &lt;key&gt;Purpose2&lt;/key&gt; &lt;string&gt;Purpose2TranslatedPhrase&lt;/string&gt; &lt;/dict&gt; Should my InfoPlistStrings file look like?: "Purpose1TranslatedPhrase" = "We use your location to do a thing"; "Purpose2TranslatedPhrase" = "We use your location to do something very different"; Thanks

Hello! I’ve seen plenty of “brace yourself because users can give you approximate location permission” posts around but nothing related to the other way around. I am developing an app that needs to know which country a user is in so I don’t need more than approximate location and I would like to ask directly for it but my code doesn’t seem to work. This is my (simplified) code: let locationManager = CLLocationManager() locationManager.desiredAccuracy = kCLLocationAccuracyReduced locationManager.requestWhenInUseAuthorization() I have not seen other kinds of request...() methods neither other related settable fields in CLLocationManager, is it possible to do it in the first place? If so, what am I missing? Thank you a lot!

It was showing before when I tried the application without building against the iOS 14 SDK, but when I build it using Xcode 12, it doesn't show at all. I'm using CLLocationManager function requestWhenInUseAuthorization() and added the new locationManagerDidChangeAuthorization delegate function annotated with @available attribute. Not sure what am I missing? I tried all versions of Xcode 12 beta 1 through 4, all have the same issue. Note: I can see "Precise Location" option in settings, just not on the in-app prompt Note 2: I tried a completely new project with the following CLLocationManager().requestWhenInUseAuthorization() still the same issue

Ilya, where did you get that cool T?

The Core Location talk on WWDC emphasized that it's good to ask for in-use first. It also said that if i have been granted in-use, i can ask for always and get a prompt in the app again. This is good, but i would like to be able to inform our users as clearly as possible, i.e. if no prompt can be shown, i'd like to direct them to settings whenever they try to turn on a feature that requires "always". However, it's seems that there is no way to check whether the "always" question has been asked before, since there is only "NotDetermined". If i have "WhenInUse", i can't know if it's because i asked for always but didn't get it. It would have been great if there was a method like "canAskForAlways" or similar. Is there something i can do or do i have to store some variable in NSUserDefaults so that i know that i have asked for always? This way i can know that i have to show a popup directing the user to settings rather than ask for always but no system dialog pops up. Pointers appreciated.

Hello Apple, adopting new LM I have some questions: what do recommend concerning usage of new .reducedAccuracy and startUpdating .heading? when will the new method locationManagerDidChangeAuthorization called? where do you recommend to place init LocationManager? Ihm looking forward hearing from you Best regards Helmut P.S: amazing new features in iOS14. Great! locationManager = CLLocationManager()         print("initLocationManager 1")         //locationManager!.desiredAccuracy = kCLLocationAccuracyBest         locationManager!.desiredAccuracy = kCLLocationAccuracyBestForNavigation         locationManager!.activityType = .automotiveNavigation         locationManager!.distanceFilter = kCLDistanceFilterNone         print("initLocationManager 2")         locationManager!.delegate = self         print("initLocationManager 3")         locationManager!.requestAlwaysAuthorization()         print("initLocationManager 4")         locationManager!.allowsBackgroundLocationUpdates = true         print("initLocationManager 5")

For web apps that want location while running in a browser or webview, does the new location "precision" setting apply to them (reduced, full)? If so, which precision do web apps get and can a user change it? I.e. Does each web site get the precision that the user grants to the browser app itself? What about an app running in a webview -- where does its location precision setting come from and can a user affect it? Also, the web api for location doesn't report any information about precision setting, right? So, for example, a web app cannot determine that reduced precision has been set in order to alert the user that it needs full precision, right?

Hi, I have an App which just needs to know whether the user is coming home or is currently at home. I don't need the location at all and what to make this as privacy conscious as possible. Another app from someone else I use would just need the information how far away I'm from my home and when it looks like I might be coming home how long that will take (e.g. to adjust heating/cooling). My question: Do you have already requests to extend the location privacy features in that direction or do you see a privacy away way to implement it already? Kind regards, Alex

In Ilya Vegman's introduction to What's New in Core Location, he showed how the new reduced accuracy reports locations by snapping to quantitized regions of differing sizes. He mentioned that the regions will place the user on the appropriate side of an international boundary, but that it might show the user as potentially being in a neighboring city if they are in a city close to another. My app needs to know which state a user is in, which for users more than ~10km away from the state line would definitely be a good use case for reduced accuracy, except I'm worried about the case when the user is close to the state line. Are US state lines are treated in a similar way to international borders with regard to the quantitized regions. If so, would it be safe to map the centre of a region, determine which state it is in, and infer that the user is in that state? Additionally, with cities which are situated across state lines, in two states, such as Kansas City KS/MO, or Texarkana TX/AR, will state lines be respected by the quantitized regions in these cases?

Hi, we have an app that handles kind of time reporting when at a certain location, and therefor always need precise. The user can click a button to check in/out, but we also have feature that used background location and geofences so that the user can automatically be checked in/out when arriving and leaving a location. When the button is pressed first time we ask for "in use", when the user turns on the feature we ask for "always". The ios13 "provisional" state was therefor pretty detrimental to us since the user might go in an turn it on, expecting it to work, and then leaving work 30 mins later not be automatically checked out. We had to add large banners telling them to go in to settings if they wanted it to work right away... Now from the session, it was mentioned that you changed this in 13.4. However, it was not clear to me exactly when it applied. Our users most often clicks the button first, and then discovers the auto-feature later, but SOME might turn on the feature right away (especially on re-installs). In those cases we will ask for "always" before "in use". In these cases, will it work like before, i.e. we will end up in the "provisional state" like prior to 13.4, just because the user asked for always before in use?