Motohiro Takayama

BlueTooth Headphone for running

@mootoh 腰ベルトはなんだかなあ。。いい感じのBluetooth Earphoneなんでしたっけ？

March 31, 2013

最初に使ってたのは Jabra CLIPPER. 手持ちの有線イヤフォンを無線化できるのがよい。丸首 T シャツなんかの首周りにつけてた。音飛びもほとんどしなかった。難点は、クリップが固くてを挟むのに苦労すること、けっこうディレイがあること (Youtube とか見てると lip sync しない)。 新型が出てる ので試してみては。

次に使ってたのは Motorola S10. 一体型であり、人によっては頭の形に合わないかもしれない。自分にはうまくフィットしなかった。しばらく使っていたら電源が入らなくなって放置してる。

いちばん最近使ってるのは、 DENON の AH-W150BU Exercise Freak In-Ear Headphones. かっこいいし、バンドが紐状なので頭の形に左右されない。そこそこフィットする。Bluetooth 3.0 だからなのか、 iPhone から電池残量が見えたりしておしゃれ。ただし、腰ベルト なんかに iPhone 5 を入れて走ってるとすさまじく音飛びする。肩近くに iPhone 5 をもっていって走ると音飛びしない。電波がだいぶ弱い感じ。じっさい

> For the best performance, you should avoid keeping your smartphone in your pocket while using your headphones, as Bluetooth connectivity can be weakened when your smartphone’s battery is low or when clothing or the human body blocks the signal. Wearing your smartphone in an armband can ensure better reception and make accessing controls easier.

とか書かれてある… 昨日 Nexus 4 から使っていたら、ズボンのポケットにいれてても音飛びしなかった。

みたいな感じです > @tksohishi

Setting Property is Case Insensitive

さいきんコードレビューで指摘されて首をかしげたこと。

lower case で始まる名前の property に値を代入するところで、 property name を upper case にしていた。 あーはいはいタイポタイポ、と思いながら、あれ? でもこれコンパイル通ってたじゃないの。それは奇妙だ。

ちゃんと動いているのか

% clang --version
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix

ふつうの clang さん。

% clang -Wall -pedantic -Wextra -c case.m

a.m:28:8: warning: unused variable 'a' [-Wunused-variable]
A *a = [A new]; // will show "Yay"
   ^
a.m:26:14: warning: unused parameter 'argc' [-Wunused-parameter]
int main(int argc, char **argv)
         ^
a.m:26:27: warning: unused parameter 'argv' [-Wunused-parameter]
int main(int argc, char **argv)
                      ^
3 warnings generated.

特に代入文に対する警告もなし。実行してみると

% ./a.out
2013-01-19 15:16:43.918 a.out[4980:707] value = Yay

ちゃんと代入されている。おやおや。

何がおこっているのか

clang に c++ のコードをはかせてみる。 (参考: @niw さんのNSURLConnection の深堀り話)

% clang -Wall -pedantic -Wextra -rewrite-objc -c a.m

出力はこんなのになり、 setter method は

static void _I_A_setLowercaseString_(struct A * self, SEL _cmd, NSString *lowercaseString) { ((struct A_IMPL *)self)->lowercaseString = lowercaseString; }

とつくられている。 setter method の呼び出しは

((void (*)(id, SEL, NSString *))(void *)objc_msgSend)((id)self, sel_registerName("setLowercaseString:"), (NSString *)&__NSConstantStringImpl_a_m_0); // use upper case in setter => ok

になった。なのでちゃんと lowercaseString に値が代入される。

clang はきっと

self.LowercaseString = ... を見て、ああこれは setter method, property name は LowercaseString, じゃあ setter method name は setLowercaseString, あぁあるある…

と考えているのだ。

じゃぁ混ぜると

lowercaseString と LowercaseString っていう property をつくってみるとまずいんじゃなかろうか。

% ./a.out
2013-01-21 13:28:54.279 a.out[11571:707] value = UPPER
2013-01-21 13:28:54.281 a.out[11571:707] value = (null)

ん、残念な結果になる。そもそもほとんど同じ名前の property をつくることはないと思うけれど…

今回コードレビューで指摘されたのは、幸いにも問題にはなっていなかった。テキストエディタのコード補完に頼っていた結果、 LowercaseString っていう class name と lowercaseString っていう property name の違いに気づかないのは、コードの意味を解析しないテキストエディタではありがちなこと。

Objective-C は一見単純なコードの下でいろんなことが起こっていて、下の層に潜って理解したい。しかし -rewrite-objc という clang のコマンドラインオプションは man clang してもでてこないもので、要するに探究心の強い友人がいると便利だという話です。

「夜は短し歩けよ乙女」には Tumblr に通じるものがあると思う。