MVVMアーキテクチャにおいて、一つのModelを複数のView Modelで共有している場合、あるイベントを複数のView Modelで同時に受け取りたいことがある。これをKotlin Coroutine Flowを使って書くとどうなるのかなぁと思ったのでやってみたメモ。テストも書いた。 前回のエントリでPaging Library 3の内部実装を読んだ際に同じようなことをやっているようなコード があったので参考にした。 muumuutech.hatenablog.com 実装例 例として「requestがあったらremote source (api serverとか)から何か値を取ってきてflowにemitする」ようなservice classを実装する。コード例はこちらのgistにまとめてある。 Example of Kotlin Coroutine Flow with multip

コロナ禍で在宅勤務が一気に広まり、自宅でアプリの開発やリリースをすることが多くなりました。この状況のなかで、アプリの挙動に問題があるなどで動作確認をしようと思うとき、その問題に対処するためのデータを集めたり、問題が発生したときの状況を確認するための手立てを持っておく必要があります。この記事では、手元にない端末で起きる問題のトラブルシューティングをしやすくするために準備しておくとよいことを書き残しておこうと思います。 端末のログを収集する ある端末でアプリがクラッシュしたときに、そのスタックトレースを記録しておくことはとても重要ですが、そのクラッシュにいたるまでに何があったかをログとして収集しておくことで、クラッシュが起きた状況を把握しやすくなります。 Firebase Crashlytics や DeployGate など、端末からログを収集して Web コンソール上で閲覧できるようにして

EasterEgg Neko Atsume LauncherのAPKサイズを極限まで小さくすることに取り組んだ成果を適当に書いておく。 EasterEgg Neko Atsume Launcherがそもそもなんだ？？って話だろうけど、以下とか読めばOK。 hack-it-iron.hatenablog.com play.google.com どのようにAPKのサイズを小さくしたか コードはGithub上に公開してある。読むほどの価値はない...🐱 具体的にAPKサイズのチューニングを行ったPull Requestは以下の２つ。 github.com github.com 不要なリソースファイルを削除する EasterEgg Neko Atsume Launcherはアプリの性質上、ほとんどリソースを必要としない。 R.javaさえ消し去りたいくらいだ。 styles.xmlはいらないね。

先日、Kotlin や IntelliJ Plugin をテーマにもくもく会を開催しました。 会場: 株式会社サムライズムさん イベントページ: http://connpass.com/event/27791/ もくもく会の様子 当日は、簡単な自己紹介をした後、1名飛び込みで LT をしていただいたりしました。 その後、Kotlin グループと Plugin グループとで何となく分かれ、開発を始めたのですが、 飲み物とピザをサムライズム山本さんが用意して下さってので、飲んだり食べたりしながら楽しくもくもく出来ました！ ちょっと写真が無くて申し訳ないのですが、サムライズムさんはプロジェクターやマイク、電源、WiFiと何でも揃っているので最高でした。 僕は Plugin グループでもくもくしてたのですが、意見交換とかも出来て楽しかったです。 Kotlin グループも Kotlin エヴァンジェ

NavigationView と Fragment と BackStack: DroidKaigi 公式アプリの構造と設計・実装の判断の足跡を辿るJavaAndroidFragment 概要 DroidKaigi 公式アプリ誕生のお話は @konifar さんのブログ記事 を御覧ください。 この記事では、DroidKaigi 公式アプリの中でも、自分がプルリクエストを出した、NavigationView の操作とそれに連なる部分の構造について解説します。 NavigationView のイベントハンドリング NavigationView に表示するメニューの各項目は、従来の OptionsMenu などと同じMenuItemです。そのMenuItemが選択されたタイミングのイベントを拾うコールバックとして、NavigationView.OnNavigationItemSelectedLis

短い答え OrmaはRobolectric上でほぼ完全に動作するので、 OrmaDatabase.builder(context).name(null).build() でオンメモリDBを作ってそれを使うDAOをテストすればよい。 長い答え Orma を使ったユニットテストは、Ormaを使うコードが正しいかどうかをテストするものであるべきです。たとえば、konifar/droidkaigi2016ではSessionDaoというクラスをつくり、Session / Speaker / Category / PlaceなどのデータをSessionというクラスを中心に操作するためのDAO: Data Access Object としています。複雑なモデルの関係があるときは、このようにDAOを作って操作するというのはいいパターンです。 このとき、DAOはロジックを含んでおり、そのロジックはテストが必

Androidエンジニアの@operandoOSです。 最近、JSONArrayのremoveメソッドがAPI Level 19以上でしか使えない現実に落胆しております。 http://developer.android.com/intl/ja/reference/org/json/JSONArray.html#remove(int) 先日、メルカリオフィスにて shinobu.apk #1を開催しました！ shinobu-apk.connpass.com そもそも shinobu.apkってなんぞ？？ shinobu.apkは、Shinobu Okano(この記事書いてる本人)と愉快な仲間たちが繰り広げるファンタジーな勉強会です。 shibuya.apkという、渋谷を中心に活動するAndroidアプリ開発者コミュニティの名前をtypoしたことによって生まれたものです。 真面目に言うと、有

