self.property と _property の違い

objective-c でプログラムしていて、property の値をいじりたい時、self.property と _property どっちにすればいいのか、ふと悩んでしまいました。

実験した結果、self.property とすれば、setter が呼ばれました。ので、setter を呼びたい場合は、self.property にしたほうが良いと。

_property では setter が呼ばれません。

軽くハマりましたが、使い分けができるようになって良かったです。

NSPredicate で検索句を作る

バードウオッチングをして、フィールドノートを記録するためのアプリを作成中です。日本で観察できる野鳥名のマスタは日本野鳥の会から取ってこれたので Core Data に入れました。頭一文字を入力したら、候補の野鳥名が一覧で出てくるようにするにはどうするのか調べたところ、NSperdicate の出番だと。

predicateWithFormat メソッドを使用すると、完全一致で検索ができるようになったのですが、前方一致で検索する方法が分からない。さらに調べたところ、between, like, contains などが指r定できることがわかりました。何だか SQL っぽいですね。

画面から入力された文字の末に * をつけて検索したいところなのですが、うまくいかない。predicateWithFormat:"jname LIKE %@*", searchStrings と安易に指定してみたところエラー発生。

* を取って検索すると完全一致で検索だし、試しに contains を指定してみたところ、任意一致で検索する始末・・・、、ま、これはこれでいつか使えなくもないのでよいかもしれませんが。。。

試行錯誤の末、次のように、* を含む検索文字を作っておくことでうまくいきました。

    NSString* searchword = [NSString stringWithFormat:@"%@*", searchStrings];

    NSPredicate* predicate = [NSPredicate predicateWithFormat:@"jname LIKE %@", searchword];

searchStrings は、このメソッドの引数。

なんかめんどくさいなぁ。

後日談ですが、さらに調べたところ、MATCHE という慣用句があり、LIKE の代わりにこれを指定すれば目的達成だと、めでたし、めでたし・・・

AppDelegate を他のクラスで使う

AppDelegate とは何だろう。delegate とどう違うのか。

私も未だ明快にわかっていないのですが、AppDelegate は、Application 全体を通じて共有するようなオブジェクトを定義しておいて、必要に応じて参照・更新するような使い方をするようです。言ってみれば、昔のグローバル変数にすごく似ているのかなと。

AppDelegate の場合、Application を通じて参照できるため、AppDelegate というクラスをわざわざ定義してインスタンス化したオブジェクト参照するという手の込んだ概念となっていますが、グローバル変数だと考えた方が遠回りでもないし、理解が早い。

オブジェクト指向では忌み嫌われるグローバル変数の概念ですが、例えばゲームのスコアのような全体を通じて参照・更新するような性質のものの扱いには、確かに便利な概念でしょう。

目下、CoreDate を使っていて、アプリケーションの随所で参照するマスターデータがある場合、AppDelegate で managedObjectContext を生成しておいて、他のクラスで必要に応じて参照・更新できると、多分、メモリの節約にもなるし code も少なくて済むでしょう。

そんな訳で AppDelegate を使おうとすると、素ではすごくめんどくさい。

