Slashcolon /:

Bluetooth経由で携帯電話からダイヤルアップ接続を行うためにBluetooth周りを調査。

採用している実機には、TOSHIBA製のBluetoothスタックが搭載されているのでAPIの説明書を読む。Bluetoothのスタックは、どうも過渡期のようで数種類乱立してるっぽい。Microsoft製なら、WinSockからも扱えるのになぁ～などど恨めしく思いつつ

MSがサボってたおかげで、TOSHIBA製は結構なシェアがあるっぽい。しかし、Google先生に聞いてもあまり情報がないので、サンプルプログラムとAPI説明書を紐解くしかない。API説明書は当初英語版しかなかったけど…一応、日本語版も入手できた（なぜか英語版の直訳なんだけどね ）。サンプルプログラムもAPIをちゃんと網羅していて悪くない。

そう入手できる情報量としては、非常に良い部類だろうと思う。だけど

APIの設計自体がどうにもイタダケナイ

イタダケナイ理由を思いつくまま列挙してみる。モチロン自分のことは棚上げね

• BtHogeHoge2と新APIに2をつけて、2なしは互換性のために残している
  後方互換性を維持するのはわかるし、重要だと思うけど…2は萎える。
• 非同期APIがチラホラある（このチラホラってのが萎える）
  処理に時間がかかるので、終了したらウィンドウメッセージを投げてくる非同期APIがある。理由はわかるけど。
  時間かかっても同期で呼び出せる方法があっても良いんじゃない。同期、非同期が区別しにくい、API名とか説明書とかもう少し工夫して欲しい。
• 引数がやたら複雑
  一部のAPIの引数が構造体の中に構造体さらに…って感じで、まるでマトリョーシカ人形 のよう。あと、リストが多く。メモリ解放などにも責任を持たないとイケナイ。

要するにAPIのバランスが非常に悪いのだ。

例をあげると、RFCOMMレイヤで使うSCN（Service Channel Number）を接続相手から取得するために単純なAPIと複雑なAPIを合わせて8個も呼び出さないとならない。さらに、その8個のうちの2個が非同期。3個はマトリョーシカ人形。

もう面倒くさいったらありゃしない。最終的に取得したいSCN値って、単なる整数値ですよ しかも、今回の場合接続相手が携帯電話なので機種が同じなら…たぶん、固有値なのに。

APIには可能な限り対称性を持たせましょう。APIは可能な限りシンプルにしましょう。APIは…。あぁ～言いたいことは一杯あるけど…

このブログで関連すると思われる他の投稿

• C#のTcpListenerでハマるorz
• JUDE 5.4正式リリース…サポート対象外のサンプル機能が面白い
• Winsockが壊れた？
• ALT+Tabチックなプログラムを書く…切替タスク取得編
• ALT+Tabチックなプログラムを書く…オナードローCListBox編

Comments(2)       

TrackBack URL :