Flutterやろうよ!!! 2
■ このスレッドは過去ログ倉庫に格納されています
ようこそFlutter野郎どもよ!!!
軽い開発環境でモバイルアプリ開発ができるなんて最高じゃねえか
AndroidもiOSも両方行ける、まさに漢のためのツールだな
https://flutter.dev/
前スレ
Flutterやろうよ!!!
https://mevius.5ch.net/test/read.cgi/tech/1527919660/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured お花畑だなあ
アプリストアビジネスの負け組2社がタッグを組んで、AppleとGoogleのシェアをちょっとでも切り崩そうという企みなのに なぜマイクロソフトは自身で独自のAndroidストアを立ち上げなかったのか?
Googleが築いてきたAndroidの世界をそのまま取り込んでしまってもよかったのではないか?
GoogleよりもMicrosoftのほうが開発環境は素晴らしいのだからワンチャンあったのではないか? >>751
あくまで、Androidを取り込んで最終的には消滅させるのが目的だからでは?
積極的にAndroidを取り込んだというより、Windows Subsystem for Linux (WSL)
や、ARM版Windowsの互換性(ARM上でのx86/x64アプリ実行)向上を進めた結果の
副産物だと思う。 >>751
Java/C#系統の開発環境はMSよりGoogleが依存しているJetBrainsの方がちょっと優れてると思う
VisualStudioにJetBrains系IDEの機能を追加するこんなものがある程度商売になってるみたいだし
https://www.jetbrains.com/ja-jp/resharper/
俺がAndroidStudio使っているときにはこのクイックフィックスやリファクタリングの機能にものすごい依存してる cocoapodsがmacのm1に対応したら教えてください まじなの!?じゃあrosseta2使わなくても環境構築できるのか!!! >>756
去年の2月から中規模アプリ4つリリースしてるし AndroidとiOS用にそれぞれMaterialとCupertinoで作った画面を表示したい場合って、ほぼほぼ同じ画面を2回作ることになるの? プロジェクトで使われているFlutterのバージョンって
Flutter upgradeをしただけでは上がらないのでしょうか? イギリスの新規感染者数グラフのカーブがヤバイ
ワクチン効果なしかーー 前から決まってた事だろうけど
この時期にやるのはWindows11とアマゾンに対する
地味な嫌がらせかな?
Google公式アプリストアの新アプリ受付は8月からAPKではなくAABに
https://www.itmedia.co.jp/news/articles/2107/01/news122.html >>765
Embarcadero(Borland) の C++ Builder の、Androidポートは、
64BITに対応してないのでそれだけでもGooglePlayには登録できなくなってる。
恐らくaabへの対応もきっともまだなので Borland潰しになってる。 64ビット対応できない弱小ソフトメーカーは放っておいても潰れるのは時間の問題だと思う そもそもAndroidは、Java/Kotlinが基本で、それだと、64BIT化なんて関係ないん
だから、マシン語を使うC++ような言語だけが64BIT化を強制されるのは
独占禁止法違反。 64BIT化して何割も高速になるのならまだしも、実際には高速化されるかどうかは
ケースバイケースで、遅くなるケースもあり、実際の例では、高速化される
としても数%程度なことが多いはず。
Java/Kotlinだけにくらべて、C++を使うと(マシン語に直されたところの)
ロジック部分は簡単に2〜3倍に高速化される。それだけでも十分で、
64BIT化しても、ほぼ高速化になった恩恵は受けないどころか、メモリ効率は
むしろ落ちる。
また、Java/Kotlinだけだと、64BIT化されてもビルド時間は増えないが、C++を使うと、
ビルド時間も倍かかるようになる。数%の速度向上のためにビルド時間が倍掛かるのはおかしく、
本来は、どうするかは開発者の判断にゆだねるべきなのに、32/64の両対応が強制される。
これも独占禁止法違反だと思う。 C++のようなマシン語に直される言語を使った場合、これからは、テストもほぼ、
倍かかるようになってしまた。
Java/Kotlinだけだと一回のテストで済むのと比べて不利。
原理的には32BITだけでもアプリユーザーの体感速度は数%しか変わらないのに、
ただただ、開発者に手間をかけるだけの施策。 googleというよりarmのチップで32bit命令対応しなくなるんだから
cortexX2は対応
cortexA710は非対応
cortexA510は対応
bigコアが32bit命令を実行できない 数%も速度向上できるなら例えビルド時間が10倍になってもウェルカムと考える俺が少数派なのか? >>773
C#は、速い場合でもC++の1.5倍くらい時間が掛かることが多いが、
ウェルカムな人が多いから、あなたは少数派だろうな。 >>774
昔々、ビルド時間が数時間なんて当り前の世界で育ったので、今のコンパイラのターンアラウンドタイムはほとんどゼロに等しくてセロを10倍しても誤差と思っちゃうわ。
ぶっちゃけ老害と認める。 >>776
ああ、俺も昔仕事で大きいシステムやってた時は、半日以上かかるのやってた事あるわ
ライブラリビルドするのに半日、それ使ったシステムのビルドにまた半日とかw
まあ、そういうのはビルド流して他の事してるから、インタラクティブなビルドの時間とは単純な比較は出来ない気もするけどね >>779
遅くてもC#でなければプログラミングできない層がかなりいるからだと思うが。 エスパーの人に教えて欲しいんだけどさ
チュートリアルのプロジェクトで、VSCodeで保存してChromeで動かそうとすると
Waiting for connection from debug service on Chrome...
みたいに出て数分間待たされる
待たされる原因や、原因の調べ方を教えてくれんかな?
ディスクもCPUもメモリも食っていなさそうで、本当にメッセージ通りChromeの応答を待ってるだけなんじゃないかと思うんだけど・・・・なんでこんなことになるんだろうか・・・・ すまぬ、Flutterのアップデートしたらだいぶ改善したわ
ファイルが壊れていたのか一部のバージョンがおかしかったのか原因はわからんが・・・・ Ruby, Selenium Webdriver でも、
Chrome は自動更新されるから、
Chromeドライバーのバージョンと不一致が起こって、動かなくなる
その都度手動で、新しいドライバーをダウンロードしないといけない。
そのダウンロードを自動化した、モジュールもあるけど flutter upgrade
flutter clean
してみ ディレクトリ構成って本当に悩む
あとクラス名の付け方も悩む
このあたりPHPのPSRみたいにルール決まってたらいいんだけどな fucsia で end-user が使う言語は、dart(flutter)と書いてある資料もあるが、
別の資料では、end-user向けにサポートされている言語は、C、C++、Dartとある。
システムコールはC形式。
少なくとも、第一言語は、AndroidのようなJavaやKotlinではない。
APIがCなら、Androidより速度は向上するだろう。 競合他社にイニシアチブ与えるようなことするわけ無いだろ >>788は結構デタラメだから気にするな
エンドユーザはつまるところOS使用者なのでプログラムを書かない。開発者はC/C++やDartの他にRust、Go、Pythonはサポートされる。
システムコールにC形式とかはない。FichsiaではZirconというカーネル群があって、そいつを呼び出す。
全部fuchsia.devにあるからデマを信じないように
本人はデマのつもりは無いんだろうが >>793
ABIに言語は関係ない。関係あればそれはAPIと呼ぶ
それはCで書かれた関数をコンパイルしたバイナリを呼ぶという意味。バイナリの時点で言語とは切り離されてる
システムコールもそうだけど、結局バイナリに対しての呼び出しだから、もし言語云々言うのならアセンブリ言語のレベルでないと扱えない。CもRustもシステムコール時に内部ではアセンブリ言語を呼んでるみたいね 元レスのC形式ってそういうことでしょ
他の言語から呼び出す場合はffi経由でないと呼び出せない。rust向けのapiもcをラップしてるだけ。
システムコールを実行するには最終的にsyscallやsvc命令を呼び出さないといけないのだから一部アセンブラで書く必要があるのはどのOSでも当たり前なんだが >>796
まじかよ。正直スマンカッタ。
flutter+swiftでiosアプリの流入促進でも狙ってるんだろうか… 需要があるかは知らんが、Windows 11でAndroidアプリが走るようになるし、
OS下剋上、戦国時代へ突入かね? >>795
一応、機械語でもいい。特にCやRustは機械語でもおかしくないような気がする。まあ対応づいてるけどね
それから振興OSに当たり前が通用するかわからんじゃんか 一応とか気がするとか分からんじゃんとかフワフワしすぎ >>791
使えることと基本にしていることとは違う。
Androidも、Cは使えるが、APIの基本は Java/Kotlin。
Cを使う場合でも Java/Kotlin が必須となる。
一方、Windows/Linux/Unix は、Javaも使えるが基本はC。
Cを使う場合、Cだけで済む。
Cは、マシン語と直結しているので、Java/Kotlinを含めたあらゆる
言語と相性が良く、Javaだけで作る場合のモードチェンジも必要ない。
一方、Java/Kotlinは、マシン語と直結していないので、
他の言語とはとても相性が悪く、必ず JNI というモードチェンジ
の仕組みを使わなければ成らず、Cだけで書こうと思っても、
必ずJNIを使ったモードチェンジをある程度の頻度で行うことが必須となる。 >>801
[補足]
1. OSのAPIがCを基本としている ---> APIがマシン語のインターフェースを基本としている
--->どんな言語でもモードチェンジ無しで最高効率で動く。
(Cは、マシン語と直結しているので、ABIでもありAPIでもある。
マシン語とCの違いが実質的に無いと言えば無いので、Cというよりも、マシン語の
インターフェースであり、それより高速なものが存在して無いとも言える。
ありとあらゆる言語の母体である。)
2. OSのAPIがJava--->他の言語を使う場合、Javaとの間でモードチェンジが
必須となり、最高効率で動くことは出来ない。
Javaのクラスやメソッド群をAPIと考えると、それらはマシン語ではないので、
APIとABIに意味の開きが出てくるのが、1とは違うところである。
Javaは、Cとは違ってマシン語とは言えないので、他の言語の母体とはならず、
他の言語を使う場合、Java言語で、他の言語のインタプリタを直接作る場合は除き、
いったん、マシン語モードに切り替えるために JNI が必要となる。
1の場合、Cがマシン語とも言えるのでCを基本としているといえるのかどうか
意見が別れるとも言える。 [補足]
WindowsやLinuxは、OSのAPIはC風であり(それはマシン語のインターフェースでもある)、
それしかサポートしていないとも言えるが、Cが余りもマシン語と近いために
他のあらゆる言語は、サポートしなくてもほぼ最高効率で動くことが出来る。
サポートしていなくてもあらゆる言語が Windows で動き、あらゆる言語で
アプリケーションを作ることが出来る。
一方、AndroidがOSとして基本サポートしているのは Java/Kotlin のみ。
Cは重要すぎるため、社としては、NDKでJNIを通じてサポートはしていると
言えばサポートしてはいるが、それでもアプリの基本が Java/Kotlin であるため
必ずモードチェンジが必要となる。
一方、Fuchsiaの場合は、OSがサポートしているのは、CとDartだと書いてある。
これは、他の言語でアプリが作れないことを意味するのではない。 残念ながらワクチンに予防効果は無い、貫通しまくり、それでも重症化も死亡者も少ないから良いといってるが
イスラエルの場合だと、未接種者より接種者のほうが死亡例が多くなってる
↓
イギリスの1日の新規感染者3万人超す 1月以来最多
https://asahi.5ch.ne...newsplus/1625750338/ >>801
>Cは、マシン語と直結しているので、Java/Kotlinを含めたあらゆる
意味不明w Cの呼び出し規約がマシン語とイコールのように読み取れるけどさすがにそれは誤解招くでしょ。 すまんがこれ、コンテナにListViewを入れるとエラーが起きるのは何故なんだぜ?
画面の一部だけリストにしたいとかあかんの? >>807
どういうエラーか分からんが、hasSizeうんたらってエラーならListViewがサイズ決められないって怒られてる。
ListViewの外にExpandedとか置けば直るはず。 >>808
まじか、ありがとう!
もしかしてViewってついてるやつは特殊なのか!?とか思ったり、わけわかんなかった dartって複数種類の型を持つListって定義できないのか。TypeScriptでいう[number, string]みたいな >>810
本当になんでもいいならList<dynamic>でいけたはず
int, String固定なら、それぞれどういう用途で使うかに対して名前をつけるというのがいいんじゃないか
例えばint age, String nameだったら
abstract class PersonData {
final value;
PersonData(this.value);
}
class PersonAge extends PersonData✓{
final int value;
Age(this.value) : super(value);
}
class PersonName extends PersonData {
// 略
}
とかしておけば、List<PersonData>に入るのはPersonAge, PersonNameという役割を持ったint, Stringになる
クラスの作り方はもっと良い方法あるかも… 継承を使わずコンストラクタで
Person.fromAge
とか
Person.fromName
とかもありかもね。
この場合も値の内部保持はdynamicだけど。 いやー確かにデータ構造としてはそれでいいんだろうけどね
事情としては、APIで取得するJSONがそういう値でjson_serializableでそのままfromJson出来なくてなんだかなあとなっている
TupleのGoogle謹製のパッケージはあったけどjson_serializableと組み合わせるのは難易度高そうだった Json形式のデータから、ディクショナリ(Map)構造に変換するパッケージがあった
ような記憶があるけど、今すぐ名前が思い出せんな。 >>813
Tupleはあくまで値のペアを格納するものなのでちょっと目的とは違うくない?
俺も同じような事で悩んだけど、結局一旦dynamicで受けて適切なエラー処理を入れながら目的の型に変換した記憶が。 指定した時間にアプリを自動起動する方法ってFlutterじゃ無理ですか? >>816
やりたいのは、こげなこと?
ttps://rinoguchi.net/2021/04/flutter-background-timer-app.html >>817
Google純正の時計アプリなんですけど
アラームを設定してからアプリを閉じても、指定した時間にアプリが起動して音が鳴るんです
バックグラウンドではないのにアプリが立ち上がる、そういうことがしたいんですね
https://play.google.com/store/apps/details?id=com.google.android.deskclock&hl=ja&gl=US >>818
Flutter/Dartの問題というより、プラットフォーム(OS)依存になると思います。
Windowsだとタスクマネージャーに登録しますが、Androidの場合だと、
ttp://android-note.open-memo.net/sub/activity__autorun.html
のようなことをする必要があります。 Flutterから使う場合、以下のようなパッケージが
あるみたいです。 但し、Android限定です。 iOSは判りません。
ttps://pub.dev/packages/android_alarm_manager (旧)
ttps://pub.dev/packages/android_alarm_manager_plus 質問させてください。
現在、次のような状況です。
1,CustomPaintで画面サイズより大きな画像を、画面内だけ描画
2,GestureDetectorのonPanUpdateのdeltaを用いてcanvasのoffsetを変更して画像を移動
この状況で、描画する画像が大きいため、スクロールバーで一気に移動したいときがあります。
しかし、一方向のSliverの並びではScrollbarとCustomScrollViewの子要素にすればよいのですが、上記の状況ではViewport(?)などが設定されておらず、簡単にはスクロールバーを実装できません。
それっぽい四角を配置するのではなく、Scrollbarウィジェットの子要素として配置できる形で実装したいです。
何かを継承して、viewportの大きさなどを指定するのだと思うのですが、ソースを読んでも理解できませんでした。
もし分かる方がいれば教えて下さい。お願いします。 >>819
ありがとうございます
ためしてみます! >>821
どうやら「flutter_local_notifications 」パッケージを使った方がよさげな模様。
これなら、AndroidだけじゃなくiOSもいけるっぽい。
ttps://ichi.pro/flutter-no-tsuchi-to-ara-mu-41660884726638
ttps://stackoverflow.com/questions/61905143/how-to-create-alarm-app-in-flutter-for-ios
https://pub.dev/packages/flutter_local_notifications Flutterをちょっと触ってみた感じだとAndroidStudioでもVSCodeでも使えるけど、
スマホアプリを作るのにどっちがオススメとかありますか?
普段はスマホアプリをAndroidStudioで作って、VSCodeでPythonを書いてるから、感覚的にはどちらでも良いんだけども
エディタの違いだけだから好きにしろってのが正解? 私は初心者なのであまり参考にならないと思いますけど
AndroidStudioでできることがVSCodeでもできるならVSCodeのほうが良いのではないでしょうか
開発環境のメモリが足りないなどでIDEが思いなら私はVSCodeを選ぶと思います。
ただメモリに困っておらず快適なのでAndroidStudioを使っています
IDEでやれることをVSCodeでも同じようにやれるかどうかはVSCodeのプラグイン次第なので
そこの学習コストや調査コストにかけられるかどうかで洗濯してみてはいかがでしょうか。
ちなみに私はVim使いですが、やっぱりVim上で完結できない機能もあるので
AndroidStudioを使います 個人的にはVSCodeがおすすめ
ビルド状況の確認は確かAndroidStudioでしか出来ないけど、開発のしやすさは多数の拡張機能が揃ってるVSCodeの方がしやすい印象
軽量で、他の言語とかで使ってた拡張機能も使えるものも多くて環境も揃えやすい >>824
vscodeはideじゃなくて所詮汎用のエディタ
基本性能が劣るから使いたくない
色々な表示が見にくくてカスタムしても足りない
flutterのプラグインにinspector, performanceとかの機能がたぶんない
起動は早いかもしれないけどインデックスとかを起動時にしないだけでメソッドの使用箇所とかの最初の検索時に長く待たされる
メモリはくわない
android studioはide
カスタムしなくても使いやすい
flutter開発用のタブやツールバーがある
リファクタリングの機能が強い
プロジェクトの設定やrunの設定がしやすい
自分で使って決めるのがいいよ
メモリが辛いからvscodeを選ぶのはダブルベッドが快適なのに部屋が狭いからシングルにするようなもの
>>826
> 他の言語とかで使ってた拡張機能も使えるものも多くて環境も揃えやすい
有料のintellij ideaなら他の言語の拡張機能も使えるらしいよ VSCodeでもインスペクタあるじゃん。
俺はVSCode派。
色々拡張使ってるから、Android Studioだとイマイチ。 >>827
他の言語で使ってた拡張機能ってのはそういう意味じゃなくてVSCode自体のエディタ拡張のこと
単語の誤字を見つけてくれるだとか、対応する括弧に同じ色をつけるだとか、フォーマッターとかGit関連とかリモート開発とかそういうの
言語によらない一般的な機能はDartにも適用できるから、今までの開発環境そのままでFlutter開発ができるイメージ
そしてインスペクターはVSCodeにもある VScodeはカスタマイズ出来ない人には辛いかもね
玄人向きだ 実態はどうあれVSCodeはIDEではなくコードエディタ VSとか使う気にならないぐらいの
スーパーなエディタ >>828 >>829
> VSCodeでもインスペクタあるじゃん。
> そしてインスペクターはVSCodeにもある
vscode内で使えないと「vscodeにもある」とは言えないけど使えるようになった?
前はvscode内で開けなくてブラウザを開かないといけなかった
>>829
> 今までの開発環境そのままでFlutter開発ができるイメージ
intellij ideaはjava, dart&flutter, c++他いろいろに使えるんだから同じことじゃん > 色々拡張使ってるから、Android Studioだとイマイチ。
それは逆も言えるよね
android studioの拡張を色々使ってるからvscodeだとイマイチ >>834
VSCodeの中でInspectorとかPerformanceとか開けるようになってるよ
ブラウザで開く機能も残ってる >>834
VSCode内で開ける。
IntellJは仕事で使うにはライセンス買わないといかんので、布教しづらいのもある。 >>835
Android Studioの拡張より、VSCodeの拡張の方が自由度高いと思うが、
それでも、Android Studioの拡張が良いならそれでいいんじゃない?
Rainbow csvとか便利よ。 IntellJって有料だったの?と思ったらおいどんはオープンソース活動してたから無料で使えてただけだった >>837 >>838
へえ使えるようになったんだね
>>839
rainbow csvはandroid studioにもあるけど何か違うの?
他にもっと便利なcsvもあるし
自分が使ってる特定の拡張が使えないと困るとかそういう話ならそれも逆が言えるからvscodeのほうがいい理由にはならないね >>840
community版じゃね?
万能なのはultimate >>841
違わないと言えば違わないし、違うと言えば違うわな。
どうしても推したいわけではないし、話が噛み合ってないと思うわ。 >>843
え?
両方見たら同じにしか見えなかった。 IDEとエディタのどっちが上話は宗教戦争にしかならんからやめれ 普通はどっちかしか使ってないし、調べもしないから話が噛み合わないね
ここまで意見割れるなら結局どっちも一度使ってみるのが良いんじゃないかってのに戻るよな 基準をしめしてこういう部分はこっちが上という話であれば建設的になるかもしれない >>843
矛盾したことを言っといて屁理屈言う人とはまあ噛み合わないね
でも意見は一致してると思うけどな
合うほうを使えばいいって考えだよ >>844
差なんか見つけようと思えばいくらでも見つかる。
水掛け論よ。
>>849
俺も合う方を使えば良いと思うよ。 ■ このスレッドは過去ログ倉庫に格納されています