CloudKIt Database を使って・・・
CloudKit Database を使っての印象。
良い点
- CoreData いらないかもね。全部サーバに保存しちゃえば良い。
- 無料で使える容量が多いので、ほとんど無料で行けちゃうね。これはありがたい。
悪い点
- 蓄積したデータのメンテナンスはどうやるのがうまいやり方なのか。ブラウザからのインターフェースは設定に関するもので、プログラムを介在させる余地はない。アプリからメンテナンス用のプログラムを発行できるが、利用者全員が使えてしまうとまずい訳で、隠しコマンドを打つと(あるいはジェスチャー?)インターフェースが出てくるみたいなトリックが必要か?
- リレーションについて、合理的なプログラムは書けない。SQL で慣れているなら特に違和感はないだろう。CoreData で N : N の記述に慣れてしまうと、途方もなく面倒なプログラムを書いている気になってしまう。
- 大量のデータ(例えばマスターデータ)を保存しようとすると処理が追いつかないことがあるので、少し wait しながらコマンドを発行する必要がある。デメリットというより、使用する上でのコツのようなものでしょうか。
また気づいたら書きます。
結局、Objective-C の方がよいのでは・・・
昨日の続きとなりますが、特別な事情があり QR コードリーダーを急遽実装することになり、昔の醤油もとい source を引っ張り出して来て実装したのです。
info.plist の仕様変更という躓きはあったものの、ほとんどまんまで実装できました。理由は、ハードウエアに依存するプログラムは、結局のところ深いところで native C で書いてあるので、親和性の高さから言って Objective-C が有利なんじゃないかと思いました。アプリを Swift で書いていたとすると、以前の source はまんま使えない、変換するにしても、実装は異なる形にならざるを得ない、という、今日は完徹でっすになりそうな悪寒、もとい、予感がしたのですが、そうはならなくてよかったです。
と、いつまで経っても Swift に移行できないというジレンマもありますが WWDC の動向を踏まえて、また検討したいと思います。
iOS 10 で、AVCaptureSession startRunning すると、error...
訳あって、制作中のアプリに QR リーダーを実装する必要が出て来て、ずいぶん前に作ったラーメンタイマーの source を引っ張り出して来て実装。
build & run で無事(?)error 発生・・・以前との違いは OS が 8 → 10 に変わったぐらい。
エラー内容を見ると、かなり深いところでエラーになっている感じ。さっぱり意味わからず、調べてみたら、stack over flow に以下の記述が・・・
iOS 10 で、AVCaptureSession startRunning すると、error になる場合は、info.plist に以下を追加しろ。
<key>NSCameraUsageDescription</key>
<string>Allow us to scan documents and capture images.</string>
なにそれ?
聞いていないんだけど。
半信半疑で試してみたら、カメラにアクセスする許可を求めるようになり、無事起動しました。
AVCaptureSession startRunning exc_bad_access iOS 10 Swift 3 - Stack Overflow
ふうぅ・・・
第5回 飯能アルプス~奥武蔵丸山トレイルラン、完走するも体ボロボロ・・・
距離がちょっと長いけど、参加したことがないレースなので、準備万端(のつもり)で臨むも、ゴールまで 9 時間近くかかるというなんとも情けない結果に・・・
距離が長いことはあらかじめわかっていたので、秋葉原までランニング 3 回、その他、20Km 以上の距離数えきれず、締めはつくばまでランニングと、足はしっかりできていたつもり。
レースを終えて痛いところは、太ももの前面と歯を食いしばったからか、顎の筋肉が痛い。太ももの前面は、特に階段を降りるときにかなりきつい。冷や汗が出るほど。顎の筋肉も相当やばい。お腹が空いているのに昨日は噛めなくて食べたくなくなるほど。
このコース、登り坂がきつすぎる。そして長い。見上げても見上げてもピークは遥か彼方、まるで見えない。しかも、途中で息継ぎしないと昇れないほどの急坂なので、全くスピードが出ない。登りがきついということは、下りも同じくらい急な坂ということ。ある程度の斜面なら、サーっと降りることができるが、そんな斜面ではなく、おっかなびっくり下りる感じで、下りもスピードが出ない。
あと、縦走区間がほとんどない。正丸峠を超えたあたりから、多少走れそうな区間があったけど、そこにたどり着くまでに足を使い果たしていて、スピードが乗らないし走る気力も失せてくる。
初めの 5Km 表示で長いと感じたが、10Km, 15Km が異様に長く感じる。15Km 地点で確か、4 時間は超えていたと思う。15Km 走って、まだ半分来ていないわけで、落胆の色は濃くなる。お金を払って出たレースなので、今まで考えたこともなかったけれども、リタイアしたいと何度か思った。ただ、リタイアしたところで、最寄り駅まで運搬し、以降はゴールまで電車で行って荷物を取ってくることになっているようで、それはそれで面倒すぎる。
25Km を超えたあたりからか、半分は超えた、残り半分、後半は確か下り一本調子だったはずと自分に言い聞かせて、淡々と進む。登って降りるとエイドがあるのが嬉しい。でも、エイドの後はまず間違いなく坂がきついということに気づき始め、エイドを離れたくなくなってくる。目論見通り、最後のピーク、丸山を超えたら下り一本調子になるも、もう、完全に足が残っていない。下りの方が足へのダメージがかかる。疲労が蓄積される感がすごい。
ようやくゴールするも、17 時過ぎていて帰りの電車に間に合わないかもしれないと思い、ゴール地点が温泉なのに風呂に入らず駅へ急ぐ。帰宅したのは 20 時を過ぎていた・・・
9 時間も運動をし続けたのは、人生初ではないだろうか。正直、もう、このコースは走りたくない(何日かするとまた、走りたくなるものだけど)。
日付の比較は compare ですか。
Objective-C で日付の比較をしようとしたところ、どうも、うまくいかない。
if ( now > item.date )
こういうのはだめ。
なんで?と調べて見たところ、compare 使えと。
[now compare:item.date] --> 1 ............ now の方が最近
[now compare:item.date] --> -1 ........... now の方が古い
isEqual といい、入念に用意してあるね。
設定、app、通知 が許可になっているのか調べるには・・・
時刻を設定すると、その時刻になるとアラームを出すアプリを作成中。こういった処理は、UNNotification を使って作成するのが iOS 10 からの流れのようで、UINotification の時代から大して慣れていない中、やっとこさっとこ意味のある機能を作ることができました。
端末が通知を許可しているか、許可していないかを調べる方法がわからなくて、色々試行錯誤してようやくわかりました。そもそもなんで許可しているかどうかを知りたかったかと言えば、タイマーをセットしようとして、時間が来たらアラートを出すのですが、端末が許可されていないと、fire しても発火しない(アラートが出ない)からです。
具体的な方法は、AppDelegate.m に以下のメソッドを定義します。
- (void) isNotificationsAuthorization:(void (^)(BOOL isActive)) handler
{
[[UNUserNotificationCenter currentNotificationCenter] getNotificationSettingsWithCompletionHandler:^(UNNotificationSettings* _Nonnull settings)
{
//settings.alertStyle == UNAlertStyleNone;
NSLog(@"settngs: %ld", settings.authorizationStatus);
if ( settings.authorizationStatus == UNAuthorizationStatusAuthorized )
{
// NSLog(@"Authorized");
handler(YES);
}
else
{
// NSLog(@"Denied");
handler(NO);
}
}];
}
このメソッドを呼び出すと、YES が返って来れば、端末は通知を許可していることになります。一方、NO が返って来れば、許可していないということです。このメソッドを呼び出すのは次のようにします。
AppDelegate* appdelegate = (AppDelegate *)[[UIApplication sharedApplication] delegate];
[appdelegate isNotificationsAuthorization:^(BOOL isActive)
{
if ( isActive )
{
NSLog(@"notification setting: YES");
}
else
{
NSLog(@"notification setting: NO");
}
}];
isActive の状況に応じて分岐できるので、例えば設定されていないことが分かれば、そこで「設定してください」のアラートを出すことができます。
というわけで、こんな感じでできることがわかって、良かった・よかったなんですが、余談もひとつ。
最近ネット上に Objective-C の記述が少なくて、そろそろ情報が増えて来た Swifit にしようかなと思い始めたところです。でも、Swift のコードを見ると、クロージャとかの記述は Objective-C とあんまり変わらず見にくい(醜い)ので、そうであれば、Objective-C の方がまだわかりやすくていいなぁと思いました。
SKLabelNode で画面中央に時計を表示すると、何秒かおきに横にずれてしまうのを解消。
SKLabelNode で画面中央に時計を表示した時のこと。時計は、シンプルに次のような形で HH:MM:SS。これ、何秒かおきに微妙右にずれ、左にずれを繰り返します。理由は、画面左右の中央に時計を表示しますが、時計の数字フォントの幅が、数によって微妙に異なるため。例えば、1 の横幅と 0 の横幅は違うということ。
これ、TeX の時も謎だったんだよなぁ。TeX で表組みする時、表に数字データが入っていると、数字によって幅が異なるので、縦に並べようとするとガタガタになっちゃう。回避策は、数字を表示したいときは数式モードにしてやると、0-9 まで全部の width が揃う(というか、kernning されなくなる)ので、表組みしてもガタガタしない。
SKLabelNode の場合、kernning を解除する指定は無いようなので、さてどうしたものかと試行錯誤した結果、horizonalAlignmentMode というプロパティがあり、縦方向に揃えようとする時、どこで揃えるかを指定できることが判明。今回の場合、SKLabelHorizonalAlignmentModeLeft を指定して、label の左端を揃える位置として指定してやることで、ずれなくなりました。デフォルトは center になっているので、数字の組み合わせによって時計全体の幅が変わるのでガタガタしていた、という訳だ。
細かく指定できていいけど、ちょっとめんどくさいね。