NSManagedObjectContext* mg = [(AppDelegate *)[[UIApplication sharedApplication]delegate];

とした上で、

NSEntityDescription* entity = [NSEntityDescription entityForName:@"someEntity"

                                              inManagedObjectContext:mg];

などとする。

何がめんどくさいかというと、初めの (AppDelegate*)[UIApplication... の部分で、キャストですか？、使うたびに毎回ですか？、何ですかそれ？　みたいな感じになる訳です。

なので、例えば、viewDidLoad メソッド辺りに、

appDelegate = (AppDelegate *) [[UIApplication sharedApplication] delegate];

としておくと、以降は、appDelegate.hogehoge のように、いつもの property のように使用できて便利だなと。

もちろん、クラスの頭で

Appdelegate* appDelegate;

と宣言することも忘れてはならない。

愛宕吾国ハイキング縦走コース

今年はトレイルの大会に出なかったので、年末の三連休に自主練することにしました。茨城方面の山でどこか良いところはないかと探してみたところ、3つほど候補があり、筑波連山縦走も考えたのですが総距離 37 Km と、あまりにも長く、自信がないので、愛宕山ー難台山ー吾国山の縦走コースにしました。これなら距離も17Km 程度と、難なく行けそう。

高尾山から陣馬山の往復縦走は以前何度か走ったことがあるのだけれど、今回のは常磐線岩間駅から水戸線福原駅までの one way。高尾山の場合、駅で着替えてコインロッカーに預けておけるのだけど、今回はそうはいかない。荷物はできるだけ軽く済むよう厳選して、着替えのウインドブレーカーとジオラインを持っていくことに。その他、飲み物 1L と財布などを入れたらリュックはもう一杯。

当日は 6 時前に家を出て、岩間駅に着いたのは 7:30 頃。前日、台風？ではないと思いますが、やけに暖かくて、その気温を引きずり今日も暖かい。キャプリーンを着ていたら暑い。山中、モヤが多くて景色が見えない。中盤快晴となり景色を満喫できたのはよかった。ゴールの福原駅に着いたのは 11 時少し前だったので、3 時間半ぐらいかかったことになる。道中、道はよく整備されていて、ところどころ看板も立っているので迷うところはあまりありませんでした。

そんな中、次回に備えて、2 箇所だけ間違いそうなところを書いておこう。愛宕神社から先は、神社の階段を降りて手を洗うところの横にある階段を降りる。せっかく苦労して登った分ほとんどを降りてしまうことになるので、もったいないのと本当にこれで良いのか不安になりますが、それで正解。

もう一つは、吾国山を降りて福原駅までの道。登山道入り口から先に、ところどころ看板が立っているのでそれに従って道を採ることになりますが、あぜ道のようなところはほとんど迷わなくて、一般道に出てからがわかりにくい。駐在所付近まで行ってしまったらそれは行き過ぎ。遥か彼方に見えるのは実は水戸線で、そちらの方面に左折した方が良い。今回は看板を lost したらしく（ってか、看板立ってた？）なんかおかしいと思って iPhone の地図で確認したら行き過ぎに気づいてルートを修正。最後の最後で lost するとガックリ感が大きい。

一方、トレイルのコースはほとんどがダブルトラックで道迷いの心配はない。でも、このコース、アップダウンがきつすぎて、登りはほとんど走れなかった・・・。また、前日の雨で滑りやすくなっているところがあり、傾斜のきついところでは滑って登れないところが 2 箇所だけあり、難儀しました。以前、岩間のトレイル大会に出た時も傾斜きついなと思ったのだけど、ハイキングコースと甘く見るとかなり痛い目に合いそう。

走った後は、いこいの家はなさとで風呂と食事しました。アルコールも置いてあって、つい、ハイボールを飲んでしまいました。もう少し近いと良いのだけど、クールダウンと言い聞かせて歩きました。宍戸駅前の踏切がちょうど工事で通れなくなっていたのでかなり迂回したので、2Km 以上あると思います。

また時間を見つけて challenge してみよう。

SKScene で、view が取り除かれる時に呼ばれるメソッドは・・・

SKScene で、View が表示される時に呼ばれるメソッドは、

-(void)didMoveToView:(SKView *)view

ですが、その view が取り除かれる時に呼ばれるのはなんでしょう。

取り除かれるというのがよくわかんない表現になっていますが、結局のところ、別の view を表示しようとしてその view を消そうとした時に呼ばれるメソッドです。

別の view と言うと、今書いているプログラムとの整合も悪くなってくるので、didMoveToView が呼ばれる前に呼ばれるメソッドといった方が的を得ているでしょうか。

昔 4D のプログラムで event と呼んでいたものですが、Objective-C でもこういった、メソッドがちゃんと用意されていました。

- (void)willMoveFromView:(SKView *)view

便利なものですね。

force touch

MacBook 12 inch ですごいと思うのが force touch。トラックパッドを押すと、感覚的にはどう考えても押している反応があるのに、装置が作り出した擬似感覚。電源 off で、トラックパッドを押しても全然押した気がしません。これはすごい。

これ、何がいいことあるって、使っている側からすると、スイッチだとどうしても「いつか壊れちゃうんじゃないの」っていうのが気になるのだけど、それがない。同じく内臓ファンもないので、故障しにくさがさらに増します。実は、これ買う前に MacBook Air 11in 使っていたのだけれど、買い替えの理由がファンの故障によるものだったので、なおのこと精神衛生上好ましいのだろうと。

ところで、force touch ができるんだったら、キーボードもそうしちゃえばいいのでは？と思ってネットで調べたら誰もが思いつくことのようで、そんな観測記事がいろいろ載ってました。あまり深く読んでいないのだけれど、自分でも想像を膨らませてみることにしました。

まず、従来のキーボードを全部 force touch に置き換えるのならば、今のキーボード面はのっぺらでよいことになります。金属板一枚貼り付けてある感じでしょうか。それは無駄なことであることは誰もが賛同するところで、液晶ディスプレイ二枚おきという形が想像されます。

ただ、液晶ディスプレイが二枚あっても、一枚はキーボードに使うので手で塞がれてしまい、あまり視認性がよくありません。ってことは、先日発表のあった、ファンクションキーの部分が液晶になっているだけでもよいように思います。そうした場合、依然キーボード部分がのっぺらになってしまいますが、例えば全面トラックパッドとかだとどうでしょう。以前に比べて広くなったトラックパッドの面積。これを拡張して全面トラックパッド＋force touch 仕様のキーボードになると。んーー、便利そうですがやっぱり明確なメリットが感じられないなと。

全面スピーカーとかはどうでしょう。これも悪くはないのですがそこまでサウンドにこだわるかなと。しかもノートで。

元に戻って、液晶ディスプレイだと、必要に応じて画面を拡張できることになるので、ま、便利といえば便利かなと。今の所、この線で勝手に予想しておこう。

Mac Book 12 inch

MacBook 12 inch を使っています。

これで Xcode を使って開発までしているので、酷使している感がすごいなと。。

インターフェースが usb-c だけとか、キーボードが打ちにくいなど前評判が悪い意味ですごかったのですが、実際使ってみるとほとんど不満がありません。

全くない訳ではなくて少ないながらも不満な点を挙げると、インターフェースが usb-c のみなので、拡張するためのデバイスを購入しましたが、usb-c インターフェースのものはなんでも高い。延長コードで ¥2000 とか、USB の延長コードは 100 円なんですけど・・・と、その価格を知っているととても買えない訳で・・・

早期に改善されることを希望します。