✖
NanoVNA WebApp の Android アプリ化
Capacitor をつかって NanoVNA-Web-Client を Android アプリ化してみた。
あんまりハマりどころはなかったのでそれほど書くことはないけど、いくつかメモ。
node_modules
アプリサイズを減らすためにできるだけリソースを減らす必要がある。node_modules 以下を雑に入れると数十MBになってしまうので、気をつける。
Web 版のリソースを完全にそのまま入れるより、必要なリソースだけをコピーするようなビルドスクリプトを書いたほうが良さそう。今回は Makefile でなんとかした。
splash 画像の生成自動化
Ionic のブログに Photoshop template があるので、これを利用させてもらう。
が、ブログの通り cordova-res を使うとうまくいかなかったので、Makefile と ImageMagick でなんとかした。
res: convert images/splash.png -gravity center -resize 480x320^ -extent 480x320 ./android/app/src/main/res/drawable/splash.png convert images/splash.png -gravity center -resize 800x480^ -extent 800x480 ./android/app/src/main/res/drawable-land-hdpi/splash.png convert images/splash.png -gravity center -resize 480x320^ -extent 480x320 ./android/app/src/main/res/drawable-land-mdpi/splash.png convert images/splash.png -gravity center -resize 1280x720^ -extent 1280x720 ./android/app/src/main/res/drawable-land-xhdpi/splash.png convert images/splash.png -gravity center -resize 1600x960^ -extent 1600x960 ./android/app/src/main/res/drawable-land-xxhdpi/splash.png convert images/splash.png -gravity center -resize 1920x1280^ -extent 1920x1280 ./android/app/src/main/res/drawable-land-xxxhdpi/splash.png convert images/splash.png -gravity center -resize 480x800^ -extent 480x800 ./android/app/src/main/res/drawable-port-hdpi/splash.png convert images/splash.png -gravity center -resize 320x480^ -extent 320x480 ./android/app/src/main/res/drawable-port-mdpi/splash.png convert images/splash.png -gravity center -resize 720x1280^ -extent 720x1280 ./android/app/src/main/res/drawable-port-xhdpi/splash.png convert images/splash.png -gravity center -resize 960x1600^ -extent 960x1600 ./android/app/src/main/res/drawable-port-xxhdpi/splash.png convert images/splash.png -gravity center -resize 1280x1920^ -extent 1280x1920 ./android/app/src/main/res/drawable-port-xxxhdpi/splash.png optipng $(wildcard ./android/app/src/main/res/*/splash.png)
Play Store のメモ
リリースしたことある気がしていたが、よく考えたら前職で数回やっただけなので個人のアカウントではやったことがなかった。いろいろストアの使い勝手が変わっていた。
- 初回の審査は結構時間がかかる。一週間ぐらい? 更新の審査は割とすぐ。
- 要求される画像がいっぱいあってだるい。全部埋めないとベータ版すらリリースできない
- adb という仕組みができていた。(端末にあわせて必要なリソースだけを含む apk を自動生成する)
無料アプリの開発者視点からすると、別に Play Store に出すメリットはぜんぜんない。他の端末にさくっと入れたいときに便利かな、と思う。けど、それも普通にウェブサイト経由で .apk ダウンロードして入れればいいだけなので、それほど致命的に面倒くさいわけではない。まぁ Play Store のショバ代は初回に $25 なので Apple (毎年$99もとる) よりは格段に優しいといえる。
✖
NiZ Keyboard PLUM からキーマップや打鍵回数を読み出す
NiZ のアプリケーションは Windows 向けしかない。プロトコルが気になったので、とりあえず打鍵回数を読み出すところをまでをやってみた。環境は macOS で hid_api gem を使い、Ruby で書いた。
できたもの
実行するとこういう出力をする。最後の数字がキーに対応するカウント。
key= 1 hwcode= 1 ESC: 35 key= 2 hwcode= 15 1: 66 key= 3 hwcode= 16 2: 92 key= 4 hwcode= 17 3: 114 key= 5 hwcode= 18 4: 119 key= 6 hwcode= 19 5: 53 key= 7 hwcode= 20 6: 99 key= 8 hwcode= 21 7: 18 key= 9 hwcode= 22 8: 115 key= 10 hwcode= 23 9: 76 key= 11 hwcode= 24 0: 171 key= 12 hwcode= 25 -: 307 key= 13 hwcode= 26 =: 78 key= 14 hwcode= 41 \: 38 key= 15 hwcode= 14 `: 33 key= 16 hwcode= 28 TAB: 575 key= 17 hwcode= 29 Q: 253 key= 18 hwcode= 30 W: 627 key= 19 hwcode= 31 E: 1461 key= 20 hwcode= 32 R: 911 key= 21 hwcode= 33 T: 1137 key= 22 hwcode= 34 Y: 616 key= 23 hwcode= 35 U: 1317 key= 24 hwcode= 36 I: 1662 key= 25 hwcode= 37 O: 1536 key= 26 hwcode= 38 P: 549 key= 27 hwcode= 39 [: 584 key= 28 hwcode= 40 ]: 41 key= 29 hwcode= 27 BS: 1662 key= 30 hwcode= 67 L-CTRL: 18 key= 31 hwcode= 43 A: 1794 key= 32 hwcode= 44 S: 914 key= 33 hwcode= 45 D: 853 key= 34 hwcode= 46 F: 249 key= 35 hwcode= 47 G: 520 key= 36 hwcode= 48 H: 828 key= 37 hwcode= 49 J: 671 key= 38 hwcode= 50 K: 1424 key= 39 hwcode= 51 L: 696 key= 40 hwcode= 52 ;: 452 key= 41 hwcode= 53 ': 155 key= 42 hwcode= 54 RET: 1281 key= 43 hwcode= 55 L-Shift: 1610 key= 44 hwcode= 56 Z: 177 key= 45 hwcode= 57 X: 128 key= 46 hwcode= 58 C: 459 key= 47 hwcode= 59 V: 253 key= 48 hwcode= 60 B: 384 key= 49 hwcode= 61 N: 1352 key= 50 hwcode= 62 M: 482 key= 51 hwcode= 63 ,: 383 key= 52 hwcode= 64 .: 255 key= 53 hwcode= 65 /: 161 key= 54 hwcode= 66 R-Shift: 850 key= 55 hwcode= 156 R-Fn: 135 key= 56 hwcode= 67 L-CTRL: 1653 key= 57 hwcode= 166 L-Fn: 6 key= 58 hwcode= 69 L-Alt: 35 key= 59 hwcode= 68 Super: 703 key= 60 hwcode= 70 Space: 2037 key= 61 hwcode= 68 Super: 7 key= 62 hwcode= 71 R-Alt: 5 key= 63 hwcode= 74 R-Ctrl: 5 key= 64 hwcode= 88 Left Arrow: 24 key= 65 hwcode= 89 Down Arrow: 19 key= 66 hwcode= 90 Right Arrow: 34 key= 67 hwcode= 0 : 0 key= 68 hwcode= 0 : 0 key= 69 hwcode= 0 : 0 key= 70 hwcode= 0 : 0 key= 71 hwcode= 0 : 0 key= 72 hwcode= 0 : 0 key= 73 hwcode= 0 : 0 key= 74 hwcode= 0 : 0 key= 75 hwcode= 0 : 0
プロトコルの概要
すべて HID 上で行われる。64bytes 固定で read/write する。
日本語で説明するよりソースコード読んだほうが早いので説明するのをやめる。
カウントを得るためにすること
キーマップを得る
NiZ キーボード側から、現在のキーマップを取得する。66キーのモデルなので、66キー × 3レイヤー (ノーマル・左Fn・右Fn) で 198 個の論理キー定義がある。
これによって、キーID (1〜66) と、割当られているキーコード (.pro ファイルの HWCODE) のマッピングを得られる。
カウント一覧を得る
カウントは66個の数値の配列のようなものが得られる。インデックスがそれぞれキーIDに対応していると思われる。
インデックスからキーマップを得てカウントと共に表示すればおわり。
備考
macOS だからか、実装が悪いのか、どこが悪いのかわからないが、挙動が不安定
- HidApi.open がしばしば失敗する
- read に失敗する (タイムアウト)
何回か繰替えすと成功する。
hid_api
hid_api は timeout のメソッドがあるにも関わらず timeout の処理が抜けているので、モンキーパッチを書いてる。PR 作ろうかと思ったけど結構放置されてそうでめんどい。
macOS でもキーマップを書きかえたいんだけど???
read した形式で書き戻せばいいだけだと思う。
どうやって解析したか?
Windows に USBPcap を入れて、公式のアプリケーションを操作しながらログをとった。
あとは気合
ソースコード
https://github.com/cho45/niz-tools-ruby github にうつしました
>
このエントリを参照するエントリ
✖
NiZ Keyboard PLUM という静電容量無接点キーボード
(この写真のキー配列はデフォルトのものではなく、既にカスタマイズ済みです。mac 用のキーキャップが付属しており、HHKB を基準にできるだけキーキャップもあわせています)
3行で
- 信頼性のあるキーボードがほしいなら買わないほうが良い
- 打鍵感は十分に良い
- これにしかない魅力はある
NiZ というキーボード
https://www.nizkeyboard.com/ が公式っぽい。中華製の静電容量無接点キーボード (HHKBやRealforceなどと同じ分類)。
HHKB と比べると以下のような特徴がある
- 35g / 45g を選べる。35g モデルでも 10g 増やすバネで、特定のキー(ホームポジションとか)だけ荷重を増やせる
- HHKB は 45g キーストローク 4mm
- キー数のバリエーションが多い
- 完全にキーマップをカスタマイズ可能 (ファームウェアレベルで行う)
- Type-C コネクタ (mini-B よりも機械的に丈夫なコネクタ)
- Bluetooth 接続対応・バッテリー内蔵
- 価格は若干安い
価格が安いだけなら買うつもりはなかったけど、キーが HHKB よりも軽くて Bluetooth 接続が可能で、Type-C 接続な点で気になった。66キー(HHKBとほぼ同じ大きさ) 35g のモデルを買ってみた。スペック通りなら HHKB 信者を止めることになる。
初期設定とハマったところ
デフォルトだと「Office モード」というモードらしく、キーのリマップが効かないモードになっている。 Fn+M キーを同時に2秒押して Program モードというモードにしなくてはいけない。
専用アプリを使ってのキーカスタマイズはこのモードでしか適用されない。
キーが効きにくい……
試しうちしてすぐ気付いたが、左 Ctrl (というか位置的には Caps-Lock)、スペース、RET、Shift が叩くように入力しないと反応しない、または普通に使っていて入力をとりこぼすことがわかった。
https://www.nizkeyboard.com/2019/07/07/some-keys-doesnt-work-look-at-this/ 公式にこういうエントリがあるぐらいなので頻出問題みたい。手順では F2 F10 を押しながらキャリブレーションすると書いてあるけど、単に基準となるキーが変わるだけで、どのキーを押しながらでもキャリブレーションできる。自分の場合は左 Shift + スペースを軽く押しながらキャリブレーションすることで、気になる範囲の取りこぼしはなくなった気がする。
キーボードの信頼性
市販のキーボードは「普通に動く」けれど、それはもうそれだけですごいのだ、ということに気付く。キーボードの信頼性というのはそこで、普段意識するようなことはない。最低限ちゃんと思った通りに入力できなければならない。
NiZ は(自分の場合は)キャリブレーションなしには全く使いものにならないものだった。普通に考えたら初期不良だし、キーボードをキャリブレーションしたらなおるとか思いもしないだろう。そういう初期調整も含めての安価な値段だと思う。
NiZの良い点
良い点は冒頭でもほとんど記したけど
- 打鍵が軽い
- スコスコしたスムーズな打鍵感
- 打鍵音が静か (HHKB と比べると雲泥の差)
- カスタマイズ性
- Bluetooth
とかいろいろある。このキーボードにしかない特徴があるので、うまくキャリブレーションするか、あたり個体を掴めれば良い選択かもしれない。
とりあえず普段遣いできる感じのキャリブレーションはすることができたので、しばらく使ってみるつもり。
細かいメモ
USB デバイスとしては `ID 0483:512a STMicroelectronics 66EC-S ` で認識されている。STM32 っぽい……と言いたいところだけど、中華デバイスは STM32 互換の MCU に STM32 のツールで作ったファームウェアを書いていたりするので、これだけでは判断できない。