琴線探査

二地点の緯度・経度からその距離を計算する（日本は山だらけ〜） のJava版をSwift2に移植しました。数学は分かりません。理論も分かりません。でもSwiftとJavaは分かるので移植はできるのです(^^); オリジナルがMITライセンスなので、このコードもリスペクトを込めてMITライセンスとします。 // // GeoUtil.swift // import Foundation /** * 二地点の緯度・経度からその距離を計算する（日本は山だらけ〜） - http://yamadarake.jp/trdi/report000001.html */ @objc(GeoUtil) class GeoUtil: NSObject { static let BESSEL_A: Double = 6377397.155; static let BESSEL_E2: Double = 0.00667436061028297; static let BESSEL_MNUM: Double = 6334832.10663254; static let GRS80_A: Double = 6378137.000; static let GRS80_E2: Double = 0.00669438002301188; static let GRS80_MNUM: Double = 6335439.32708317; static let WGS84_A: Double = 6378137.000; static let WGS84_E2: Double = 0.00669437999019758; static let WGS84_MNUM: Double = 6335439.32729246; static let BESSEL: Int = 0; static let GRS80: Int = 1; static let WGS84: Int = 2; static func deg2rad(deg: Double) -> Double { return deg...

iOSでのバックグラウンド処理の制限 iOSでのバックグラウンド処理は非常に制限されているが、いくつか方法はある。しかし、「定期的にバックグラウンド処理をする」という条件になるとかなり限られる。 どのような方法を選択できるかはアプリのタイプや目的によるが、アプリによらず選択できるであろう方法は少なくとも２つある。 Background fetch iOSがアプリの利用頻度などから「非定期に」バックグラウンド処理を動作させるので使えない。 Remote Notifications サーバーからのNotificationが届くタイミングでバックグラウンド処理を起動する方法だが、サーバーサイドの実装が必要な上、Notificationが届くタイミングはまちまちで、最悪の場合は届かないこともあるので、苦労の割に確実性に欠ける。 AndroidのAlarmManagerの代替は無いのか？ 調べた限り、iOSではAndroidでいうところのAlarmManagerのようなバックグランド処理はできない。 iOSで言うところの「バックグラウンド」とは、タスクマネージャーにプロセスが残っている状態のこと である。つまり、ユーザーがタスクマネージャーからアプリを終了させたらバックグラウンド処理はできない。 位置情報の更新を利用した定期バックグラウンド処理を採用 幸い今回開発中のアプリは位置情報を利用するタイプのアプリなので、「Location updates」のcapabilityを利用して定期的にバックグラウンド処理をさせることができた。 位置情報の更新によるバッテリー消費を抑えるために考えた２つのこと（失敗） しかし、ここで気になるのは、バックグラウンドで位置情報を更新し続けることによるバッテリーの消費がどれだけのものなのかということ。 そこで、このあたりを参考にした。 Energy Efficiency Guide for iOS Apps: Reduce Location Accuracy and Duration 一番始めに考えたのは、iOS9から導入された requestLocation() を利用することだった。タイマーで必要な時だけrequestLocation()を使って位置情報を取得すればバッテリーの...