お疲れさまです。
APP/UI チームの玉置です。
最近のマイブームは鬼滅の刃 (きめつのやいば)です。ツイッター のタイムラインで鬼滅の刃 のワンシーンを見てしまい「おっ、刀がメインのアニメか！」と思ってNetflix で動画を見始めたのがきっかけです。るろうに剣心 」の十本刀の「宗次郎」にとても似ていてそのシーンだけで気に入ってしまいました。
そんなこんなで動画を見つけた日は善逸くんの上記のシーンまでの動画を徹夜で観ていました。
さて、そんな話しは置いとくとして今日は先月ずっと行っていた
リプレイスする前に使っていたライブラリについて
リプレイス前に使っていたライブラリは「JSQMessagesViewController 」という名称のものです。
github.com
2016年頃まではチャットアプリでごく一般的に使われていた有名なライブラリです。
github _commit_log
現在は非推奨となっています。pod installをした際にこのライブラリが非推奨というワーニングが表示されます。
depricated_JSQMessagesViewController
今はチャットライブラリで有名なものとして「MessageKit 」というOSS があります。
github.com
今回はこの「JSQMessagesViewController」からの脱却をメインに書いていきます。
リプレイスするきっかけと足枷になったこと
本当はすぐにでもJSQMessagesViewControllerを脱却したい気持ちがありました。
その理由を挙げるだけでも
2017 年から公式が非推奨
公式からのサポートが得られない
事業的にリファクタリング よりも新規機能の開発が優先
リファクタリング のコストを支払っても利益が出ないため報われないリプレイスにかかるコスト(工数 見積が定かではない)
iOS のライブラリ管理ツールである「CocoaPod」からdepricated というワーニングが表示
などの要因がありました。
最後の1行のメッセージの空白
この問題に対して臨時対応を5月頃に実施して解消されているはずでしたが今年8月にも別のユーザー様から同じような問い合わせを受けてしまいました。
そのため使っていただいているユーザー様のためにもできるだけ早くこの問題の根本原因を解消しなければならないと思い、リファクタリング 期間を頂いたのでこれを機会にチャットUIライブラリを差し替える業務に本格的に着手することにしました。
リプレイスする上でのツラミ
実際にライブラリのリプレイスをすると決意してからが大変です。デグレ に気をつけなければなりません。
開発メンバーに申し訳ない感
iOS のキーボードが意図通りに表示してくれない差し替えたあとにiPad 横画面でデグレ が起きる
という三点でした。
それぞれ解説していきます。
開発メンバーに申し訳ない感
こちらはリプレイス云々とは関係ありませんが事前に工数 見積をしていても全てが事前に見積もれる訳ではありません。デグレ が発生している方が問題になります。
「デグレ 」と「捨てて良い機能」の定義はタスクや機能によって違いますが、
それはそうとして話しを戻しますがインパク トを直接与える作業ではないのであまり楽しくなかったんですよね。
なので自分が楽しくないことにひたすら挑戦していたので(おまけに事業の売上に貢献していないことも含めて)
このツラさを解消できるKPT でいうところ、「Try」があればいいなと思いました。リファクタリング が楽しいものになるんだろうなと思いました。
iOS のキーボードが意図通りに表示してくれない
後述する内容ですがリプレイス先の「MessageKit」のInputBarAccessoryViewがうまく意図通りに動いてくれなかったため、全ての挙動を既存仕様に合わせることが難しかったです。iPhone ・iPad に関わらず大変で着手中ずっとキーボードの制御に苦しめられました。childViewController になっています。
(main) RoomViewController > MenuViewController > ChatViewController (child)
という設計になっています。
この場合は ChatViewController で MessageKit のInputBarAccessoryViewを表示しようとすると初期表示時にInputBarAccessoryViewが画面外に隠れてしまう現象が起きます。
InputBarAccessoryViewが画面下にあるので表示されない
このような問題にも対応しなければなりませんでした。
念の為、この問題を解消するのに参考になったページを張っておきます。
github.com
github.com
差し替えたあとにiPad 横画面でデグレ が起きる
最後のツラミとして、今年5月頃に私が開発したものですがiPad のレッスンルームを横画面にも対応したのですが、MessageKitがそのあたりもいい感じに補正してくれると期待していたところ見事にそれを裏切ってくれました。
iPhone でだいたい既存の同じ挙動になることを確認してからデグレ 起きなかったらいいなと淡い期待を持っていましたが、
単純にJSQMessagesViewControllerからMessageKitに差し替えてもiPad を横画面にすると既存と全く同じ挙動にならなかったのです。工数 見積をしましたが、iPad 横画面ではその当時確認していませんでした。できなかったこともありますが。工数 見積を行いました。
着手前に見積もっていた工数 も残りわずかというか使い切ってしまいましたので、iPad 横画面でのデグレ 箇所の工数 見積をしていました。
想定外のデグレ の工数 はメンタルに良くないですね。
実際のリプレイス作業
ということで長々と書いてしまいましたが、ここで実際にライブラリをリプレイスしたときに行った手順を復習します。
ライブラリ自体の調査と挙動の調査 (工数 見積まで)
アプリの既存の動きの調査
MessagesKit自体のデザインの調査
MessagesKitがどこまで柔軟に対応できるか
試しimport でどれだけのデグレ が発生しているか
実際にライブラリをimportする (実際に着手開始)
MessageInputBar が使えず、InputBarAccessoryViewが必要
どのバージョンのInputBarAccessoryViewを使えばいいのか情報が少ないのでその調査を行う
そのためcocoapodのPodfileは下記のようにInputBarAccessoryViewをimportしました。
pod 'MessageKit'
pod 'InputBarAccessoryView', '4.2.2'
ハマリポイントの改修 (想定外の対応)
ChildViewControllerでは初期表示時にInputBarAccessoryViewが表示されない
レッスンルームを一つのViewController で管理できるかの調査 (既存設計を大きく変える方法の調査)
メインのViewController で becomeResponder()を読んでinputBarを意図的に表示させたときの調査 (既存設計を踏襲する場合の調査)
iPad 横画面でのデグレ の対応
上記のような流れになりました。
レガシーコードと向き合った感想と気をつけるべきこと
今回はレガシーコードではなくライブラリのリプレイス作業について解説してみました。インパク トを与えられますがレガシーなものを新しいものに書き換えるようなリプレイス作業は見た目が変わらないので作業していてもなかなか辛い部分がありました。
ですがレガシーコードは綺麗にせずにそのままにしておくと将来の負債となったりメンテナンスできなくなって「ゼロから作り直し」になったりする非常にセンシティブな部分でもあったりします。ソースコード を「１から作り直し」になってしまった所もあるのではないでしょうか。
またApple やGoogle のSDK が年々新しくなって昔のソースコード がいきなり非推奨になったりします。ソースコード を綺麗にして保守性を上げる開発体制が一番安全かなと思いました。
今回のチャットUIを新しくしたことでレアジョブアプリを使って頂いているユーザー様により快適にレッスンルームをご利用頂けると思うと開発者として報われる気持ちになりますね。
ということで長文になりましたがぜひレッスンルームを使って頂ければと思います。
大カテゴリ、中カテゴリ、タイトル、テキスト、イメージなど早い話が仕分けですね！
余白を入れてグループとグループの間を空けます これだけでだいぶ見やすくなりました！
分けた要素はグループごとに同じ見た目に、
