日本語の変換中に、下線が一瞬で消える — 自分のコードを全部外しても直らなかった不具合を、1か月かけて潰した — 制作日誌 #33
制作日誌

日本語の変換中に、下線が一瞬で消える — 自分のコードを全部外しても直らなかった不具合を、1か月かけて潰した — 制作日誌 #33

自作アプリで日本語を打つと、変換中の文字に付くはずの下線が一瞬だけ出て消える。純正のメモやLINEでは出る。自分の書き方を疑って3通り試し、全部だめだった。原因はアプリの土台そのものにあり、直す手順も途中で1回、効いていないのに効いたように見えていた。

KIYODO
#個人開発#アプリ開発#iOS#失敗の記録#制作日誌

紙に鉛筆で下書きをして、上からペンでなぞる。その途中で、誰かが毎回、紙ごと新しい白紙に差し替えてしまう。鉛筆の線は一瞬だけ見えて、すぐ消える。

日本語の入力で、変換が確定する前の文字には下線が付く。「ここはまだ下書きです」という印だ。自作のタスク管理アプリ「the task」では、この下線が一瞬だけ出て、すぐ消えていた。

例え実際
鉛筆の下書きの線変換中の文字に付く下線
紙を差し替える人アプリの土台が、文字の見た目を毎回貼り直す処理
差し替えをやめさせる土台の動きを、アプリ側から上書きする部品

例えが当てはまらない点が1つある。紙を差し替える人は悪意で動いているわけではない。土台は「文字の色や大きさを、画面の状態と常に一致させる」という正しい仕事をしていて、その副作用で下線が消えていた。

症状を並べる

困るのは、変換の区切りが見えないことだ。どこまでが確定済みで、どこからが変換中なのかが分からないので、長い文を打つと確定のタイミングを読み違える。タスクの名前を打つアプリなので、毎日触る場所だった。

比べると、こうなる。

打った場所下線
純正のメモ出る
Safari の検索欄出る
LINE出る
the task一瞬出て消える
同じ作り方の姉妹アプリ2本一瞬出て消える

同じ土台(React Native という、1つのコードから iPhone と Android のアプリを作る仕組み)で作った3本だけが、そろって消える。ここで「土台の問題かもしれない」とは思った。ただ、それを言い切る前に、自分の書き方を疑う必要があった。土台のせいにするのは、自分の側を全部外してからだ。

自分の書き方を3段階で外した

入力欄には、ふつう2つのやり取りがある。アプリが「今の文字はこれです」と欄へ渡す流れと、欄が「今こう打たれました」とアプリへ知らせる流れだ。どちらかが変換中の状態を壊している可能性がある。

そこで、開発用の画面に入力欄を3つ並べて、やり取りを1本ずつ切った。8月26日に実機で試した結果がこれだ。

欄アプリ→欄欄→アプリ下線
A渡す受け取る消える
B渡さない受け取る消える
C渡さない受け取らない消える

C は、アプリのコードが入力欄に何ひとつ関わらない状態だ。それでも消えた。

これで、書き方を変えて逃げる道は無くなった。同時に、もう1つ確定したことがある。アプリには、焼き直さずに中身だけ差し替えて配る仕組みがあるが、その仕組みで届くのは画面の動きを書いた部分だけだ。今回の原因はそこではない。差し替え配信では絶対に直らず、有料のビルドを焼き直すしかない。

原因の場所

土台を作っている側の公開の不具合一覧を探すと、同じ報告が見つかった。土台が新しい描画の方式に切り替わった版(0.76)から、ずっと起きている。描画のたびに文字の見た目を同期して貼り直すので、iPhone が持っている「変換中」という状態がその都度壊れる。

調べた時点で分かったことは3つある。

  • 修正案は公開されていた。しかし取り込まれていない(8月25日に実測。状態は「未完了」、取り込み「なし」)
  • 別の報告は「閉じた」になっていたが、理由は「対応予定なし」。返信が無くて自動で閉じられただけで、直ってはいない
  • 「その修正はもう取り込まれた」と書いている記事があった。実測すると誤りだった

