こんにちはEveryDaySoft代表の永田です。
今回は2020年振り返りとプログラム要件における感想を綴ります。
企業様へフルコミットの結果、体力と技術を限られた時間で全部使って皆様への有益な情報としては、SwiftUIでの感想かと思います。 それしか現状残っていない状態です。
今年の参画した案件は3つ
Kotlinのpush通知関連 リモート業務
SwiftUI+Kotlin健康アプリ リモート業務
iOS Live配信案件 リモート業務
Kotlinのpush通知関連リモート業務
kotlinのpush通知案件はGoogleサービスを使用した内容です。これは機能を確認したのは１日で対応し、AndroidはAIを活用した省エネシステムで自動省エネモードが走るのですが、それをパーミッションで許可を得て、スリープモードでもPush通知を飛ばすといった内容でした。この案件と並行で、SwiftUIの案件に参画しました。
SwiftUIの課題
1.bindingにおける通信
2.単体パーツ毎に座標軸に差異がある
3.使用するライブラリーでプレビューが見れなくなる場合があり、効率が下がる
の3つです。
1.bindingにおける通信
大規模アプリで通信APIが３桁あるとします。通信を取得するシナリオが３桁あります。全てが疎結合で単体でのbindingで通信取得、データの更新をすれば問題ないでしょう。しかし３桁ぐらいのhuge状態になると必ずどこかとどこかが、影響します。その際にbind、bind、bindとなったらどうでしょう？どことどこが影響しているかってスパゲッティ状態でbind、bind、bindってなり、かなり手強いですね。解決策はアプリの保存機構はなくしデータ保存をAPIに持たせる。データ構造もAPIに任せる。(アプリ側でデータ構造を再構築しない)。SwiftUIはアプリでやる内容を極限まで絞る。
そうなると、とても早いアップデートが可能になると思います。
2.単体パーツ毎に座標軸に差異がある
グラフや罫線など単体では便利な部品の始まり座標origin(x:0,y:0)の場合、SwiftUIはyとxに差異があるデフォルトパーツがありました。それを全デバイスミリ単位で合わせるのは骨が折れました。ある部品は左上、ある部品は真ん中です。これはSwitch文のcaseで対応せざるおえませんでした。とても悔しい思いを今でも覚えてます。なのでいつか必ず技術ハックすると心に誓っています。
3.使用するライブラリーでプレビューが見れなくなる場合があり、効率が下がる
これは夏頃まで発生していた内容ですが、cocoapods経由のライブラリーの影響で見れなくなるような問題でした。プレビューが見れなくなるので、SwiftUIのスピーディーな能力が失われる形になります。これはサービス自体のライブラリーを使用している場合は、致し方ないかもしれません。これを解決するのは問題提起側が技術アウトプットを積極的に実施、技術力を世の中に認めてもらい、発言力を強くする努力を継続的にし続けなければ、根本的な改善スパイラルにはならないでしょう。
SwiftUIの良かった点
それでも早い。圧倒的に速いです。
具体的にはプレビュー画面を見ながら構築を進める形なのですが、慣れだすと技術サイトをみずにコーディングをデザインツールを見ながら１０数分ぐらいで構築できます。基本的なパーツの場合は全デバイス合います。SwiftUIにはないパーツをUIkitと合わせて表現する場合はいきなり難易度はライブラリー構築レベルまで上がりますが、、。
それでも早い。圧倒的に速いです。
iOS <-> Kotlinの Switchスタンス
かなりスクラム案件で反復横跳びのように右から左に一気にデザインを変えたりするので、基本的に速攻で何でも作れますよって感じじゃないと、仕様と技術に呑み込まれ潰れたかもしれません。これに加え、Androidエンジニアのチームに加わり、コア画面を作成しました。みんな本気で攻めていたので、燃えましたね。朝から朝まで何度も燃えてました。Androidでグラフィックカラーや特殊グラフを表現するのも昔のjavaコードを引っ張ってKotlinに少し改造したり、メモリー使用量を上がらないようにしたり、チームのアーキテクチャを夜通し確認してチェックして翌日の朝には課題を共有したり、とにかく燃えてました。そうしている中で、またiOSに戻り、bind連続したアーキテクチャを変更したり、仕様追加に伴いデータ構造を作成したりしました。
ture,false(画面非表示、画面表示)というシナリオパターンが３桁発生する場合に、一つの画面をtrue,falseすれば全部なるというのが、進みながら、少なく実装するのは本当に難しいと思いました。もっともっと修行して、圧倒的にハックすると心に誓っています。
１ヶ月休暇
リモートで週７で朝から晩まで毎日開発を進めていると、精神も肉体もボロボロになり、足し算ができなくなります。それでも３桁パターンと期日があるんです。今思えば極限状態でしたが、それが現実で数年間の修行の継続の結果、無意識にコードを書く事がいくつか出来ます。なので、ギリギリアウトラインにはいかなかったんだと思います。日頃の積み重ねがなかったら、完全に潰れた夏だったと思います。
9月は１ヶ月休暇になりましたが、開発は毎日進めて、Aws経由のPush通知をAPIでCRUDのロジックを作成したり、Pythonで翻訳をした内容をアプリのチャット機能にのせたりした内容を勉強会で発表したりしました。
iOS Live配信案件 リモート業務
デザインを見た時、機能要件を全開に盛り込んでるような案件で、これは大変だなと思いました。あと半年はかかる内容です。
僕は、Zoomのようなテレビ複数画面を縦から、横に移動しながらアニメーションさせたり、投げ銭のようなアニメーションを作成したり、配信確認をしたり、自動化のTestFlight設定したり、FireBaseのログ設定したり、360動画ライブラリーを改造し、正しい仕様に変更したり、動画の回転した際に、相手が画面回転をロックしてる場合に画面向きが横向きになってしまう事象がありました。skype等の様々なアプリの案内では自デバイスの画面ロックをOFFにしてくださいという内容だけでした。自作ライブラリーを作成して、タップして補正するという機能を作ったり、自由にやらせてもらいました。
https://github.com/daisukenagata/RotationFaceDetection
出来なかった事
そんな中でテレビ動画ライブラリーを使用している影響で、配信動画とテレビ動画ライブラリーの音声を綺麗にオーバーライド出来ない状況にぶち当たりました。もしかしたら、Objective-cなら出来るのかもしれません。
僕の答えはライブラリーのカプセル化されたprivate Methodをopen修飾子に改造し、ライブラリー機能自体で変更するという内容でした。
音声ボリューム機能をライブラリーで用意すれば可能だと思っているのですが、規模が大きいし、いろんなエンジニアが関わるので、組織ぐるみで決めなくてはいけない内容です。一人の力では限界を感じ、とても悔しい思いになり、音声実装能力をもっともっと高めると心に誓いました。
今年について
3案件の企業様、皆様、厳しい中、筋を通し一緒に働かせて頂いた事に誠に感謝しています。
コロナ禍、IT業界はリモートで仕事できます。だからIT業界も本気で日本の経済を回せるように頑張るのが筋だと思っています。しばらくは、個人の時代になると思いました。
来年から
音声系の案件に参画します。
全力で精進し、貢献できたらと思っています。
1月4日までに本気で準備します。
貴重なお時間お読み下さいまして、誠に有難うございます。