为“超本地”应用程序获取用户位置（也处于死亡状态）的适当方式
要求 –我build立一个hyperlocal的应用程序，将提供基于他的位置的用户提供。 当在应用程序中，我可以得到他的当前位置，并相应地显示优惠，但我现在需要的是基于他的位置发送推送通知给用户。 所以我想找出用户的位置，并根据他的位置发送优惠。
我已经阅读苹果文档的重大改变定位服务，但这个答案是说，它不会工作，一旦应用程序被杀害。
我也读了关于跟踪用户的位置，但这不适合我的工作。 我没有得到超过5个更新的背景。
我当前在viewDidLoad代码 –
if (self.locationManager == nil) { self.locationManager = [[CLLocationManager alloc] init]; self.locationManager.desiredAccuracy = kCLLocationAccuracyBest; self.locationManager.delegate = self; self.locationManager.allowsBackgroundLocationUpdates = true; self.locationManager.pausesLocationUpdatesAutomatically = false; if ([CLLocationManager authorizationStatus] != AVAuthorizationStatusAuthorized) { [self.locationManager requestAlwaysAuthorization]; } } [self.locationManager startUpdatingLocation];
而我的委托方法看起来像这样 –
-(void)locationManager:(CLLocationManager *)manager didUpdateLocations:(NSArray *)locations { if (UIApplication.sharedApplication.applicationState == UIApplicationStateActive) { // Get updated data according to location } else { // Send location to server } }
我的应用程序function和我的plist – 
请build议一些适当的方法，我可以生活在1公里左右的准确性。
另一种方法 –
-
我可以在“后台模式 – 后台获取”的
fetchNewDataWithCompletionHandler:获取用户的位置fetchNewDataWithCompletionHandler:？ -
我可以使用无声推送通知的
application:didReceiveRemoteNotification:fetchCompletionHandler:获取用户的位置application:didReceiveRemoteNotification:fetchCompletionHandler:）：根据这个答案不可能
所以，你的问题基本上是“我怎么能绕过苹果专门devise的用户互动，为那些想让我的应用程序闭嘴？ 答案是“不，如果你想保持在AppStore的规则”。
请注意，如果用户决定终止您的应用程序（也就是说，他们将其刷出并从任务pipe理器中清除），则此devise的整个目的是让您的应用程序停止任何操作 。 苹果公司devise的这样，人们可以迅速closures你似乎想要实施的行为。 我不明白你为什么想要规避这一点。 我同意这种交互可能有些模糊（毕竟，用户也可以允许/禁止应用程序的权利，以在设置应用程序的背景中接收位置更新），但这是iOS定义的交互。
如果我正确理解了你，你已经成功地设置了后台定位模式，所以你的应用程序可以接收到位置更新，即使它不在前台（即在后台或挂起，在后一种情况下，iOS简单地唤醒您可以处理位置更新，例如发送本地通知以通知用户）。 这是一样好。
哦，不要担心设备重启。 是的，在重新启动后，你的应用程序在技术上还没有运行，但是由于用户没有最后一次明确地杀死它，所以iOS认为它处于挂起模式IIRC，所以你仍然可以获得重要的位置更新， 。 （更一般的说法是：人们似乎常常认为实际的应用程序进程状态反映了应用程序状态，因为它是在文档中定义的和/或应用程序是否显示在任务pipe理器中，与此相关联。完全正确。）
在您的评论之后编辑特别询问我关于后台获取的内容：
对不起，这可能不完全清楚。 我没有具体回答这个子问题，因为在用户故意退出你的应用程序之后，你不应该像解释的那样“欺骗”他们的意图。 无声推送通知不会正常工作，是的。
我不知道背景获取是否会以类似的方式被抑制（可能，但我没有尝试过），但是我认为这也不会帮助你，即使它仍然在工作（我怀疑，苹果可能会很努力）。 我也从来没有尝试（重新）在这个方法的位置更新，所以我不能说这是否甚至工作（一旦完成处理程序被称为系统可能会暂停您的应用程序至less，我不知道这个“重置”系统似乎用来决定哪个应用程序被唤醒并提供位置更新的“用户杀死应用程序标志”。
application:performFetchWithCompletionHandler:因为它被完全调用）将被操作系统基于启发式调用，它试图在这个“聪明”。 由于该方法旨在从后端获取一些不提供推送通知的数据，因此可能会严重限制所调用的时间，正如文档中所述。 决定什么时候操作系统调用的实际机制是黑匣子，当你需要它的时候试图诱骗它被调用是一场赌博。 这很可能是几个小时后发生的。 考虑以下情况：
- 你的应用程序在后台定位模式下运行良好（我正确地理解了你，因为你已经成功地设置了这个function？请看这里和这里 ）
- 用户手动杀死您的应用程序。 为了这个论点，让我们假定不会让系统从以后重新启动它给它一个后台获取机会
- 由于其他应用程序正在系统上运行，并且用户此刻只有一个边缘连接，所以操作系统决定启动一个后台获取是一个糟糕的时间（我只是假设这些因素起作用，就像是一个黑盒子，但这些对我来说似乎是合理的）。 您的用户绕过多个位置，绕过您感兴趣的几个位置。
- 两个小时后，用户现在在一个完全不同的区域，你的应用程序再次由操作系统启动，并得到一个
application:performFetchWithCompletionHandler:call。 您再次开始位置更新（让我们假设即使工作，并且系统不会立即终止应用程序，即使在假背景获取它在后台提供位置更新后）。 你错过了几个地方，但是现在应用程序处理新的。 你所有的逻辑基本上都搞混了，因为你没有计划丢失那么多的位置更新。 - （可选：经过一段时间你的用户意识到你的应用程序显然做了某些事情，尽pipe他们终止了它（例如，他们注意到电池消耗），他们将删除你的应用程序，并留下一个开始审查…）
- （可选2，最坏的情况：一旦苹果意识到可以在用户以这种方式杀死应用程序后重新启动后台位置更新，他们只需在iOS更新中closures循环漏洞，并且您的应用程序又回到了我们开始的位置。 ..）
logging：我不是捍卫苹果公司做出的任何devise决定，我知道这是令人困惑的包装你的头，正如一个人可以表示“在任何情况下保存电池和用户意图”，可以做一个更好的背景跟踪。 我只是指出，他们在这里控制着，试图围绕他们在平台上设置的任何具体的交互范式进行试验，这可能不是一个好主意。
所有人都说，恐怕“用户终止了应用程序，现在我不会得到任何位置更新”只是你必须忍受的东西。 为什么这甚至会成为你的问题，考虑到你没有说任何关于背景定位模式对你不够？ 我可以想象的唯一（可疑的）场景是一种跟踪器应用程序，可能在分发服务的员工或设备上给予的设备上。 如果是这样的话（并且抛开这些东西背后的道德观念，在一些甚至是非法的国家，请介意你……），我不得不说，iOS根本就不是这个的正确平台。
嗨只是创build一个UILocalNotification设置它与您的详细信息，最重要的是当您input一个Region时触发通知添加region属性请参阅文档
希望能帮助到你