DroidKaigi 2016がいよいよ来週開催されます。 ふとした思いつきでDroidKaigiのカンファレンスアプリを作ったところ公式アプリとしてリリースさせていただくことになり、今現在完全オープンソースで色んな人がコミットしてくれています。スピード感あってなかなか面白いので、忘れないうちに経緯をまとめておこうと思います。 github.com アプリは現在こんな感じです。デモとしてアラビア語表示にも対応しています。 1/11（月） DroidKaigiの発表準備しないとまずいと焦り始めました。 最近は発表の内容に合わせてサンプルアプリを作って公開するようにしているんですが、ただのサンプルコードだと飽きちゃうので何を作ろうかなぁと考え始めました。 そこで思いついたのが、DroidKaigiのカンファレンスアプリでした。みんなが使えるアプリなら懇親会の時の話のネタにもなるし、ぼっちにもな

11/17に六本木界隈のAndroidエンジニア勉強会である Roppongi.aarを開催しました。第2回は株式会社メルカリで開催されました。参加者は36名で、8人の発表がありました。 クラフトビール好きにはたまらないAndroid勉強会@メルカリ #roppongi_aar pic.twitter.com/qVnhM8ebGf— ふじたくま (@magie_pooh) 2015, 11月 17 第一回と違って会場が広くてBGMもある #Roppongi_aar— こむ (@petitviolet) 2015, 11月 17 今回新しい試みとして、プレゼンを英語推奨としたのですが、その経緯や振り返りについて書きたいと思います。 新しい試みの経緯 今回勉強会を開催するにあたり、これまでと異なることをやってみようと思いました。理由としては、 Shibuya.apk, Kyobashi.dex

モバイルアプリの知見共有会であるpotatotipsに初めてブログまとめ枠で参加してきました。 connpass.com potatotipsはビックリするくらい人気になっていて、一般枠の倍率が4〜5倍、発表枠でも抽選に漏れてしまうこともしばしば。ですが実はブログまとめ枠はなぜかいつも空きが出るくらいスカスカで、ちょろっと申し込んだら普通に通りました。 ブログまとめ枠は5人もいるみたいですし、資料はいつものGitHubリポジトリに上がると思うので、Androidの発表を聞いて自分が考えたことをメインにざっくりまとめたいと思います。 CIと実行時間 @tomoaki_imaiさんによる、メルカリでやっているCIに関する知見の共有でした。 Tips for better CI on Android from Tomoaki Imai www.slideshare.net 最近はCIツールが充実

By Android Developers Blog スクラムエンジニアリンググループの片渕です。 Google I/O 2015でAndroid M Developer Preview(Marshmallow)が発表されてから数ヶ月が経ちました。 新型のNexus5が発表されるという情報もあり、Marshmallowがユーザーの手に届く日は遠くなさそうです。 開発者としては、新機能にワクワクする一方でアプリが不具合を出したりクラッシュしないかというのが最も気にかかる所だと思います。 という事で今回は、私が担当しているアプリをMarshmallowで動作確認した際の知見を共有できればと思います。 新OSへの対応というのは通常、deprecatedになったAPIを消したり新規に追加されたAPIを呼ぶ様に修正するというのが正規のアプローチですが、現実問題としてプロダクトの状況によってはそこまで

先日Debotという名前のライブラリをリリースし、勉強会で発表したりしたのですが、主に英語で書いたりしていたので、ブログにも書こうと思います。 デバッグ用ライブラリとしての特徴 youtu.be Debotはアプリのツールバーにデバッグメニューを簡単に追加できるライブラリです。標準でデバッグ機能として以下がついています。 Activity名、Intent情報を表示する 画面密度を表示する アプリ情報(VersionCode,VersionName等)を表示する 自動入力機能(特定のTextViewに指定した文字を入れる) また、カスタムプラグインで自分が必要なデバッグ機能を容易に追加することができます。 @DebotAnnotationアノテーションをつけたメソッドはDebotから呼び出すことができます。つまりメニューからActivity内の特定の処理を実行することができます。つまり、 デ

早くも発売が待ち遠しいAndroid Wearの端末ですが、端末を買ってから環境を整えていたら開発者として楽しめません。 エミュレータを使って開発ができるので環境構築手順を紹介します。 現時点では色々制限があり、Kitkatが搭載された実機と組み合わせないとエミュレータを使った開発ができないのでご注意ください。 4.4.2以降のAVDを使ってゴニョゴニョしてエミュレータを2個立ち上げれば何とかできそうな気はしますがここでは紹介しません。 おおまかな流れ Android Wear Developer Previewに登録 テスト用のアプリを実機にインストール Android SDKの環境を整える Wearのエミュレータと実機を接続 Android Wear Developer Previewに登録 Get Started with the Developer Previewに移動し、 のボタ