さらに、悪い条件が1つ重なった。当時使っていた土台の版(Expo 54)までは、新しい描画方式を切る設定が残っている。次の版から先はその設定が消え、常に新方式になる。つまり、土台を上げた瞬間に「方式を戻す」という逃げ道は消える。

取れる手は3つあった

案中身代償
1新方式を切って焼き直す新方式が前提の部品があると起動しない恐れ。土台を上げられなくなる
2入力欄を iPhone 純正の部品で包んだものに差し替える入力がやや重くなる。37か所の欄を張り替える作業
3取り込まれていない修正案を、自分のアプリに当てる当たるか、ビルドが通るかが分からない

3を選んだ。当たれば、描画方式を戻さずに直る。

修正案の本体は3つのファイルの書き換えだった。ファイルの置き場所を自分のアプリの中の場所に組み替えて当てると、11個の塊のうち10個はそのまま当たった。位置が少しずれていただけだ。残る1個は、自分が使っている版とは前後の文脈が違っていたので、2行足して手当てした。できた差分は348行になった。

「この言語のファイルには、この当て方は使えない」と書いている記事もあった。しかしアプリにはすでに、同じ言語のファイルを書き換える当て方が1本動いていた。これも記事の誤りだった。

ここで止まった。差分は作れたが、ビルドが通るかは焼かないと分からない。手元の Windows ではこの言語をコンパイルできない。有料のビルドを1本使うかどうかは、この時点では「まだ焼かない」と決めた。

土台を上げたら、当て方が死んでいた

9月23日、別の理由で土台を Expo 54 から 57 へ3世代上げた。前の章で書いた通り、上げると「方式を戻す」逃げ道は消える。残るのは3の当て方だけだ。差分を新しい版に合わせて作り直し、ビルドの記録にも「当てた」と出た。

ところが、焼き上がった版を実機で打つと、下線は出なかった。

ビルドの記録をさかのぼると、書き換えたはずのファイル名が、コンパイルの記録に0件だった。新しい土台は、本体をあらかじめ組み立て済みの形で取り込む。中身を書き換えても、その中身はもう一度組み立てられない。「当てた」は本当で、「使われた」は嘘だった。

確認した所見えたもの
差分を当てる処理の記録成功
コンパイルの記録対象ファイルが0件
実機下線が消える

本体を毎回ソースから組み立てる設定に切り替えれば、当て方はまた効く。ただしビルドが毎回長くなる。これは採らなかった。

当てる場所を変えた

代わりに、アプリ側に小さな部品を1つ足した。アプリが起動した時に、土台の中の該当する処理を、修正案と同じ動きの処理へ差し替える。土台の本体には触らないので、組み立て済みかどうかに左右されない。

1つだけ決めごとを入れた。差し替え先が1か所でも見つからなければ、何もしない。開発中のビルドではそこで止める。土台をまた上げた時に、静かに効かなくなるのを防ぐためだ。前の失敗が、まさに「静かに効かない」だった。

これをビルド89に焼き込んだ。今度はコンパイルの記録に部品の名前が載っていた。その後、実機で日本語を打って、変換中の下線が残ることを確かめた。

振り返り

8月26日の切り分けから、実機で直るまで1か月かかった。かかった理由を並べると、技術の難しさより、「確かめた」と思った所が2回すり抜けていたことの方が大きい。

1回目は、記事の記述だった。「もう直っている」「この当て方は使えない」の2つとも、実測すると違った。

2回目は、自分のビルドの記録だった。「当てた」と出ていても、それが組み立てに使われたかは別に見る必要があった。

次に土台を上げる時は、差し替え先の存在を最初に確かめる。修正案が取り込まれる見通しは、今も立っていない。

コメント (0)

まだコメントはありません。最初の一言を残しませんか?