今更Build Testable Apps for Androidを見て驚いたところメモ - Qiita
概要 去年のIOで少し古い動画なのですが、すごくいい動画なので、見てみてください。 特に驚いたポイントを太字にしています。 かなり端折っているのでおかしいなって思ったら動画の方を確認してください。解釈が違いそうっていう所があればコメントか修正リクエストをください https://www.youtube.com/watch?v=VJi2vmaQe6w テストにおいて、キーとなるアトリビュートはスコープ スコープは一つのメソッドでテストがアプリケーションのどのぐらいカバーしているのか、または複数の機能、複数の画面にまたがることはできる。 スコープはテストの他の2つのアトリビュートに影響を与える。 → スピード ミリ秒単位で終わるものもあれば何分もかかるものもある。 → Fidelity(忠実さ) テストケースのシミュレートが、どのぐらい本当の世界のシナリオに近いか。スコープを広げれば広げるほど
DroidKaigi 2022のセッションで驚いたところ - Qiita
md.sys.color.on-secondary ↑ デザインシステム名 md.sys.color.on-secondary ↑ Design Tokenの種類。これは `sys` なので、システムトークン md.sys.color.on-secondary ↑ トークンの役割を伝えるための名前(colorとon-secondary) (Component Tokenは今のところ使われていない) 主にSystem TokenとReference Tokenが使われる。 System Tokenに対して複数のReference Tokenがありえる。 https://m3.material.io/foundations/design-tokens/how-to-read-tokens System Tokenのほうが抽象的なもので、ダークモードなどのコンテキストによってReference
2022年のAndroidプロジェクトセットアップ - Qiita
Qiita Nightの資料になります。 ↑ 右下の拡大ボタンを押すと読みやすくなります。 https://increments.connpass.com/event/251564/ どうAndroidプロジェクトをセットアップするか？ takahiromという名前で活動しています。 Androidが好きです。 GDE for AndroidやDroidKaigi Co-organizerやCyberAgent Developers Expertなどの活動をしています。 初めてQiitaスライドを使いました。 初めてAndroidアプリを作りたいという方 Googleから公式のチュートリアルが提供されているので、最新のAndroidの開発について確認してみてください！一緒に開発していきましょう🙌 https://developer.android.com/courses/android
KtLint + Spotless + GitHub ActionsでPRにsuggested changeさせる - Qiita
ちょっと30分ぐらいで書いた小ネタで申し訳ないんですが、すごく簡単で、便利なので、アドベントカレンダーで紹介します。 Android Studioの自動フォーマットだとKtLintで指摘されるものを修正できず、Formatterをコミット前やビルド時に走らせるのもコード量に比例して遅くなりそうで、また変更したところだけフォーマットさせたいですがうまくできません。コミットのたびに時間かかりそうで微妙で、なにか解決策を探していました。 これを調べ始めて30分程度でできちゃったので、すごく簡単に機械的にレビューさせられるので、ちょっと試してみてください。 インデントを直すsuggested changeの例 使うツール Spotless 変更したファイルを検出してFormatterを呼び出してくれたり、いろいろな機能があります。(JetNewsなどGoogleのOSSなどでも使われています。)
どの方法で柔軟にAndroidのGradleのビルドロジックをまとめるか - Qiita
いくつかやり方があり、それぞれメリデメがあるようなのでのでまとめておこうと思います。 nowinandroidがComposite Buildを導入したことで、話題になりました。 ちょっと調べてみたんですが、これが最強というのは見つけることができませんでした。かなりプロジェクト規模によって異なってきそうです。メリデメ見ながら採用していく必要がありそうです。 ここではある程度大規模だが、Androidアプリでビルドエンジニアを雇うほどではないという想定をしています。 以下で色々試行錯誤していました。 どこにビルドのコードを置くのか？ buildSrc プロジェクト/buildSrcにコードを書く方法。 メリット 色々魔法をGradleが使ってくれるので簡単 小さなプロジェクトではこれでも大丈夫。 プラグインとextension以外が公開できない。Kotlinのextension functi
Google I/O 2022で驚いたところ - Qiita
個人的に驚いたところを太字にしておきます。 AndroidのエンジニアなのでAndroidに関するものが多めです。専門領域外のものはかなり素人目線のただの感想が多いです。なにか大きな間違などがあればご指摘お願いします。修正いたします。 またまだ見ていきますが、一旦、 Keynote Developer Keynote What's new in Android What's new in Jetpack What's new in Development tool Lazy layouts in Compose Fragments: The good (non-deprecated) parts を見たメモを書いています。 まだまだ、ここに追加していく予定です。 セッション: Keynote 今までは2言語の比較を見ながら機械学習をしていたが、翻訳を見ずに学習ができるようになった。これによ
Architecture: Live Q&A - MAD Skillsメモ - Qiita
これを書いている時点では正確な字幕はまだ手に入らなかったのと、かなり意訳なので直接見てみてください 結構普段の開発で論点になる部分が多いので、面白かったです。 なにか致命的な間違いなどがあれば教えて下さい また、わかりにくければ動画を見てみてください LiveDataはdeprecated？ そうする必要はないので、deprecatedになっていないので、使い続けてOK。 ただ、StateFlowもFirst classでサポートしている。 なぜBusiness logicをデータレイヤーに持っていくのか？そのモチベーションは何？ single source of truthを実現して、並行実行や再利用性の管理もできる。 strings.xmlのようなリソースにViewModelでどのようにアクセスするべきか？ ViewでもComposableでも基本的にViewModelはアクセスすべき
API Guidelines for Jetpack Composeを読んだメモ - Qiita
こちらにあるドキュメントです。 ある程度Composeを触ったことがある人向けのドキュメントだと思います。開発チームなどでComposeやっていく人は一読の価値があるかなと思いました。 The Compose API guidelines outline the patterns, best practices and prescriptive style guidelines for writing idiomatic Jetpack Compose APIs. As Jetpack Compose code is built in layers, everyone writing code that uses Jetpack Compose is building their own API to consume themselves. Jetpack Compose API をidi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
