ポケモンGo、部屋にいながらにして歩く？
ポケモンGo（iPhone）で一人歩きできてしまう裏技です。
1. アプリ起動
2, コントロールセンターを表示
3. コントロールセンターをすぐ閉じる
2, 3 を繰り返すと勝手にキャラクターが歩きます。
結構遠くまで歩きますが、無限に遠くに行くわけではありません。実際の位置から半径 300m ぐらいは歩くみたいです。
コントロールセンターを閉じたタイミングで位置調整が行われるようで、部屋の中など、座ったままでキャラを歩かせることができます。モンスターも捕獲でき、運良くポケストップまで着ければ回すこともできます。
WIFI は切った方が遠くまで行くように思います。ただ、2 分間に1度ほどGPS 信号を読み取るようで、画面上部に GPS を探しているとのメッセージが出続けることがあります。こうなったら、同じくコントロールセンターを表示して、Wifi を ON とし、赤い表示が消えたたら、また Wifi を OFF にし、上記の 2. 3 を繰り返します。
精度は悪いため効率は悪いですが、この方法でも、歩いたとみなされ距離も加算されます。2Km たまごぐらいは、部屋にいながらにして孵すことができます。
難点は、歩く方角を指定できない点です。部屋からは回せない少しだけ離れたポケストップに好きな時に行ける・・・ということだともっとよかったんですが、なかなかそうはいかないものです。
暑い日中や、雨の日、深夜など、外出が嫌だなぁ、でもどうしてもポケモンやりたいなぁという時はちょっとだけ使えそうでしょうか。
自作 class の sub class
自作 class の sub class なので、何か性能が悪くなってしまったか？と勘違いしていましたが、循環参照問題によるものと判明し解決できたので、sub class で色々実験。
まず、super class で定義済みの @property は sub class で再度定義する必要なし。当たり前ですが、試してみてよくわかったので。
次に、delegate。super class で protcol を通してあって、delegate メソッドも実装されていれば、sub class では protcol を通す必要なしで、delegate メソッドも実装必要なしで引き継がれる。
これは便利ですね。
cannot find declaration for class A superclass of class B.
ゲーム作成中です。
SpriteKit 使ってます。
ゲームシーンは SKScene で起こしています。
あるシーンを SKScene の sub class として作りました。class A とします。
次に、class A の sub class を起こしました。class B とします。
build するとエラーになります。
cannot find declaration for class A superclass of class B.
なんですかこれは？
黒本引っ張り出してきて調べるも不明。Xcode の解説はないので当然。
困った時は Google さんに聞いてみます。
StackOverflow が結構引っかかります。
ヘッダーファイルを循環参照している時に起こるエラーのようです。
それで、.h に記載していた #import を.m に移動したらうまくいきました。
#import する場所が重要な鍵を握るとは知らなかった・・・
ヘッダファイルと実装ファイルどちらで import すべきかはこれから勉強。
ふぅ〜・・・
KADI Port 到着
MacBook 12 inch を入手したのが去年の 5 月。外部ポートが 1 つしかなくて、どうかなこれと思案しましたが、ついに 5 年目に突入してしまった MacBook Air 11 inch の冷却ファンがイカれ気味で異音がひどく、いつ壊れるかヒヤヒヤで、おっかなびっくり使うのは開発者にとってまったくよくなく已むを得ない、というのは表向きの理由で、最新機種を使ってみたいとの気持ちも少しだけあって、考えようによってはいいタイミングで壊れてくれました、と。
入手前から分かっていたのだけれど、usb-c 一つしかないので、usb ハブは必要だろうと。
規格自体が新しいので周辺機器がなかなか出ない中、KickStarter で KADI Port を発見。早速申し込んだのが去年 9 月頃だったと記憶しています。
HDMI のポートが欲しかったんですが、Apple の純正はずいぶん高いのでちょっと買えないなぁと思っていたところで、安くはなかったんですが、スタイリッシュな外観にも惹かれてつい、出資してしまいました。
ようやく今にして届きました KADI Port。長かった・・・本当に長かった・・・シンガポールからの国際便で届きました。
一応、出資者には必要に応じて進捗が report されてくるのですが、一時期は 12 月中に発送と言っていたのに、なかなか円滑に進まないもので、製造している中華圏では旧正月で製造がすべてストップするとか（初めからわかってんだろ？と言いたくなる）、最終テストで看過できない問題が発見されたとか、私たちは決してあきらめないとか、いろいろ（言い訳含めて）理由があって遅れに遅れ、ようやく、ほぼ一年越しの昨日届いた次第です。
KADI Port は USB-C (power charge), usb-c, USB-A, HDMI ポートを持つハブです。届いたので早速、軽くレビュー。
まず、HDMI ですが、自宅のテレビにつないでみました。見事に出力出来ました。これで当初やりたかったことはほとんどできたと言えます。
外観ですが、購入前にも気になっていたのですが、USB-C のポートに差し込みますが、横幅が結構あるので出っ張りがそれなりになるので、なんか、差し込み口に変な力加わったら心配だなぁ、グラグラしないのかなぁ・・・と、それは、全然心配の通りで、力を加えるとグラグラしますし、誤って強い力を加えると折れてしまいそうです。将来は延長コードとかでつないで使おうかと思っています（一体型がよくて買ったのに、延長してしまうと本末転倒な気が・・・）。
また、これは誤算でしたが、厚みが結構あって、MacBook 12 本体よりも厚みがあります。つまり、装着すると土台側ははみ出た格好に・・・ただ、本体には丸いゴム足が付いていますので、下駄を履いた状態であることが幸いして、KADI Port を装着しても傾いてしまうことはありません。持ち上げる時に、装着したのと反対側を持ってしまうと KADI Port 側が当たるので、折れてしまいそうになりやや気を使いますが・・・
私が必要な機能は全て揃っていますが、装着するとグラグラしそうなのがちょっと嫌だなぁ・・・純正ぽい形状のものが安くなったらまた購入検討したいと思います。
Objective-C は古くさい？
Swift 全盛の今日この頃、Objective-C でプログラム組むのはいかなる理由によるものか？という命題があります。
当方、Swift には今のところあまり関心がない（もとい、学習する意欲がない）のですが、それは何でか自己分析しました。
まず、Objective-C を十分理解しているとは言い難いので、まずはこれを極めてからステップアップしようという心意気（意気込み）があります。職人は使う道具にこだわります。道具は苦楽を共にした戦友であり、良い部分・悪い部分含めて知り尽くしています。どんな難題も回避策が見出せます、見出してきました。実績を加味して信頼感が抜群です。そのような理由により、捨てがたいという理由です（もっとも、私の場合、極めていないので、まずは極めてからという心情が先に建ちます）。
次に、新しい技術は流行り・廃りが短期間に現れるのでそれを警戒している、というのがあります。新しい技術の学習コストはそれなりなのですが（日夜自宅で研究する日々）、いつの間にか廃れてしまって・・・という憂き目に遭いたくないので、十分浸透してから手を出そうという気持ちがあります。前例を挙げますと、config.sys、68k,漢字Talk（否、AppleTalk ?）、RealBasic, SCSI, FireWire など、かつて一世を風靡して今墓場行きの技術は、枚挙に暇なく、かつて、どれだけあったことかと・・・繰り返しますが、新技術は学習コストがそれなりにある、でも、熟練した時にもう廃れていた・・という事態を避けたいので、どうしても保守的になってしまうということです。
それで、Swift の今後はどうか・・・ですが、んー、そろそろ手を出そうかなという感じですね。Objective-C の古くさい言語仕様にちょっと、閉口気味なんで・・・
余談
FrameWork の問題ということもありますが、
メソッド呼び出しで、
[someClass someNethod];
someFunction(withArg);
のように、統一されていないのは、初学者にとって難関ではないかと。
最も、NextStep からの古参であれば、歴史的経緯を背景として十分理解できるのだと思いますが、beginner には明らかに取っつき難いでしょう・・・
クラスメソッドとは何か。
Objective-C のメソッドを大別するとクラスメソッドとインスタンスメソッドの 2 種類あり、その区別は定義するときに、頭に+ が付いていればクラスメソッド、- が付いていればインスタンスメソッドになります。
ところで、通常プログラムを書くときはインスタンスメソッドにすることが多いと思います。クラスメソッドは一体どのような用途に使うのでしょうか、というより、どうやって区別して使い分ければ良いのでしょうか。
今までとても疑問で、本を読んだり、ネットで調べたりしたのですが、今ひとつ、なるほどこうやって使い分けるのか（膝ポン）と納得できていなかったのですが、今日、具体的な事例でクラスメソッドの利用シーンがありました。
例えば、SKSpriteNode のサブクラス (STSpriteNodeSub) を作成し、メソッドを定義することを考えます。頭に SK と付いているのは、SpriteKit 派生のクラスを意味します。SKSpriteNode とは、ゲームの例で言うと、様々なキャラクタなんかを規定するためのクラスです。
今、このサブクラスを使って、丸や四角の形状を持つオブジェクトを生成することにします。
いつものように、
STSpriteNodeSub* hoge = [[STSpriteNodeSub alloc] init];
とインスタンスを生成し、hoge に対してプロパティを与えていく・・・という方法も取れます。インスタンスを生成してから、丸にしたり、四角にしたり順番に操作していく訳です。
この方法ももちろん採れますが・・・明らかにめんどくさいですよね？
例えば、丸であれば、
initWithCircle:(float) radius cener:(CGPoint)centerpoition
のようなメソッドを定義しておける、四角であれば、
nitWithSquare:(float) hsize vertical:(float) vsize position:(CGPoint) centerposition
のようなメソッドを定義できれば、インスタンスを生成する側でコードを減らすことができて便利です。
このように、インスタンスを生成するときに、同じクラスでも様々な種類のインスタンスを生成する必要がある場合は、クラスメソッドとして定義すると随分とやりやすいことが実感できました。
CoreData で Entity を subclass 化すると 4 ファイル作成されるようになった
CoreData で Entity を新設したらファイル一覧で右クリック、New File... します。
その後、テンプレート選択画面になるので、Core Data、NSManagedObject subclass を選択し Next ボタンを押します。
すると、新設した Entity を元にして、.m, .h ファイルが作成されます。
これまでは、2 ファイル作成されていたのですが、いつの間にか 4 ファイル作成されるようになりました。
...+CoreDataProperties.h と ...+CoreDataProperties.m が新しく作成されたファイルです。
いわゆるカテゴリ化されたファイルです。
中身を覗いてみると、Entity で定義した Attribute を property にしていることがわかります。
これまでは、Entity 独自の method を書いて、その後、Attribute に変更を加えてしまったとしたら、property を手で追加する必要があったのですが、Attibute を別ファイルに書き出すようになったので、変更後ファイルを再作成すれば property として書き出され、別ファイルに書いた method は消えてしまわないということかな。
便利だけど初め意味わからなかった・・・
