Fluttereエンジニアがいつか経験すること
パッケージではできないことをやる日が来る
こんにちわJboyでございます。技術の話もしつつ今日はポエムみたいにな記事を書きます。あまり面白くないかも。
Flutterエンジニアは、流行りの技術を学び続ければ良いと思ったが現場によっては、流行りのものを使わないところもあります。人によってはレガシーだ面白くないと思うでしょう。
レバテックフリーランスを使って、優秀な営業さんが面談組んでくれた自社開発企業から案件のオファーをいただきました。今までは、自社開発もどきの助成金目当ての企業やIT企業とは呼べないところでしか働いたことないので、嬉しいようで不安もありました。
他の現場に行くと新しい技術が導入されている可能性は高いので、Riverpod、GoRouter、AutoRouterを学んでおくといいでしょう。
しかしパッケージを使うのを控える現場もたまにあります。自社開発が良い例かもしれません。
なぜ使うのを控えるのか？
- 破壊的変更が出たときに対応するのが大変💦
- Flutterだと使えない機能がある💦
- Swift、Kotlinのコードで機能実装してメソッドチャンネルで呼べば解決できる💡
- 他の企業に兵器みたいにライセンス生産した物を提供している🚀
Flutterはクロスプラットフォームです。iOSとAndroid両方の開発ができる。ということは、オリジナルであるSwift、Kotlinのコードを呼び出すことができたりする。
プラットフォーム固有のAPIを呼び出すどうだ。
過去に実験で作ったものがある。
どのような場面で使うのか？
Flutterはセンサー系が弱いらしくSwiftとKotlinでロジックを作って、呼び出してうまいこと使わないといけないらしい。
例があるとしたら、体重計、スマートロック、GPS...
Xamarinの案件を昔やっときに、BLEなるものを知りました。
BLE（Bluetooth Low Energy）は、Bluetoothの拡張仕様の一つで、低消費電力で機器間の通信を行う無線通信規格です。
BLEの主な特徴は次のとおりです。
低消費電力：従来のBluetoothと比較して消費電力は約2分の1で、コイン電池1つで数年間稼働することが可能です。
2.4GHz帯の周波数を使用：2.4GHz帯の周波数を2MHzの幅で分割して40個のチャンネルとして利用しています。
スマートデバイスとの親和性が高い：ワイヤレスのヘッドセットやマウス、キーボードなどの周辺機器、スマートホームシステム、医療、フィットネス機器など、多岐にわたるデバイスで使用されています。
BLEの仕様定義には、プロトコルとプロファイルの2種類があります。プロトコルはすべてのBLEデバイスが利用する定義、プロファイルは特定のBLEデバイスで利用されるデータの送受信定義やユースケースが含まれます。
BLE通信では、ペアリングを実施することで通信内容が暗号化されます。ペアリングを実施しない場合、通信内容は平文（暗号化されていない状態）でやり取りされるため、通信内容を傍受される可能性があります。
Streamを使用して、流れてくるデータを取得してそれをViewModelのようなものに保持させて、グラフに描画したりして、UIに表示する。FutureBuilderを使ってfl_chartに直接表示するわけではないらしい？
グラフは流石に自作は大変だ💦
Riverpodは使うが頼りすぎない
やりたいことは、ネイティブのコードを呼び出して使うこと。RiverpodのプロバイダーやState管理があまり出番がないなら、StreamBuilderやオブジェクト指向でコードを書くだけで十分だったりする。標準機能で頑張る💦
自社開発の特徴っておそらくモダンな技術を使ってるのをアピールする企業と、安定した技術で自社の製品をメンテナンスし続けて、ビジネスを成功させるのが目的なのに分かれると思う。
でも他の現場だとそうはいかなかった
たまに人と話して、こんなこと言われます。
- Riverpod必要ないならいらないと思いますけどね。
- なんでみんなFirebaseでアプリ作るんだろう〜
そんなの決まってる。給料払う奴が決めたからだ(^_^;)
今まで入った現場では、SESの現場だとモダンな技術構成とデザインパターンがありました。クライアントからいわせれば使用が決まってるのでキャッチアップしろと言われう。
私も昔は、GoRouterが嫌いでした。AutoRouteだってあまり情報ないので好きになれなかった。でも決めるのは自分ではない。
命令されたら従う。それが傭兵だ。会社員でも一緒ですが。
覚えるのに抵抗がないか？
募集要項に、SwiftとKotlinの経験２年と書いてありました。よくありますね。今回のは必須ではなかった。普段から学習しているところを評価されたので、知らない人よりは良いと思われたのかも。
どうしてもセンサー系の機能を実装するには、オリジナルしか使えないAPIを呼ぶ必要があるみたいだ。技術が好きならキャッチアップできるだろう。
Webやってたころにありましたが、新しいことを覚えるのに抵抗があって、フロントエンドはやりがありすぎてついていけないからバックエンドに逃げて、MVCだけやる人がたまにいますが、今時だとフロントエンドとバックエンドでWebアプリを開発するSPAは当たり前のように使われるようになりました。
現場によっては、クラウドもやれと言われる💦
昔と比べると、Reactを使える人が増えた。覚えようという意欲がある以外にもReactを知ると見える世界があるから、興味でやったのかも。
Next.jsを例に出すか
私もNext.jsが好きではなかった。使用がバージョンアップするたびに変わるので、好きになれなかった。副業先で大学生がパッケージ入れてバグだらけのもんを作った時は腹が立って文句言ったことがある。
Flutter Webで作ったら業務系のシステムなら作れるだろう。
普通のReactでいいだろうと。
でもNext.jsは素晴らしいフレームワークだと思った。リスクがあるので採用は慎重になったほうがいいが。Vercel社の製品でないと相性悪いしVercelが潰れたら動かなくなるしな💦
素晴らしいと思ったのは認証機能の実装をしたときにmiddlewareの設定をすると、FlutterのGoRoterのリダイレクトと同じように、認証が通っていなければ指定したページへは遷移できないように対策ができるからだ。
フレームワークやライブラリが開発されたのは、過去の悩みを解決するために生まれたので、それを考えれば技術への抵抗はなくなった。
私の場合は、あまりパッケージは入れませんでしたけどね笑
依存してまうのでね。あとでメンテナンスが大変になるのと作るものにあっていないから、最近自分で作っているプロダクトでは、Auth.jsもPrismaも採用してません。
使い方わからんというのもあるが、動くの作れるけど、サポートされなくなった時への対応と標準機能で十分だからやめた。目的があってライブラリに頼りすぎないように、作られたFlutterアプリと同じですね。
ちなみに使わなかった理由を説明すると...
Supabaseの公式がメンテしてねーからだよ😇
副業先では大学生が勝手に入れておった。の割には、ログインするときに画面が一瞬出てくるエラーが出たぞ笑
「なぜ議論しない？」
俺ちゃんのはmiddleware.tsしか使ってないけどリダイレクトできるよ笑
標準機能でなんとかなる!
Prismaを使わなかった理由は使うメリットがなかったから。俺はスキーマがどうとか型安全とを知らない。標準機能のでなんとなる😇
使った結果どうなったか。データベースを一緒にすることになった。マイグレーションするとテーブルのデータが全部消えます😇
コピーしてバックアップを取る必要があるらしい。でも設計がコロコロ変わるプロジェクトには合わないな。そもそもレビューがしずらい笑
複雑にするな。一人で勝手に作って進めた結果使い物にならず。
「コミニケーションはとりましょう。議論していれば無駄なことは減る。」
詳しい人に以前質問したのだが複雑なクエリは使えないらしい。
ちなみにこんな人間は、VScodeのインストールさせてくれなくて、AI禁止の会社に行ったら仕事できないだろう。🌸エディターだとモバイルアプリ作れませんが☺️
案件をくれた企業に限ったことではないが、「コミュニケーションがとれる人」を企業は求めている。
隠れてコソコソバグだらけのもを作ると、仕事なら「設計と違う。なぜ対話しない？」と突っ込まれるだろう。案件から退場されるだろう。首切られなかったら部署移動だろうが😇
すんません技術の話に戻ります💦
流行りだからかっこいいから使うのはいいでしょう。しかしビジネスの目的にあっていないなら、不要です。あとでメンテナンスのコストが増えます💦
私は流行りがいいですが技術選定するときに相手が指定したものがあれば、MVVMかクリーンアーキテクチャかいいねと受け入れて使うし「標準機能で頑張るのか。Swift、Kotlin使うのか。」であれば勉強させてもらいますのスタンスで頭を切り替えます。
まあ僕の好みでないから、「それ入れんなって思うことあるけど」議論しない人はよくやります😇
友人と最近自社開発してるサービスは、議論してGoのフレームワークはEchoにしましたしPrismaとzodは必要性を感じないので、入れませんでしたwwww
技術選定するならまずは調査して、リスクも考えて選ばれたのだなと最近は思う。多分ね。
最後に
Flutterは便利なツールです。しかしIOTアプリの開発をする現場だとFlutterが苦手なセンサーを使うので、SwiftとKotlinの知識を求めれることがあります。いつかは、SwiftとKotlinへの理解を求められるでしょう。
Webとデスクトップも開発できるが、ElectronやNext.jsで作ったほうが良いかもってことも。
おそらく言語の特徴とオブジェクト指向と歴史とかアーキテクチャに興味を持って覚えることが必要なのだろう。
面談した人はマニアックな会話をしてた💦
Riverpod、GoRoterBuilder、Retrofitを使いたがるやつが多くて、合わせていたがまさか、もっと難しいネイティブの機能を使うとは。
SwiftとKotlinを仕事で使って経験者になれば、流行りのパッケージ使うよりアピールになることもありますけどね(^^;;
ちなみにプログラミング詳しい人によると、AndroidのViewModelとMicrosoftのは違うらしい。
Discussion