Jetpack ComposeとGraphQLによるServer Driven UI/jetpackcompose-grahpql-serverdrivernui関連資料 宣言的UIの状態管理とアーキテクチャSwiftUIとGraphQLによる実践 https://speakerdeck.com/sonatard/swiftui-graphql 宣言的UI https://speakerdeck.com/sonatard/xuan-yan-de-ui
【Android】FlipperのCustomPluginを作成してデバッグ効率を改善する - Mirrativ Tech Blog
Mirrativ Androidエンジニアのmorizoooです。MirrativではデバッグツールとしてFlipperを使っています。Flipperはモバイルアプリデバッグのためのデスクトップアプリケーションで、アプリ内のデータの整形や可視化を行うことができます。また、Flipperはネットワークの通信状況を確認するNetworkPluginなど、標準でいくつかの機能が用意されています。詳細についてはこちらをご覧ください。 tech.mirrativ.stream Flipperは標準機能だけでなく、独自のCustomPluginを作成することもできます。MirrativではCustomPluginを積極的に作成し、バグ調査や開発効率の改善に役立てています。一つ例を上げると、Mirrativではコメントやギフトの機能のために、WebSocketベースの独自のPubSubライブラリを使用し
メルペイ Android のアーキテクチャとテスト | メルカリエンジニアリング
こんにちは。Merpay Advent Calendar 2019 の18日目を担当する、メルペイ Android チームの @KeithYokoma です。 前回の記事ではマルチモジュール構成なプロジェクトにおける画面遷移の実装について、簡単な設計の方針から解説しました。 今回の記事では、メルペイ Android 全体として採用しているアーキテクチャやテストの方針について解説します。 全体像 はじめに、メルペイ Android で採用しているアーキテクチャを解説する際に出てくる登場人物を整理しておきます。 メルペイ Android では、Redux の考え方と MVVM を組み合わせて使っています。Presentation は Activity や Fragment に相当する画面のことで、メルペイ Android の場合は前回の記事で触れたとおり bluelinelabs/Conduc
クックパッドアプリ(Android)の開発効率化のためにやったこと/やっていること - クックパッド開発者ブログ
モバイル基盤部のこやまカニ大好き(id:nein37)です。 モバイル基盤部では、CI環境の改善やアプリのリリースサイクル自動化といった開発・リリースフローの効率化に加え、アプリのビルド速度改善や開発のしやすさを改善する様々な取り組みを行っています。 今回はその中から、クックパッドアプリ(Android)に対して行った開発効率化の取り組みの一部を紹介したいと思います。 あわせて読みたい : Android版クックパッドアプリで採用している技術の現状確認 2018年版 日々のメンテナンス系 不要になったソースコードやリソースの削除 Lint設定の最適化/Lint警告の除去 画像リソースのWebP化/WebPおじさん化 minSdkVersion 21 後の変更 Ripple 対応 android:elevation の指定で影をつける *-v21 系代替リソースの整理 ツール導入など And
「ネイティブアプリ開発者は絶滅危惧種なのか？」への感想文 - ナカザンドットネット
ポジション MSがRNめっちゃ使ってるという話について Brownfield事例は実質的にネイティブの事例 Skypeの事例ならどうなのか ネイティブアプリ開発者の仕事は減るのか まとめ みんなの反応 Xamarin勢の反応 Cordova勢の反応 iOSネイティブアプリ開発者の反応 jp.techcrunch.com こちらの記事への雑な感想です。感想は私の主観であり、ポジショントークであり、所属する組織の意見とは無関係であることを先に述べておきます。 また「ネイティブ」という言葉に「C/C++などから作られた機械語」という本来の意味に加えて、「プラットフォームの標準言語（WindowsのC#, AndroidのJava, iOSのObj-C）や標準開発ツールである」というニュアンスを含めることをご容赦ください。 ポジション こんな感じのポジションの人です。 中小企業向けにBtoBでアプ
multi-module-no-susume
DroidKaigi 2018 - Day1 Room1 16:50~ にて発表する内容です
Androidアプリ開発にFluxアーキテクチャを導入したら保守性も品質も上がりました - ZOZO TECH BLOG
こんにちは。フロントエンドエンジニアの茨木（@niba1122）です。 弊社のAndroidアプリ開発ではMVVMアーキテクチャを用いています。日々肥大化・複雑化していくViewModelが保守性や品質を担保する上で課題になっていましたが、Fluxアーキテクチャの導入により改善することができました。 本記事では、実際どのようにFluxアーキテクチャを導入したのかを、設計やコード例を交えながらご紹介します。 今までのMVP・MVVMの限界 アプリ開発ではMVP・MVVMといったアーキテクチャがよく用いられます。弊社のAndroidアプリ開発でもMVVMを用いています。これらのアーキテクチャはビューとドメインロジックを分割するのに役立っています。しかし、昨今のUIには多くのイベントや状態があり、更にそこにAPIリクエストなどの非同期処理が絡んできます。これらが関わるプレゼンテーション層のロジッ
MVVMベストプラクティス
MVVM概要 • アプリケーションをModel / View / ViewModel に分割するアーキテクチャパターン • MicrosoftのKen CooperとTed Petersが開発 • WPF/Silverlightで使われていたが、最近は他 のプラットフォームでも採用例が多い
FlutterでDroidKaigi 2018のiOSアプリを作りました - Konifar's WIP
DroidKaigi2018が来週に迫ってきましたね。 自分もコードで見るFlutterアプリの実装というテーマで発表します。 その題材として、DroidKaigi2018のiOSアプリを作りました。コードも公開しています。 github.com 作った理由は、以前の記事に書いたとおりです。 また、公式アプリではないですが今年はiOSアプリも用意したいなぁと思っています。iOSDC2017に参加した時にAndroidアプリが欲しいと思ったからです。 まだ申請中なので間に合うかどうかわかりませんが、iOS端末がメインの方に使っていただけると嬉しいです。 DroidKaigiの発表では、時間の都合上Flutterの基本的な部分の説明は省くつもりなので、ここで簡単にまとめておこうと思います。 Flutterとは Flutterは、iOS / Androidで動くアプリを作れるクロスプラットフォー
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
Brand new US Mercari (Android 編) | メルカリエンジニアリング
Mercari Android チームの @tsuyogoro です。US 版 Mercari Android アプリの開発を担当しています。 この度、より一層 US マーケットにフィットしたアプリをユーザへ提供し US での成長を更に加速すべく、US 版 Mercari を刷新しました (https://play.google.com/store/apps/details?id=com.mercariapp.mercari&hl=en) 。 クライアントアプリだけでなく API サーバのアーキテクチャも変わり、文字通り大変更が施された訳ですが、本記事ではスクラッチから書き直した Android アプリにフォーカスを当て、何が変わったのか / これによってチームはどう変わったのか、という事を紹介します。 UI が大きく変わりました Before Mercari が US でリリースされたの
メルカリ カウルの開発気になる？なら話そう！
メルカリ カウルの開発 気になる？なら話そう！ shibuya.apk #17 https://shibuya-apk.connpass.com/event/62499/
RettyとKotlinの歩み〜アプリからサーバサイドまで - Retty Tech Blog
RettyでAndroidエンジニアとして働いている福井 と サーバサイドエンジニアの石田です。 本日Googleから「AndroidでKotlin正式サポートする」と発表されました！ 🎉🎉 そんなKotlinですが、弊社では去年2月頃からプロダクトに導入しています。今回はその歩みと一年以上使ってきた感想をご紹介します。 Androidでの導入事例 最初にKotlinを導入したのはAndroidチームでした。タイミングとしては1.0が正式リリースされる少し前から導入を検討していました。 まずはプロダクトと直接関係ない小さなアプリを書き、これで行ける！と判断したのと正式リリースのタイミングがちょうど重なり導入を決断しました。1 プロダクトに導入する際は、新規ファイルを作成する時にJavaではなくKotlinで書くといったようにファイル単位でじわじわKotlin化していきました。今ではJa
4年続くアプリにおけるチーム開発 #DroidKaigi 2017
2017/3/10 #DroidKaigi 2017 でお話した「フリル」のチーム開発に関する資料です
ドメイン駆動設計について DroidKaigi 2017 で登壇しました。
長らく Y.A.Mの雑記帳というブログでAndroidの技術情報を発信しています。最近はなかなか投稿できなくなってしまいましたが、それも仕事としてAndroidに関われているためです。Androidを触り始めたころはまだ学生だったので時間があったんでしょうね。 はじめて Android に関するエントリを投稿したのは 2009 年 5 月 24 日です。当時はJavaFXを触っていたので、NetbeansでAndroidをやろうとしていたようです。 当時のAndroidのバージョンは1.5、Fragment もなく、Support Library もなく、マルチタッチすらなく、ストアは Google Play ではなく Android Market という名前でした。 ここから2、3年くらいは、仕事でAndroid アプリを開発している人はもっぱらメーカーのプリインアプリを作っている方たち
Androidアプリを長く開発し続けるために気をつけている9個のルール - ZOZO TECH BLOG
Androidエンジニアの @nissiy です。Androidが発表されてからもうすぐ10年になろうとしています。長いですね。 実はAndroid版IQON、今年の4月でリリースしてから丸5年を迎えます。ここまで長くサービスを続けられて、かつ3年連続でベストアプリをいただけたのは、使ってくれているユーザーの方々のおかげであると日々感謝しています。 この5年で様々な追加機能の開発を行ってきました。新機能を1つ追加する度に、古い機能を1つ削除することを徹底して開発を進めてきたものの、長く開発を続けているのでそれなりに巨大なアプリになっています。 今回はAndroid版IQONを長く開発し続けるためにチーム内で徹底しているルールをいくつか紹介したいと思います。 当たり前な話ばかりですが、大きくOSのアップデートを繰り返すAndroidのアプリ開発に取っては大事な話ばかりですので、少しでも参考に
DroidKaigi 2017 アプリコード公開してから10日経ちました - Konifar's WIP
DroidKaigi 2017のアプリのコードを公開して10日ほど経ちました。 忘れないうちに今の状況をざっとまとめておこうと思います。 konifar.hatenablog.com PullRequests、Contributors こ10日間のPullRequestは200件くらいでした。Contributorsは60人くらいです。すごくたくさんの方々に毎日修正や改善を送っていただいて、本当にありがたいかぎりです。 公開して5日間くらいは1日30件くらいPullRequestが来ていました。あまりに速すぎて、Issueにアサインしても同じPullRequestが30分くらいの差で送られてきたこともありました。迷惑をかけてしまって申し訳なかったです。 コンフリクトしてしまうと申し訳ないので、基本的にPullRequestはすぐに見ています。小さい修正であれば即LGTMを出し、CIが完了し
DroidKaigi 2017 公式アプリのコードを公開しました - Konifar's WIP
去年、DroidKaigi2016の公式アプリをオープンソースで作りましたが、2017もコードを公開しました。 github.com コードだけではわかりにくいところを少し補足しておきます。 2016とは別アプリ 2016とはリポジトリもパッケージも違います。別アプリです。 なぜ去年のリポジトリを引き継がなかったかというと、個人のリポジトリではなくDroidKaigiのリポジトリとして管理したかったというのが1つ。もう1つは、同じアプリをメンテナンスしてると飽きちゃうし、またゼロから作りたかったからです。 余談ですが、カンファレンスアプリに必要な機能はほぼ決まっているので、モデルや画面をガチガチに固めて設定ファイルとリソースを用意するだけで作れるライブラリに切り出してもいいかもなと考えています。 Kotlin メインはKotlinではなくJavaで作っています。ｺﾄﾗｰが「Kotlin一択
Clean Architecture + DDD + Redux + RxJavaをAndroidでやるときにどこまで分割するか問題 - Augmented Usamimi
（追記） 本記事，頭のなかを整理しきれていない状況で書いたためよくわからないことになっていますが，Clean ArchitectureやRedux，DDDの優位な点を解説するような記事ではないことをご了承いただけると幸いです． 全体の構成がどうなっているか・モチベーション・pros・cons等については後日別記事にまとめようと考えています． いま書いているアプリがClean ArchitectureになりそこねたMVPと中途半端なDDDを組み合わせたようなアーキテクチャになっている． このアプリをある程度キチンとClean ArchitectureとDDDに寄せるにあたり，DDDのレイヤ分け（Data/Domain/Presentation）をどこまで厳格にやるかで悩んでいる． 現状 だいたいこんな感じ． Data/Domain/Presentationのすみ分けはしていない 実装上は意識
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Androidアプリ開発の体力づくり💪
