00:00
はい、じゃあ引き続きですね、Flutterの話をしていきましょうということで、 ちょっとね、もう盛り上がりそうなんで、僕ビール飲んでいいですか?
そういうテンションで行くか。 飲みサップじゃないですか、飲みサップ。
ちょっとインターバルで色々喋りすぎた気がする。 今回後半ということでね、
インターバルの時間中に話していたデザインについて、 まず、普通にワンソースでやったらなんだっけ、
Googleのデフォルトの、何て言うんでしたっけ? マテリアルデザイン。
そうそう、ちょっとペラッとしたようなやつになるんですけど、 iOSの方に似せていくこともできるんですよね。
クパチーノでしたっけ?
そうですね。
あれ、結構もうだいぶ近い感じになってるんですか?
だいぶ近いというか、多分クパチーノで組まれたら見分けがつかないと思いますね。
そこまでなってるんですね。
ほとんどのUIキットがクパチーノで用意されてるっていう感じになってるんで、
IOSネイティブで作ったよっていうのをわざわざ組み込んでいくと、
本当にどっちで作ったか分かんないぐらいな感じには 多分仕上がるんじゃないかって気がします。
同じようなものを多分描画してるっていうことだと思うんですけど、
結局でもクパチーノで作ったアプリを 両プラットフォームに出すっていうのはどうなんだ問題が出てきますよね。
そうですね。だからクパチーノで作って、 それをアンドロイドで出すかっていうふうになると、
それはすごい微妙な話にはなると思うんで、 それは自分はやらないですね。
どっちかっていうと、自分の場合ですけど、
アンドロイドとiPhoneのいいとこ取りのような UIデザインを目指していて、
その中で作っていくっていうようなやり方をするか、
でなければもう破壊的に面倒くさいですけど、
完全に分岐してバラバラにアンドロイドの場合はアンドロイドっぽく、
iOSの場合はiOSっぽくっていうふうに。 だったらネイティブで作れよって話ですけどね。
まさにそれです。
それもできるんですね。
やろうと思えばできる。
これなんかサイト上でこのビジュエットの 静止画だけ見るとっぽいなと思うんですけど、
操作感とかちょっとあるじゃないですか。iOSっぽいアニメーションの感じだったりとか。
そこら辺も一般の人は多分そんな気にしないと思うんですけど、
iOS開発者として見たときに、そこら辺の違和感とかってどうですか?
分かる。
分かるんですか?
分かる。
絶対分かるし、やっぱり仮想マシンのオーバーヘッドがフレーム1個か2個落ちてるから、
03:02
変なプルプルする。
カクカク?
カクカクまでいかないんだけれど、
普段60フレームで動いてるんだけれど、何か引っかかりが1フレームとか落ちると、
人の目ってすぐ分かるんですよ。
アニメーションだけ?
そういうのがあるから、プログラムで、例えばリストとかで、よくあるリストでデータロードして、
もう完全にメモリに載ってるんだったらいいんだけど、変換しながら表示するってやったときに、
なんか今、描画戻んなかったっていうのが人の目に見える。
戻んない。
あー、なるほど。
そういう感じ。
パフォーマンスがあまり良くないっていう話も聞くんですよね。
いや、それはね、もう今のバージョンだと結構あれですよ。
私そのTwitterクライアント作ってるけれど、何月だっけ?
なんかフレームレートが低いって話をDiscordで話して、ガクガクするよねって言ったじゃない。
あーはいはい。
あれちゃんとプログラムに問題あった、そのオープンソースのプログラムに問題あったから、
なんだよ、こいつ悪いんじゃねえかよって言いながら直したら、ちゃんと60フレーム出るようになった。
うんうん。
作り方よ。
雑に作るとネイティブだと60フレーム出るやつが、同じように雑に作るとプラットフォームは60フレーム出ないことがあるんじゃないかなと思ってます。
あとはなんか、iOSはAndroidに比べてって話にはなるんだけど、
ちょこっとぐらい古いiPhoneだったとしても、CPUが結構高速なんで、ある程度ごまかせが効くっていうのはありますね。
同じのをAndroidのミドルローぐらいで走らせると本当にガクガクになって、
これはちょっとiOSのKupachino使うのやめようかなって思っちゃったりすることはあるんですけど、
iPhoneで言ったらiPhone7とか8ぐらいだったら、CPUの速度でなんとかなっちゃうっていうところは感じることは多いですね。
Androidってチップセットが何種類かもあって、スナップドラゴンのやつとそうじゃないやつのチップセットでどっちがどうなのっていうのがさっぱり分からないんです。
性能がいいのか悪いのか。
数字が高いのが性能がいいのかなと思ってたら、実は数字だけでミドルローだったとかいうのがあって、もう分かんない。
詳しい人だったらその辺分かるかもしれないけど、その辺のチップセットの型番の混沌としている部分で騙されることがいっぱいある。
アンティストベンチマークで言って、iPhone5Sぐらいのスペックみたいなやつが普通に去年発売されてたりするのがAndroidなんで、そういうのに引っかかるとちょっと凝ったインターフェースだとつらいのかなっていうところは勘ったりしますね。
そういうの売っちゃダメですよね。
それでもさ、最近のAndroid12とかが乗って売ってるからさ、4年前のハイエンドでAndroid動くんじゃねーの?実はとか思うんだよね。なんかね、その辺が納得いかないんだよね。
06:09
去年発売されて今年のOS使えないからね。
ただAndroidの場合っていうか、このフラッターでさらっと作りたいものっていう場合って、もう今先進国中心にして考えると先進国だけガサッと切るとiOSのシェアってだいたい50%超えてるっていう感じになるんだけど、
途上国とかも入れてったりとか中国も入れてったりっていうふうに考えると、途端にAndroidの方が逆転して8割Androidみたいな世界観になってくるんで、そっちにリーチしたいなっていったときにコストかけたくないじゃないですか。
正直お金持ってるそうじゃないんで。でもそういう人たちにも使ってもらいたいっていうようなサービスを作りたい場合は、なんかフラッターでサクッと作っちゃうっていうのも手の内かなっていうのはあります。
逆に言うとそこで動く程度に軽いものしか、逆に彼らはハイスペックなマシンを使ってないので使えないっていうところを最初から考慮して作るっていうふうになったときに、ネイティブの方が早いはそうなんですけど、
制作コストをかけたくないっていうときにあえてフラッターを使うっていうのも、自分はちょっと今そういうタイプのものも作ってたりするんで、そのときにはちょっとフラッターは便利だなっていうのはあります。
わかるんですけど、理想を言えばそこのためにiOSユーザーのユーザー体験を落としたくないっていうのはあるかな。
リソースが避けるんであれば両方ネイティブか、iOSネイティブ、Androidフラッターの方がいいんじゃないかなって思いますけどね。
大手とかはライト版作ってますよね。多分ツイッターとかフェイスブックのライト版で、そもそもダウンロード、アプリの容量を減らさなきゃいけないとかも要件に入るんで。
インドとかですよね。
そうそう、通信速度がやばいですもんね。
なので多分動作もあるしアプリ容量も落として、多分リッチさをなくしてっていう感じだと思うので、
そうですね、気軽にフラッターでちょっと出したいはありですが、ガチでやるとネイティブの方がいいかなとかは思っちゃいますね。
あれフラッターってアプリ容量ちょっと増えますよね?
Xamarinめちゃくちゃ増えて、Xamarinのダウンタイムはめちゃくちゃ重いって話聞いたんですけど、フラッターはどんなもんなんですかね?
私が今作ってたツイッタークライアント、昨日申請したホヤホヤのパッケージ見てみましょうか。
普通のツイッタークライアントでタイムラインがあってみたいな。
ちなみにツイッター公式が200メガぐらいですね。
09:00
あれそんなでかいの?シフトで作ってて。
いやーオブジェクティブシリーズ作った頃に戻してほしいよね。
昔はそんなゲームぐらいでかいんだっていう印象ですね。
150メガぐらいでしたっけ?Wi-Fi必要とか。
150です。
そうですよね。
で、ツイートボット、フルクライアントですけど、こいつは15.8メガ。
オブジェクティブシーセレですね、ツイートボットは。
いや、そんなことないですよ。
古いですね。3年とか以上前の情報でツイートボットの作者はなんでスイスをやらない理由で
多分その人なんですけど、ベータテスターじゃねえからスイスやらんよって言ってた気が。
そうなんですか?
確かオブジェクティブシー反応した人だったと思いますね。
じゃあそうなのか。
だからちっちゃいファイルサイズは。もしかしたら。
そうそうそう。ちっちゃいのは正義なんですよ、やっぱり。
Twitterificとかでも21メガなんで、どっちかというとツイッター公式は重すぎるんですよ。
なるほど。じゃあスイフト製で軽いやつ。
うん。スイフト製とかはあんまり関係ない。
自分が今リリースしてるアプリは同じFlutterから書き出したもので、アップストアの方が32.1メガバイト。
意外と小さい。
Androidの方が全く同じものを書き出したもので、15メガバイトですね。
あったあった。ユニバーサルが57.5、だいたい56メガ。
やっぱりでかいですね。
そうですけどめちゃくちゃでかいわけではない。
めちゃくちゃでかいわけではない。
ツイッター純正より小さいよ。
ツイッター純正は何を仕込んでるんだろうっていう。
おかしいよね。
ユニバーサルの半分くらいになるんですね。各端末用になると。
そうなんですよ。
自分のは32メガがユニバーサルで、各端末は16メガぐらいですね。
結構小さくなりますね。
普通に問題ないレベルですよね。
Androidの方は15メガですね。
全く同じのから書き出したものです。今バージョン合ってるんで。
これ私がオブジェクティブCで作ってたツイッタークライアントは8.8メガですよ。
一番小さい。
軽い。
現存してるやつ。
僕もオブジェクティブCで書いてたやつはツイッタークライアントですけど11メガとか。
勝ちましたね。私の勝ちだ。
負けたのか。
僕ちょっと一人だけビール飲んでて酔っ払ってるんで。
ぶっこんでこうかなと思うんですが。
そもそもIOSとAndroidでUIとか一緒にしたいっていうのが良くないって自分は思うんですよ。そもそも。
12:07
同意です。
結局、小規模開発で開発にリソースを割けない。
アンドロイドIOS共通にしたいのは、サポートコールセンターとかで説明するときに楽になるとか。
多分そういう理由はあるとは思うんですが、
基本的に開発者目線とかビジネス目線なんですよ。
ユーザーがどういう体験をするかっていうところとはちょっとずれてるんですよね。
マルチプラットフォームを一緒にするっていうことが。
確かに確かに。
そこがちょっと私は気になるところがあって、
開発者目線で美しいもの、綺麗なものとかっていうのは良い体験を生むって思われがちじゃないですか。各プラットフォームのネイティブは。
でも実は、例えばこれテレビのリモコンなんですけど、
こんなんでも十分仕事の役に立つ人はいっぱいいるんですよね。ユーザーインターフェース的に。
世間的にはこんなんでいいのかもしれないのに、ネイティブの方に合わせようっていうのもおこがましいんじゃねえかなと思うことは最近あります。
僕基本的に家電のクソUI使い方わかんない人なんで。
そこはたぶんね、美的感覚が他の人よりも優れてるがいい細かいことが気になっちゃう人なんですよ。
でも一般の人から見ると、私から見るとひらぎのもMSゴシックも変わんないんですよ。
同じ文字じゃんってなるんですよ。デザインしてる人から信じられないかもしれないですけど。
で、MSゴシックの目とひらぎのの目、ちゃんと目だよねってなるんですよ。
両方目ですね。
ちゃんと読めるじゃんってなるんですよ。そこにひらぎのにこだわる理由はないと思う人たちがやっぱり一定層いて、
その人たちがどのくらいの数を占めるかって言うときっとものすごい数いると思うんですよ。
今の若林さんのやつだとリモコンで言うと各社同じようなリモコンですけど、
全く違うリモコンのUIをこれでやると開発コスト下がるからこれでいいよねっていう押し付けじゃないですか。
今までの成り下しんだリモコンじゃない新しい共通UIのリモコン、ちょっと変わったリモコンになってて、
それが開発者とかビジネス目線だと共通にしちゃえば開発コスト下がるよねっていう話なんですけど、
ユーザーとしてはそのリモコンまでめちゃくちゃ違うかって言ったら、スマホのアプリなんで高橋で言ってますけど、
新しい共通のUIになってて、あれなんかiOSっぽくないよねっていうテレビUIのiOSアプリを触ることになったり。
15:01
まさに今のリモコンの例えすごいいいなと思ったのが、
例えばそのエアコンのリモコンとテレビのリモコンと同じ金型で作ってやりたいよねって、
そしたら工場1個でいいし、ライン1個でいいし、印刷するボタンと基板だけ変えればいいよねみたいな。
で、なんかエアコンに123って書いてあるやつで、21度みたいな。
で、あの黄色ボタンで、黄色ボタン、赤ボタン、青ボタンみたいなので設定するみたいな。
なっちゃうみたいな。
そういう雰囲気かなって思うんですよ。
結局作るアプリ次第かなっていうのは自分はちょっと思ってるところがあって、
極論言ってしまえば、ゲームのUIなんてもう両プラットフォーム完全共通がほとんどじゃないですか。
違うところって確かにアラートビューとかをネイティブのものを使ってるっていう風になってくると確かに変わってきたりするんですけど、
ちょっと広い目で見てみたときに、ゲームでそのアラートビューをアラートビューでやってるっていうようなのってほんと少なくて独自UIで実装しちゃってるっていうのもあったりして、
もうユーザー体験として重要なのってパッと見わかるかどうかっていうところの方が優先されてるような気がしていて、
そういうのもあって、自分は今フラッターっていう環境を与えられたことで、両方に共通するUIっていうのも、
自分はどっちかっていうと、もともとの仕事がデザイナーで始まった人間なんで、
そういうのをデザインしてみるっていうのもちょっと面白いのかなっていうので、
今はトライしてみるっていうような意気込みはあるのかなっていう感じはしてるところではあります。
ただ、ユーザーが使いづらいって思っちゃったらやっぱりダメなのかなっていうふうには思うんですよね。
そこはユーザーが使いづらいって思わない範囲で共通インターフェースっていうのが作れるのか、
あとは分岐でうまくデザインを分けるところ、どうしても分けなくちゃいけないところはきっちり分けていくっていうところ、
そこの敷地を今から探っていければ面白いかなっていうのは自分の中ではあります。
ゲームは確かにそうなんですよね。ゲームとかは分かるんですよ。
没入感とかあるような独自UI。
松井さんのアプリってそれに近いですよね。結構ゲームに近いというか。
多かったですね。
結構合いそうだなっていう。
なんかツール系だとネイティブのUIだと親和性高い。
iOSだと下タブで、Androidも下タブになったんでしたっけ?上タブでしたっけ?とかあるじゃないですか。
そういう作法の違いとかですかね。
モデルボタンなのかスワイプバックなのか。
18:03
スワイプバックは結構論争ありますよね。
iOSの人はスワイプバックじゃないっていう。
程度の問題かなって思っていて。
Flutterのマテリアルアップで作ったiOSアプリも
ナビゲーションバーはちゃんとiOSっぽい見た目ですし
モデルボタンとかスワイプバックももちろんiOSっぽい動きをしてますし
全然違和感ないなと個人的に思ってしまいますね。
僕が多分よく分かってないんですけど、スワイプバックとかモデルボタンって
アンドロイド向けにビルドしたときは消えるんですか?
そうですね。動かないですね。
なるほど。よくできてますね、それは。
なんでうまくどっちのユーザーにも
それぞれのOSの体験は最低限見せようという努力がすごく見えるなって感じはしますね。
細かいところでは意外と気使ってくれてますよね。
ライブラリー入れるだけでちゃんとそれが実現できるみたいな。
ライブラリーがiOS向けだとこういう感じで
Androidだとこういう感じみたいなのを吸収してるって感じなんですかね。
極端にiOSっぽいなとかAndroidっぽいなってみんなが感じるところって
ナビゲーションバーとかその辺だと思うんですよね。
そういうところはちゃんと違う動きをする。
じゃあ全体的で見た時に全く違和感がないかって言われればそれはもちろんあるっていう感じではある。
ただそこも踏まえてちゃんと動くんですよね。
ちゃんと作れちゃうからアプリとして成立するレベルでは作れるんでっていうのもあるのかな。
思ったよりいいし、ザマリンとかを引き合いに出すのも気が引けるぐらいよくできてるっていう感覚はあるかな。
あの頃とはちょっと考え方のレベルが全然違って
フラッタも多分2年前だと自分も躊躇するレベルだったんで
やっと去年、去年?去年じゃないな。
もう年が変わったんで2021、20年の12月くらいに見た時に
いや、もしかしたら半年くらいにはいけんじゃねっていう直感を得たぐらい
作ってみたら動くっていう感じだったんで
そっから使ってみてもいいかなって使ってみて
フラッタ入るにはちょうどいいタイミングだったかなっていうような感じは自分は得てる感じですね。
デザインの話で言うと、UIデザインの話で言うと
21:00
フラッタ公式にiOSとAndroidでレイアウトコードを共通化して何が嬉しいの?みたいなFAQが実はあるんですけど
それがさっき松浦さんがやりたいって言ってたのとちょっと近いのかなっていう感じのことが書いてあって
モバイルアプリのレイアウトとデザインっていうのが
これ2017年当時に書かれたものだとは思うんですけど
ブランドドリブンで例えばマクドナルドアプリだったら赤と黄色でMって書いてあればいいみたいな
乱暴な表現をしたけど
ブランドドリブンでこういうデザインにデザイナーがしたいみたいな感じで
それをプラットフォーム間で共通化して作っているアプリが増えてるよねっていうのがまず前提にあって
その上でブランドのアイデンティティみたいなのを入れてカスタマイズしていくっていうこと自体が
カスタムなUIを作っていくっていうことが
オフィシャルなOSのデザインの作法に従うことよりも
厳格に従うことよりも重要になっている
なのでフラッターで共通化するべきだみたいな
それは奇弁ですね
私から見ると
これGoogleの人たちがやっていることだから
俺たちの作ったもので他のプラットフォームを荒らしてやるぜっていうのしか聞こえない
いい話だなと思ったら
いやいや塗りつぶせってことだよ世界を自分たちのプラットフォームで
AppleとかのOSをただの下地に土台にしちゃって
その上にフラッターを乗っけて俺たちのレイアウトを使えばいいだろうっていうことでしょ
なんか俺たちのレイアウトというか
みんな自由にレイアウト作ればいいじゃんぐらいの
それはでもAppleがせっかくHuman Interface Guidelinesってものを作ってるのを
無視しようぜっていう煽りだよね
そうなんですよ
そこが自分的には共感できないところなんですよね
共感したい気持ちはあるんだけれど
ネイティブの方がやっぱりツルツル
気持ちよく動くとこ見るとやっぱりネイティブ一番だよなってなる
ブランディングだと確かに他のアプリと違うUIにしたい欲はありそうですよね
本当にデフォルトで使うと純正の設定アプリみたいな感じに近くなっちゃうじゃないですか
本当にツール系
けどマクドナルドっていうのを出したい場合には全く違う
ゲームに近いブランディングとしてのマクドナルド体験を
アプリで押し付けたいっていう英語ですかね
24:01
わかんないですけどっていう気持ちはわかりますね
やっぱりフラッター
今まであんまり触れられてないんですけど
アニメーションにすごい力入れてるんですよ
2Dのアニメーション
フォーマットでいうとフレアっていうフォーマットで
アニメーションのプログラムでちょっと画像とかを作っておいて
プログラムでちょっと操作をすると動きのあるコンテンツを簡単に作れるんですよね
簡単なスクリプトで動かすんですけど
そういうのをアプリに組み込んだ時に
意味が変わってくると思うんですよね
ネイティブだとそこをやっぱり独自に作り込むのが結構大変だったりする
アニメーションっていう部分あるんですけど
これでもそのアニメーションの機能
フレアっていうフォーマットのアニメーションを作るのが標準で入ってなくて
どっかの別の会社が作ったツールを作って作るんだけないのが
なんかよくわかんない
やる気があるのかわかんなくて
そこもなんかソフト
フレアって形式のアニメーションを作るソフトの名前も変わってたりするんですよね
今なんだっけライブに変わったんだっけ
ちょっと前はなんとかスタジオって名前だったような記憶があったんだけど
そういうのを使って各プラットフォームにブランドの動きを載せるって風になると
ネイティブで2カ所作るのは結構しんどい気がしますね
アニメーション結構きついですよね
エイピングとかやるか
でもiOSだったらコアアニメーションを使ってちょろちょろっと書けば
それなりに動きのあるものは作れるんですけど
あとiOSだとAirBが出してるLottieっていう
あれは何でしたっけ何を元にできるんでしたっけ
JSONファイルを使うんですよね
アニメーションの形式って
JSONを読み込ませたらそれで動くんじゃないですか
そうです
何秒後に右へ行けとか2秒停止してから拡大何%拡大とか
グラフィックのSVGとかの表現もJSONに入ってて
デザイナーの人がそれ作ったらそれをポイって渡してくれたらすぐできるみたいな
アフターエフェクトですね
アフターエフェクトでアニメーション作る人が多いので
なるほど
アフターエフェクトのレンダリングとしてLottieっていうのがあって
確かこれはTwitterとかも確か使ってたような気がしますね
お気に入りのところとか
ちっちゃい部品のアニメーションとかで
エイピングとかでもいいような気がするんですけど
元を作る人がアフターエフェクトで作ったやつを
そのまんま動かせるっていうのがメリット
27:00
ただしこれちゃんとやったことあるんですけど
アフターエフェクトの中でもこれ使っちゃダメとかっていう要件とかもあるので
意外とちょっと制限はアニメーションを作る人の制限はあるんですけど
ファイルさえ作ってJSONとしてアプリ内にあれば
そのJSONを元にアニメーションさせるっていうのはできる
それがFlutterがせっかく独自のレンダリングエンジン持ってるんだったら
なんか共通でいい感じのアニメーションとかを
Flutterはそのパーツだけでも使えますからね
自分らだったら仮想通貨のチャートとかのエンジンを作って表示できるようにして
でもこれ独自でAndroidとiOS両方作るの大変だよねっていう場合は
そのチャートの部分だけFlutterで描画したものを各ネイティブの方で使うみたいな
そういう使い方もできるんで
そういう入り口もあるかなっていうところはあります
そういう全体のUIに関係ない描画だけっていう使い方は結構いいかもしれないですね
大変ですからねそういうライブラリバラバラに開発するとかっていうのは
自分はやったことないですけど
安倍さんが確かDevSuppの発表のときにこういう使い方もできるんだよみたいな
教えてもらって便利だなって
全然覚えてなかった
具体的に何がっていうのはなかったけど
一部だけ書き出して使うこともできますよみたいなのをやってました
FlutterでAndroidでいうとActivityっていう単位を作っておいて
そこだけ使うみたいなことができる
ABテストするときにABテストのB側だけFlutterで作っておいて
反応を見るとかそういうこともできる
UIとかUX作るときに独自のものとして使うとか
そういうのはトヨタでも車のスピードメーターのパネルとか
そういうインターフェース作るのにFlutterを使ってるっていう実例があったりとかするんで
逆に言うと組み込み系のものを作りたいとか
IOS Androidのパーツを作りたいっていう
そういう尖ったところでの需要としてFlutterを使うっていうのも
各メーカーさんがFlutterエンジニアを今募集してる理由の一つになってたりするんで
エンジニアの稼ぐ手段をFlutterが若干増やしてきたのかなっていう側面もあるのは面白いところですね
トヨタとかソニーとかもあったかな
ああいうところが独自のハードウェアとかに載せるもののUIとしてFlutter使うのは
すごいそれは共感できるっていうか
そうすればいいじゃんって思うんですよね
30:00
そうだよねだいたいAndroidベースなもんね今ね
だし自分たちの世界観を作るためのものだから
それはすごいいいなと思うんですけど
やっぱりマルチプラットフォームがやっぱり自分的には
なるほどですね
これ開発言語のDart自体ってどうなんですか
なんかあんまりいい話を聞かないというか
マジでDartぐらいのこのぐらいのシンプルな言語私すごい好きなんですけど
いいですね
いいっていうか無駄ながらなくていいよねって感じ
他の過去のJavaとかCとか知ってる人だったら何も問題なく使えるよねっていう
そっちよりなんですね
全然古臭いよ何も新しいことないから文法の後ろにはセミコロンいるし
安心できる人いるんじゃない
メソッドの前には引き過ぎるしね
引き過ぎるし省略しないでなるべく書くから記述する量はそこそこ多いんですよ
そのくせエイシンカーベイトが使えたりするっていうね
エイシンカーベイトはねこれすごくよくできてて
Swiftがもたもたしてる間にこっちの方が先に動いてたからね
言語使用として結構薄いんですか?
Swiftとかめちゃくちゃ多いじゃないですか
覚えることが少なくてもともとNull Safetyもなかったんですよ
欲しい
だからねWrapとかUnwrapっていう概念もなくて
なんかチェックする時にはちゃんとNullのチェックをする書き方っていうのが昔じゃないですか
そういうことを知ってる人から見ると安心して書ける
でもそのNull Safetyがダートっていうかいくつだっけ
2.5かな
そのぐらいかでNull Safetyが入って
重たったライブラリーはすぐNull Safetyに対応して
なんかSwiftっぽい記号が入りやがったみたいな感じになって
Wrap Unwrapの概念が入って
結局やるだけなんねえのかよってなったけど
でも所詮その程度のことでしかないから
なんか言語仕様が薄いものだと
結構大きいアプリやっぱきついのかなっていう
その複雑になるじゃないですか
例えばObjective-Cでめちゃくちゃでかいアプリ作るのやっぱきつかったなって思ってて
まじで
ちゃんとした人が作ればいいんですけど
みんながちゃんとしてない時に
例えばSwiftとかだと
なんか言語仕様ガチガチなので
あんま間違ったことしづらいかなと思ってて
Cとかも好きなんですけど
あれで巨大アプリって作れるのかなって
作れるでしょ
昔からC言語でみんな作ってたんだから
33:00
そうなんですけど
でも結構みんなLintでガチガチにしてたりします
チーム開発とかだと結構
設計の柔軟性というか
あんまり縛りがないと
なんでもできるからパッと作れる
パッと書けるけど
なんかコントロール
ちゃんと設計とかデビューしたいとか
なんかちゃんとしないといけないのかなって
余計にしなきゃいけないのかなって印象あるんですけど
どんな言語を使ってもね
バカな人はおバカなことを書くから
そういう人だから綺麗に書けるってのはないっすよ
それは
一緒一緒
ダート言語自体は別にそこまで問題ではない
問題ないっていうか
わりとこのC言語に近いシンタックスを
読み書きできる人の方が
多分人口的には多いんじゃないの?
PHPでしょ?Cでしょ?
Perl?Java?って考えると
そういうのを読み書きできる人たちが
このシンプルな構文でプログラムを書けるから
なんとなく書き始めることはできるんじゃない?
そういう意味でもやっぱり入りやすいんですね
入りやすいし
最近の尖ってるSwiftとか
ああいうやつKotlin
それかあとFirefoxで使ってるRUSとか
ああいう今時の言語って
プログラムをいかに短く美しく書くかってことも
考えられたりするけれど
そうすると情報量が圧縮されるから
一行に対する解釈が
これどうなんの?っていうのが
たぶん取っ掛かりわからない人いるんじゃない?
多いと思います
僕はどっちだったらそっちの方が好き
でもその一行に情報詰めすぎてさ
昔ひどいことになったPerlって言語があるんだけどさ
Perlだったら
Perlなんてもう本当に一行にめちゃめちゃ詰め込めれるから
例えば正規表現も含めて
これなんでこんなにいっぱい処理するの?ってことはあるよ
確かにインタープリターってやつは
一行に情報詰め込んでやった方が
一回の解釈が仕事量増えるからいいかもしれないけれど
アプリケーション作るときに
そこまでやる必要あるのとは思うけどね
アートに関しては僕は
明確に足りてない機能が2つあるなとは思っていて
それが与えオブジェクトを作る機能と
直話型を表現する機能
与えオブジェクトはStructとか
そうですそうです
そういう人に言うとStructのエナメルがないんですよ
参照型
ボトリングに詳しい方向けに言うと
データクラスとシールドクラスがないっていう感じですね
そこは今主流だと
LiveパッケージのFreezedっていうライブラリを
36:00
選ぶっていうのが
主流なのかなと思うんですけど
できれば言語仕様としてその辺は取り入れてほしいなと思ってます
与え型は必須というか好きですね
参照私がいろんなことを複雑にしてて
バグの温床かなと思っているので
ただそこを与え型でパフォーマンス良くするのって
結構ちゃんとしてるじゃないですか
そういう人とかだと
なのでその仕組みが必要だから
参照型でやってるのかなって思うんですけど
参照型のみ結構難易度上がるような気がするんですけど
どうなんですか
与えオブジェクトを作れないのはきついですね
なのでFreezedは僕にとっては必須ライブラリになってしまってます
ライブラリを組み込んでやれば
やりたいようにはできるようにはなるんだけど
ダートの仕様自体に組み込んでくるっていうところは
やたらと慎重ですよね
言語拡張させないように結構
このライブラリ標準だよねみたいなのがいっぱいあって
ほぼほぼ標準なんだけど
もともとのダートの方には入れてくれないみたいな感じになってるものが多くて
これとこれとこれは必須セットみたいな状態管理とか
リバーパッド使うとかっていうのもそうなんだけど
そういうのがいっぱいある割に
じゃあどれを選択するのっていうところは
結果的にまだデベロッパーに委ねられてるみたいなところは
多いかなっていう気がします
標準フレームワークが弱いみたいな話は
プラッターやってる人から聞きましたね
これがないの
Swissのディザルト型みたいな
ENUMがないから多分表現できないんでしょうけど
タプルとかも
タプルあるとちょっと便利じゃないですか
とかもないって話は聞いてて
言語仕様を薄くすると
ENUMないは結構びっくりな気がしますけど
どうしてるんですか
そういうライブラリーがあるんですか
ENUM
ENUMはENUMというものはあるんですよね
ただ本当にデジタル型っていう感じのENUMで
ダイスデータ的な極和型みたいな表現
アソシエイトバリューがありますよね
ああいう感じの表現が苦手なんですよね
C由来の普通の極シンプルな
シンプルないね
なるほど
ちょっと欲しい気はしますが
そういうのが欲しい人はフリーズドを使ってねっていうのが今の現状ですね
なかなか言語拡張がされないというところで
フリーズドみたいなパッケージがあるから
みんな使えてるって感じですね
そうですね
みんなこれなしで作ってるとことかあるのかな
39:02
なるほど
でもあるんでしょうね
オブジェクティブシーンのときも
私がそんな使ってたかなと思うと
使ってなくて
上型でみんな頑張ってバグ出してたような
アレイが勝手に変わっちゃうみたいな
だけどそれはもうちゃんと変えないようにしようねとか
コピーしようねとか
もらったやつコピーしてやろうねみたいな話を
僕はモダン言語好きなので
そこに戻りたくないなっていうのはありますね
アタイ型をあんなにフィーチャーしてるのは
Swiftぐらいしか見てないですね
コトリモダンとも基本参照型の言語なので
そうですねSwiftは多分パフォーマンス上げるために
あれはやってるんですよねきっと
パフォーマンス上げるためなんですかね
参照型のほうが上がるかなと思って
コンパイルするときに固定できるからじゃないのアタイ型だと
違うの
アタイ型で必ずコピー発生しちゃうので
パフォーマンスとしては劣りそうな気がします
コピーってそっちのことか
関数のコピーの
コピーオンライトがあるので
多分今までの言語とか環境だと
例えば文字列を
10名がある文字列を渡すときに
アタイ型だと単純にコピーして渡す
そうですスタックに積んじゃうから
それがセフスタートコピーオンライトで
変更したときに初めて書き込む
っていう仕組みを内部的に
ストリングとかアレイとかが
内部でちゃんとうまいことをそういう
管理をしてくれるっていう仕組みを
作れる言語仕様っていうんですか
っていう風に整理したから
多分アタイ型
基本的にintとかもアタイ型じゃないですか
ストラクトじゃないですか
アタイ型中心になったのは
そもそも参照渡し
いろいろ問題あるよねと
アレイ勝手に変わるのやだよね
コピー毎回するのやだよねっていう部分を
うまいこと言語仕様と
実装でうまくやってるのかなと
だから結構そういう意味で
新しい言語かつアップルが
自分ルールで突き進められる言語なので
うまくアップルがやりたいように
コントロールしやすいように進んでるのかな
っていう感じですね
実装だいぶ違いますね
ダート新しい目の
新しい目の言語なんですか
ダート自体はそんなに新しくないんじゃない
ダートってフラッター以外で何か使えるんですか
聞いたことないな
フラッターとダートセットになってる
っていうところしか見たことないな
42:00
これなんでダート選ばれたと思います
なんかいろいろあるじゃないですか今言語
Googleが使ってる得意な言語とか
社内であると思うんですけど
ほぼ新参者の言語を採用した
メリットとかなんかあるんですかね
特にダートっていう言葉が
言語を作った理由って
聞いたことないな
もともとこいつだってトランスファイラーだったから
別にダートじゃなくても良かったんじゃない
ダートはもともとGoogleが開発してるので
Googleのコントロール下に置きたいっていうのは
あるんじゃないですか
完全に
あったから使ったみたいな
もともとこいつはダートは
Chromeに乗るはずだったんですよ
何に乗る
Chrome Chrome
Google Chrome
ChromeのJavaScriptの代わりに
ダートのインタプリターを乗せようっていうのが
あったんですけど
何かあってなくなったんですよ
その話が
これ最初は競合が
タイプスクリプトみたいな
オルトジェースって言われる
JavaScriptの代替言語として出てきたんですよね
そうそうそう
だけど何のか何とか乗んなかったんだよね
で
なりを潜めて
実はFlutterの言語でしたみたいな感じで
再浮上したみたいな
じゃあタイプスクリプトと兄弟みたいなもんなんだ
兄弟まではいかないと思うけどね
タイプスクリプトの方が全然別次元で
上の方行っちゃってるから
そうなんだ
タイプスクリプトが
Chromeに乗るっていうんだったら
すごく喜ぶ人いっぱいいるんじゃない
タイプスクリプトからJavaScriptに変換しないで
そのまま動くっていうのを
欲しい人いっぱいいると思うけど
Googleの内部構想の匂いしかしないですね
分かんないですね
用語論として
今結構否定的な
どっちかというとネガティブな話題が多かったんですけど
福祉屋に
Androidが
Androidというか
新しいスマートフォンで
福祉屋が乗るようなものが
Fabsonから出るという噂があって
さらにそれが広がっていくっていう
未来があるなら
Androidエンジニアはやるべきなのかなって
今のうちキャッチアップしとくのは
損はないのかなって思うんですけど
そこってどうなんですかね
そこは全然気にしてないな
どうせ福祉屋で最初
Androidエミュレーター乗って
Androidアプリ動くんじゃないですかきっと
それはどうかな
さすがに
そこまで頑張るかどうかですよね
なんかフラッターが
開発環境として良いことなので
広報区間みたいなものはなくて
フラッター主流で
OSバトルが1個増える
45:01
iOS Android
福祉屋で
iOSの人は別に
Appleの世界にいるからいいけど
別にOSバトルをする必要はなくて
福祉屋はAndroidとケンカをしないとこ
使えばいいと思う
これリプレイスって話は別に
リプレイスしなくても平存でいいと思うんですよ
例えば
スマートフォンはAndroidがいいけれど
タブレットは福祉屋でも全然いいとか
っていうのはあると思いますよ
そうすると
福祉屋のアプリを開発するには
フラッターやらなきゃいけないじゃないですか
なのでiOSエンジニア的な
Appleの人がそこに行かないような
AppleはiPadあるんで行かないような気がするんですけど
全然Appleでやらなくてもいいんじゃないの
新しい人たちにそこを
プラットフォームを開放すれば
仕事が欲しい人はそこに行くから
必ずしもiOSエンジニアが
福祉屋もAndroidも両方
やらなきゃいけない理由はないと思いますよ
食えるんだったらiOS専門でやって食えばいいじゃない
iOSの人はそうなんですけど
Androidの人はパイが減るじゃないですか
なんで減るの?増えるんじゃないの?
プラットフォームが増えるから
リプレイされる未来があるならっていう
Androidがどうなるのかがわからないっていう状態で
一応フラッターも今需要があるので
フラッターにちょっとキャッチアップしとくと
それはそれでアリなのかなっていう
どうなんだろう
コトリンとかSwiftかける人だったら
フラッターぺろっとかけると思うよ
そんな構える必要はないと思うんだけど
来たらやればいい
そうそう来たらやればいい
それこそパフォーマンス上がってきて
おいしい時になったから
よいしょって入ってもいい
ですね
僕はもう完全に全部やればいいじゃん派なので
そうなんです
Swiftもコトリンもダートも似たようなもんなんで全部
Android開発を完全にフラッターでやっちゃうっていうのは
アリなんですかね
Androidのアプリをコトリンとかで書かないで
ダートだけでやる
そうです
IOSとかを考えずに
Android案件を受ける人が
フラッターのみでやるっていうのはアリなんですか
それはコトリンとかJavaで書かないことのデメリット
明らかに性能劣化するんですよ
IOSにポートしないのに
わざわざダートを使って物を作るっていう部分が
何かメリットあるのかなって
私が今去年ぐらいから
フラッターのTwitterクライアントを移植してるって話したんですけど
この移植元を作ってるGPAで公開してる人は
IOS持ってないからAndroidだけ作って公開してるんですよ
48:00
IOS向けのこと全然考慮してないから
誰も移植できてないんですよね
1年半ぐらい経ってるの
それはプラグインがAndroidのがっつり食い込んでるプラグインを使ってるっていうのと
国際化が何も考慮してないから
自分たちの言語にポートできない
英語でしか動かないTwitterクライアントなんです
そこに手を入れて複数言語を対応できるようにして
IOSとAndroid両方動くようなプラグインの調整をしてるだけで
1年ぐらい時間かかった
IOSエンジニアもAndroidエンジニアも
暇だったら手を伸ばしていいんじゃないとは思いますけどね
勉強する分でやっといていいと思うけどね
宣言的UIを学ぶっていうモチベーションだとすごくいいプラットフォームだと思っていて
やっぱり先行してた分すごくよくできているのがあるので
そういったモダンなスタイルの書き方を学びたいというモチベーションの方は
ぜひ手を伸ばしたらいいんじゃないかなと思っています
対VS SwiftUIだと宣言的な
SwiftUIはちょっと今不買いたい結果になってるかなと個人的には思ってますね
それはうまくいってるんですね
一番つらいのはやっぱりOSバージョンに縛られてしまう
SwiftUIの使える機能が
なのでなかなか実プロダクトで採用しにくくて
採用例もまだ少なくてちょっとつらいなっていう感じありますね
でも宣言的なUIを学ぶために暇だったらやればいいんじゃないっていうレベルであれば
iOS15以上にしたSwiftUIっていう手はありますよね
わかりました いい感じに酔っ払ってきましたね
読んでは
読んだら結構いい感じですね
僕もやっと最近SwiftUIデビューを
昨日の祝日に案件で
いやこれSwiftUIでいいんじゃないかなと思って
iOSただそれ12からサポートだったんで
12 13切っていいですかって今日話したら
いいですよって言われたんで
昨日書いたコード使えるって思いながら
フラッターで何気なくさらっと書いたら
iOS10以降対応できちゃうっていうのがいいっちゃいいですよね
独自レンダリングエンジンのメリットは
この辺はありそう
自分もSwiftUIがまともになるまで
ちょっとフラッターでプラットを散歩しようって
出かけたはずなのにいつの間にかフラッターでいいやになっちゃったっていう節もあるんで
そこもiOSネイティブの若干のリスクかなと思ってて
新しい言語せっかく出てきたのに
SwiftUIなんてもう2年3年経つのにまともに使えないみたいな感じになってて
51:02
でもホームウィジェットとかはSwiftUIじゃなきゃ書けないみたいな縛りが
また逆にあったりとかっていうのがあって
言語がネイティブだから安心っていうのもまたそういうところも見ちゃうと
今回はたまたまフラッターに散歩してみたらそこそこ良かったからやってみたっていう感じにはなってるけど
ネイティブだから何でも安心っていうわけでもまたないのかなっていう気はしますね
これは大いにありますね
なんかずっとベータ開発だなって思いますねSwift UIの特に
僕昨日やってこれiOS17ぐらいだったらいいのかな
17ぐらいから使ってもいいのかなって
逆に言えばフラッターにせっかく旅だったとしても
ホームウィジェットとか作ろうと思ったらネイティブで書かざるを得ない部分はあるので
そういうところを全てフラッターでカバーできるわけではないっていうところもあるんで
安倍さんがちらっと言ってましたけど
iOSの根っこの部分何も知らないでXコード全然触らないでフラッターから始めたら
間違いなく地獄見るよねっていうのはあるかなって気がしますね
それはマルチプラットフォーム何でもあるんですよ
逆にiOS自分やってたじゃないですか
それでフラッターでAndroidをリリースした時ってあんまりハードル感じなかったんですよね
これは不思議
それはすごいことですよAndroidネイティブだとやっぱりついですよね初見は
ついっていうかビルドした時のAndroidマニフェストとかグレードルのところでエラーがいっぱい出てきて
その対処はAndroidのドキュメントを読めってところが最高にきついよね
なんでそこマイグレーションするようなことやってくんないんだよって
どのファイルの直せとかっていうのが全然書いてなくってさ
でGoogleって開発フォーラムみたいなのないじゃないですか
そうなんですか
Googleプレイの中でサポートできるフォーラムってないですよねあれ
今のAppleのやつみたいに
全然困らなかったから探そうとも思わなかったですね
あれでもSDK周りのビルドで困ることないですかAndroid
それがAndroidネイティブで書いたらって意味ですか
ネイティブじゃなくてFlutterでもネイティブでも
ちょっと時間経ったプロジェクトをビルドしようとした時に
Androidマニフェストのこの項目はSDKいくつから使いませんとかなくなるとか
新しく増えたんでこっちを使わないと古い記述は無効ですとかっていうのがいっぱいあって
一体俺はどこの文章を読めばいいんだろう
その辺はFirebaseをバージョンアップするたびに書き換えなきゃいけないっていうポイントになったりします
54:08
マニフェストファイルの自分ルールの変更が激しすぎて
それへんAppleはXコードを進める時に勝手に直してくれて
Androidスタジオそれ一つもやんないから
毎回毎回何かあるたびに直したり
何かハマったあとJava8を使わなきゃダメだっていう
そういう設定を書かなきゃダメだとかそういうのはよく遭遇しましたね
まだJava8なのAndroidスタジオネイティブでやるときって
Java1-8ってちゃんと書かないとか
そっかオラクルがフリーのやつ出さないってなったから入れなくなったのか
あれでもMicrosoftがその後フリーのJDK出すとかってなってどうなったんだ
そっちは使えないんだ
すっかり最近やってないからあれだけど
Android単体の開発でも苦労しちょい込むのに
そこにさらにダートだけにするっていうメリットがあんまりないような気もするんだけどね
Android開発はマニフェストから開放されるんだったら
仕様変更してダートになってくれるんだったらいいだろうなというのはありますけどね
その辺のマニフェストの書き換えがAndroidのほうの疑問になってて
iOSのほうはXコードをアップデートしたときに
一回走らせておかないと中身のライブラリ書き換えられないから
iOSのシミュレーターが走らないとかっていうところがみんな引っかかってたりしますね
やっぱりXコードとAndroidスタジオで開発するときのセオリーを知らないとうまくいかないということですね
そうですね
それはもう絶対的にAppleのXコードは独特かなという気がします
ココアポッツでつまずいてる人多そうなイメージありますか
そうですね
ココアポッツはなんか
ココアポッツ仕組み的にはファイル持ってきてダウンロードしてきてビルドするってやつだから
スクリプトとしてはすごく素直だと思うんですけど
それ読めない人たち何やってんのって感じなんだけど
ホットファイルとかの記述が難しくてつまずくというよりは
Rubyのローカルマシンの環境とかその辺の構築がうまくいってなくて
ここはPodが動かないってことか
そうです
RubyのバージョンもMacのOSで変わったりするからそれか
そういうトラブルにあっている人が多そうだなって見てて
それはAppleが良くないよね古いバージョンのRubyずっと使ってるでしょ
アンドロイドスタジオをターミナルから起動しないと
Podがまともにインストールされてないみたいな認識されちゃうとか
57:00
そういう問題もあったりしますね
さてそろそろざっくりとまとめに入りましょうか
なんかね時間がね
終わる気がしない
もう10時半じゃん
まとめとは何だぐらいの感じですけど
いい話も悪い話も
悪い話よりのいい話も聞けたような気がしますね
そうですね
じゃあ最後ねずっと喋ってない水口さんに一言で何か
これ聞いてねFlutterに興味持った人はまずとりあえずやってみるのがいいんじゃないですかね
当たり前に
触ってみてわからなかったらまたちょっと次進むっていうところとか
あとなんかオンラインで書籍とかも無料で結構読めたりするので
非常に入門って言ったらまあいいのかなと思うんですよね
マルチプラットフォーム開発っていう感じで
まあとはいえ僕もFlutterをやりつつも
iOSのSwiftを復習し始めてるっていうような感じなので
まあそのFlutterだけっていうよりかはネイティブどっちか
っていうのもやりつつやっていくのが
まあいいんじゃないかなっていうような感じで僕は今話聞いてました
ただまあその人々それぞれのそのリソースの使い方
リソースのあり方それから会社の
なんだ開発の方針とか違うので
違いにどれがいいんかなっていうのはまあ分かんないかなと思うんですけど
まあFlutter、Googleも力を入れてバージョンアップとかもしているので
まあすぐにこうやっぱダメだっていう風になるものではないんじゃないかな
というような楽観的な予想をしつつ
これからも見ていきたいなと思います
すごい綺麗にまとまりましたね
まとめ上手
ちょっと無茶振りだったかなと思ったけど
お母さんもう酔っ払ってるから何でもありません
いつもは失敗するんですけどね
じゃあ今回はこんな感じで終わりにしましょう
じゃあ皆さんありがとうございました
ありがとうございました
番組のご感想や話題のご提案などは
このポッドキャストの概要欄にあるお便りフォームでお寄せください
ハッシュタグやスタップでの感想ツイートも大歓迎です
それでは今回もお聞きくださりありがとうございました
