TLSv1.2 って何ですか・・・
事の発端はアプリから SSL 通信で CGI にアクセスし、JSON データを受領しようとした事。
NSURLRequest を使って、簡単・簡単、と思ったら、推奨していないので、NSURLSession を使えと叱られる。うわーめんどくセーと思いながら渋々書き換えたところ、error 発生。どういうわけか、ここだけ日本語でエラー表示。
Error Domain=NSURLErrorDomain Code=-1200 "SSLエラーが起きたため、サーバへのセキュリティ保護された接続を確立できません。
何かいつもと様子が違うので、ググってみたら、iOS 9 から TSL v1.2 となっていて、Web サーバ側での対応がとれてていないのでエラーになっている感じ。Web サーバは当方管轄外なので、回避策はないのかさらに調べたところ、まず、console で通信しようとしている Web サーバの対応状況を調べ、次に、info.plist に例外記載すればよいらしい。
console で調査：
/usr/bin/nscurl --ats-diagnostics https://some_domain
TLSv1.2 with PFS disabled and insecure HTTP allowed
Result : FAIL
---
---
TLSv1.1 with PFS disabled and insecure HTTP allowed
Result : FAIL
---
---
TLSv1.0 with PFS disabled and insecure HTTP allowed
Result : PASS
はいはい、v1.0 じゃないとダメなのね、ということで、今度は info.plist に以下の記載を追加。
App Transport Security Settings, dictionary
Exception Domains, dictionary
domain_name, dictionary
NSIncludesSubdomains, Boolean, YES
NSThirdPartyExceptionRequiresForwardSecrecy, Boolean, NO
NSThirdPartyExceptionMinimumTLSVersion, string, TLSv1.0
どこに追加するのかよくわからなかったので、Information Property List のすぐ下に追加しましたが、ちゃんと設定されたようで、うまく通信できました。
これ、普通わかんないよね。
ふうぅぅぅ。
LM5102 と LM0102 の比較
先日、LM5102 と LM4102 の違いについて言及しました。
その後、LM0102 を購入（厳密には、Twill black）を購入したので、重ねてみてスタイルの違いを比較しました。
はじめに、LM5102 の説明を読んだ印象と、実際に履いてみての思っていたのは、結局、原点回帰なら LM0102 と変わらないのでは？と思っていました。今回、両方を重ねて比較した結果、スタイルはほとんど一緒だということがわかりました。
ただ、購入したのが Twill black なので、履いてみての姿は随分違います。Twill の方がシワが目立たないので、陰影も薄く、履いた姿はブーツカット感もない感じに見えます。
細かく見ると、仕立ての部分で detail が随分違います。LM5102 の方が総じて作り込まれている感じがします。ジッパー、レザーバック（LM0102 は革ではない）、サイドの耳が開いている（履き込むといいアタリが出る）、ベルトの穴が 7 本などです。こういった細かい違いが価格差になっているようです。ただ、この違いは履いた時の見た目にはあまり違いが出ません。生地もオーガニックだったりトレーサビリティだったりするので上質ですが、履き心地も見た目も違いになって現れないでしょう。残りの良さとして、染めの違いがありそうで、同じブルージーンズなら、LM5102 の方がカッコよく色落ちする期待感があります。
今回、Twill の黒を購入しましたが、LM5102 （アメリカンライダーズ）でも Twill 黒あります。Twill の場合、前述の通り、見た目にはさほど違いが出にくいので、価格差を考え、LM0102 でもいいかなぁと思いました。
私としては、ローライズ感満点で、履いた時の見た目のかっこよさが抜群の LM4102 のスタイルがとても良かったので、復活希望です。
addObserver に UserDefaults を登録できる
プログラムを作るときに KVO って便利なんだけど、監視対象にするオブジェクトとして、UserDefaults を指定できることを知らなかった・・・
随分遠回りな実装になってしまったところでできることに気がついて、その後、余分なコードを消し消ししてそっちの方が大変だった。
実装は次のような感じ。
defaults = [NSUserDefaults standardUserDefaults];
[defaults addObserver:self forKeyPath:@"fireTime"
options:( NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld )
context:nil];
便利、便利。
UserNotifications について
時計とアラームをアプリに組み込んでいて、時間が来たら Alerm を出すわけですが、以前は、Notification とか使っていたんですけど、いつの間にか、UNNotificationCenter なる Framework が追加になっていた。
Swift ベースの記述が多くて難儀しましたが、いろいろ調べたところ、今までよりも格段に使いやすくなっていることが分かりました。後学のため、組み込み方をメモします。
以下のような記述が必要ですが、ひとまずは Appdelegage.m の applicationDidFinishLaunchingWithOptions に記載。
//set NotificationCenter instance
UNUserNotificationCenter* notificationCenter = [UNUserNotificationCenter currentNotificationCenter];
// set delegate
notificationCenter.delegate = self;
//setting type of notification
// use Sound and Alert
[notificationCenter requestAuthorizationWithOptions:UNAuthorizationOptionSound|UNAuthorizationOptionAlert
completionHandler:^( BOOL granted, NSError * _Nullable error )
{
// none
}];
フォアグラウンドで通知を受けた場合の処理は delegate method が呼ばれる。
該当するクラスに、delegate を設定し、.delegate = self; を忘れずに、以下のメソッドを記入。
- (void) userNotificationCenter:(UNUserNotificationCenter *)center
willPresentNotification:(UNNotification *)notification
withCompletionHandler:(void (^)(UNNotificationPresentationOptions))completionHandler
{
// アプリがフォアグランドにいた場合の通知動作を指定する。
completionHandler(UNNotificationPresentationOptionBadge |
UNNotificationPresentationOptionSound |
UNNotificationPresentationOptionAlert);
}
はまってしまったのは、AppDelegate.m に記載しなければならないのかと思ったのですが、普通に delegate method だったので、delegate の宣言をして、呼んで欲しいクラスに書けば OK。
ボタンを押したら SpriteKit に切り替えるには・・・
アプリを作成中なんですが、今のままの機能だけでは reject 必至だろうということで、ミニゲームの機能も持たせることにしました。アプリの画面にボタンを用意して、ボタンを押したら spritekit の画面に切り替えようとしたところエラー発生・・・
呼び出し元のボタンでは、以下のように呼びます。
[self presentViewController:gameViewController animated:YES completion:nil];
呼ばれた ViewController は spritekit の Scene を呼ぶわけですが、この ViewController の実態は UIViewController。テンプレまんまで、以下の通り。
SKView* skView = (SKView *)self.view;
これではダメで、以下の通りでようやくうまくいきました。
CGRect applicationFrame = [[UIScreen mainScreen] bounds];
SKView *skView = [[SKView alloc] initWithFrame:applicationFrame];
self.view = skView;
実は以前もトライして、うまくいかなかったんですが、今にしてようやくなるほどと。
Xcode 8 では CoreData 用のファイルは automatic になったんだって
仕事でアプリを作る必要があり、CoreData も使おうと。ようやく作り方にも慣れてきたところで、まずはモデリングして、次に、Editor -> Create NSManagedObject Subclassess... を選んでファイルを生成してと、慣れた手順でファイルを作ったら、build でエラー発生・・・
エラー内容は、以下の通り。
Showing All Messages
ld: 4 duplicate symbols for architecture x86_64
Showing All Messages
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ナンジャコリャ。重複しているファイルがあるので、linker がエラーこきました、とのこと。しっかりしろよ、clang。
調べてみたら、このエラーは必要なライブラリを指定していない時に出るよとのことで、あぁ、そう言えば CoreData を linked framework に指定していなかったなぁ、ってか、そんなこと最近しなくてもよくなった気がしていたんだけど・・と思って、指定してもエラー解消せず・・・
最近 Xcode がアップデートしたので、ひょっとして Xcode の bug じゃないのか？と思って、さらに調べたところ、Xcode 8 から CoreData 用にモデリングしたファイルは自動生成されるようになったんで、Subclassess で生成してしまうと duplicate error が出てしまうと。
自動生成するかの指定は、.xcdatamodeld を選択して、Show the file Inspector の Tools
Version を見るとわかります。Automatic (Xcode 8.0) と書いてあるので、自動生成だと。
全然知りませんでした。Release Note をよく読めってことですかね・・・
でも、便利な機能であることは間違いないなと思いました。これによって、アプリのバージョンアップの際、CoreData のモデルに変更があるとデータが失われてしまうので、migration 必要とかも解消するのかなぁ・・・
LM5102 と LM4102 の比較
Lee の 102 が好きで、いつもこれなんですが、数年前に買ったものが、ついに、お尻の辺りが薄くなってきて、このままではまずいなと。
アメ横の 610 のセールはもうすぐだった気がするけれども、待てそうにないので買うことにしました。おまけで、Lee のマグカップもらえて嬉しかったです。
今売っている 102 は、細かくいうと LM05102 というモデル。数年前に買ったのは LM4102。数字からしてアップデートされているのですが、LM04102 のお尻の生地が破れてしまう前に、両モデルを重ねてスタイルを比較してみました。
重ねてみると、ほとんど変わりません。膝の絞り込み、裾の広がり具合、レングス、同じです。宣伝見ると、生地が厚くなったのか？とも思っていましたが、それも変わりません。
大きく違うのは股上の長さ。LM05102 の方が断然長く、チャックの長さも 2cm 以上長いです。これは、履き心地にも大きな違いとして感じられます。履きやすさでいうと断然 LM5102 ですが、おそらく、履いた姿がカッコよく見えるのは LM04102 でしょうね。
あと、宣伝で見て知っていたのですが、ベルトループが 5 → 7 本に増えました。効果のほどは、んーー、ズボンに入れたシャツが出にくくなる？かもしれませんね、まだわかりません。
そのほか、Lee のレザータグがちょっと変わってます。色が少し濃くなってます。これは正直 LM04102 の方が良かったかな。ベルトするときは、中に通さないので、誰にも見えない部分ですから、実はどうでもよいことなのですが・・・また、見えないことですが、ジッパーのつまみの形状が変わりましたね。今までは真四角でしたが角がカットしてあり、全体的に大きくなっています。使い勝手がよくなった感じです。
ってことで、しばらく履き込んでみます。
