導入のしやすさ
- Mac必須 開発というよりかは、iPhoneやiOS Simulatorの為
- Flutter Doctor 便利
- packageも楽ちん
- 導入というか性質というか、頻繁にFlutterアップデートが来る。描画が壊れるupdateもあったが、回避方法はあったので致命的ではなかった
Flutter
- WYSWYGツール不在の為、UI設計が面倒とおもったけど十分高い生産性
- hot reloadが優秀 (ソース保存即時反映)
- Debug paintが優秀 (各コンポーネントの描画範囲等がわかる)
- Flutterの基本コンポーネントにしろよと思ったパッケージ群、よっぽどシンプルじゃない限り必要になる 以下 pubspec.yaml dependencies:に追記するべきパッケージ
validate: "^1.6.0" #email等、入力チェック
http: "^0.11.3+16" # APIと通信するためのもの
sqflite: any #SQLiteを使うもの
path_provider: any #iOS,Android問わず、ローカルリソースパスを取ってくるもの
map_view: any # google map widget
url_launcher: "^3.0.2" #他のアプリにパスする http:// ブラウザ tel:// 電話起動等
flutter_webview_plugin: "^0.1.6" #サファリとBrowserを一緒くたに扱えるWebView
share: "^0.5.2" #他のアプリにシェア UIActivity, share compat相当
- 描画エリアがシビアというかサイズが足りないと、派手なエラー描画が出てできない事を教えてくれる。
- コンポーネントによっては、描画エリアサイズがわからない場合、使えないと真っ赤なエラー画面で教えてくれるが、コンポーネントがイケてないだけではと思ったり。
- 基本中の基本 Scaffold にbottomNavigationBarとかついているのに、タブアイテム3個しか入れらないとか、ふざけ過ぎじゃないですかね。
- setStateや条件分岐で表示を変えるとか、慣れるのにちょっとかかるかも。
- iOSとAndroid ほぼほぼ互換性を保つ
- 互換性を保てないところ
- google map (iOS デフォはapple mapのため)packageで回避できる
- Webview (iOS はsafari, androidは browserの為)packageで回避できる
- splashスクリーン 本当の意味でのロード中はflutterではできない。
- いちいち Alignment指定にClass指定をしないといけないとか、プロパティにClass要求が多いので、入れ子の入れ子の入れ子...になるのがホントクソ
- 生産性は素晴らしく良い。
- Action と View分けにくすぎ。無理に分けると操作しずらくなる
- メンテンス性を高めるには、Widgetを小分けにClass化して、再利用性を高める、ダラダラと巨大なWidgetを作らない。
- Action相当は存在せず、Viewとロジックごっちゃに書いてる
- 手探りでやって行ってだいたいこうなった
model APIやsqlite用のmodel
view 画面分のファイル
widget viewが使うWidget集. 複数の画面で使ったり、単にScreenがデカイ場合も小分けする用途
util 複数箇所から使われるユーティリティ
Dart
- カッコ地獄 []{} () 普段pythonを書いていたので、これ煩わしいすぎる ダサい
- Android Studio、IDEのカッコ補完がなければ死んでた 閉じ部分に//Scaffoldとか出てくれるのには助かる
- ほぼほぼカッコのせいで可読性低い
- 書きやすい、瞬発力出る → 楽しい
- カッコ以外はモダンな言語仕様で、概ね好感が持てる。
- ドキュメントは日本語が無いので、英語力ない人はお断り状態