Google, Play Store にて Allo と Duo を事前登録受付中!!

メッセージングアプリで巻き返しを図っているようです.

Official Google Blog: Saying 👋 to Allo and Duo: new apps for smart messaging and video calling

Google_Allo_-_Google_Play_の_Android_アプリ

Google_Duo_-_Google_Play_の_Android_アプリ

Allo はメッセージングアプリ.

Duo は動画チャットアプリ.

先手必勝のここらでいまさらユーザをキャッチできるのかしら.


Google発リアクティブなライブラリ「Agera」の評判を眺める

google_agera__Reactive_Programming_for_Android

Agera (Swedish for “to act”) is a super lightweight Android library that helps prepare data for consumption by the Android application components (such as Activities), or objects therein (such as Views), that have life-cycles in one form or another. It introduces a flavor of functional reactive programming, facilitates clear separation of the when, where and what factors of a data processing flow, and enables describing such a complex and asynchronous flow with a single expression, in near natural language.

Home · google/agera Wiki

どんなものなのか良く知らないので掲示板で評判を眺めて雰囲気を確認する.

REDDIT: AGERA - Reactive Programming for Android by Google : androiddev

どんな特徴なのか?

I'm a little surprised they don't mention RxJava at all. At first glance this looks like they wanted to create a simplified version of RxJava. It really doesn't seem to be that Android specific, except for the extensions.

(公式ドキュメントで) RxJavaについて全く言及していないのはのには少し驚きました. 一見, RxJavaの簡易版を作りたかったように見えます. また, エクステンションを除けば, Android に特化しているようにはみえないです.

The library is not very Android-specific tho, and it suffers from the same pitfalls loaders and other Google patterns/libs do: no rotation, poor unsubscribe logic.

まったく Androidに特化していません. Loaderや他のGoogleパターンやライブラリのように同じ落とし穴に悩まされる. ローテション不可, 貧弱な unsubscribe ロジック.

なぜつくったのか

I'd love to hear why they went with an in-house reactive library. A nice long blog post would be great.
Performance? Memory overhead? Android-OS specific concerns?

なぜ自社内でリアクティブライブラリを作成したのか聞きたいです. 素敵な長いブログは素晴らしいです. パフォーマンス? メモリーオーバーヘッド? Androiid OSに特化した何か?

Most likely because Google has a strong internal policy to avoid depending on external libraries, so they were probably forced to develop their own. Obviously, that doesn't make for a very good excuse, so they avoid the whole topic completely and don't even mention Rx a single time in their docs.

なぜなら Googleは外部ライブラリに依存しないという強力な内部ポリシーを持っている. それで, 多分開発を強いられたのでしょう. 明らかに, それは良い理由ではありません. それで, すべての話を完全に避けて, ドキュメント内で一回も言及していません.

I'm not a Googler, but I know of no such policy.
I do know (through decompilation) that applications such as Gmail were using Dagger 1.x as far back as 2-3 years ago. In addition, the Android platform uses many external dependencies, including sqlite and okhttp. So I'm curious where you get this information.

私はGoogleの者ではないが, そのようなポリシーはないと思います.
Gmail は2,3年前 Dagger1.x を利用していたことを (デコンパイルにより) 知っています.
加えて, Androidプラットフォームはsqliteやokhttpを含むたくさんの外部依存を用いています. どこでその情報を仕入れたのか興味がありますね.

The open source licenses are listed in their apps if the open source library requires it. I don't see Dagger listed in the Gmail app but I see it in Inbox, along with a whole slew of open source licenses.

もし, オープンソースライブラリを必要としているなら, オープンソースライセンスがそれらアプリに列挙されます. Dagger は Gmail アプリで列挙されているのをみたことないが, Inbox ではみました. たくさんのオープンソースライセンスの中にありました.

I'm guessing they built this before RxJava was available or widely used and are just now releasing it as open source.

私は, RxJavaが利用可能となり広く利用される前にこれは作成されたものと推測しています. そして, 今回オープンソースとして公開されただけだと.

Googleの人登場!

We don't compare Agera with RxJava because it's not meant to be a replacement for it nor it's our opinion that it should be replaced.

Reactive programming has many flavors and Agera proposes one that we know works well for Android. It was developed internally as part of Google Play Movies and we like to open source code whenever possible.

Question: what's the relation to RxJava? · Issue #20 · google/agera

我々は, Agera と RxJava を比較していません. なぜなら, それに代わるものを意味しているものでもなく, 置き換えるものであるという意見でもありません.

リアクティブプログラミングには多くのフレーバーがあり, Agera はAndroid上で問題なく動くもののひとつとして提案しています. Google Play ムービーの一部として内部で開発されたもので, 我々は, 可能な限りソースコードを公開したい.

今後どうなるのか?

Reading between the lines in some of the answers it seems like they wanted something Android specific.

コメントを読んでいると, Androidに特化した何かを欲しがっているね.

My major concern would be that this was written for Google Play Movies as mentioned in GitHub issue linked above. So it doesn't seem like a first class project at Google so the odds of it being actively maintained seem slim.

上の GitHubリンクで言及されているように. 一番の注目点はGooglePlayMoviesのために書かれたということでしょう. それは, Googleの重要なプロジェクトではないように見えるのでメンテナンスのアクティビィティが細っていく可能性がある.

RxJava から乗り換えたほうがいいのか

Unless there's some major advantage I'd say it's better to stick to the RxJava or RxAndroid from Wharton. I don't want to learn another api for something is already so popular.

大きな利点がないならば, Wharton の RxJava や RxAndroid にとどまったほうが良いといいたい. すでに学んだ有名なものに対して別のAPIを学びたくない.

RxJava, definitely. It's widely used, it's got great maintainers, it isn't Java/Andorid specific, the same pattern is used in a lot of languages.

絶対に RxJava がよいです. 広く使われており, すばらしいメンテナーたちがいます. Java-Android に特化されているわけでなく, たくさんの言語で同じパターンが使われています.

As a person still learning about reactive programming, should I stick with learning RxJava/RxAndroid or give AGERA a try?

リアクティブプログラミングを学んでいるものとして, RxJava/RxAndroid を引き続き勉強するべきか,または, AGERAを試してみるべきか?

If you are new, stick to Rx for now. Have a good grasp on it first. Mastering other reactive tech should be approximating and mapping similar logic from one to another. Those are opinionated APIs, but principles are setup. It is still early to make such claims but reactive knowledge should transfer between language/tech as well as polymorphism does today.

もしあなたが新人であれば, 今は Rx にどどまるべきです. まずそれをしっかり理解しなさい. 他のリアクティブ技術は 似たロジックで構成されています. APIは違うけれども原則は同じです. そのような意見ははまだ早すぎで, 今で言うポリフォーイズムと同じようにリアクティブの知識を持ってから言語や技術間を移動すべきです.

Sticking with RX would give you benefits are:
1. Multi language support. Migrating logic should be a breeze.
2. Great support on the maintainers side.
3. Any company that uses it will want to hire you more.
4. Syntax looks similar enough to other tech like streaming APIs of Java 9.

Rx のメリット:
1. 複数の言語サポート. ロジックの移行が簡単.
2. メンテナー側からの素晴らしいサポート.
3. それを使用するすべての企業はより多くのあなたを雇うことになるでしょう。
4. Java9の ストリーミングAPIのような他の技術に文法がかなり似ている.

今のところは

「乗り換えなくてもいいけど, 試してみる」くらいが妥当なところなのかな.


苦労した経験から学んだ Androidアプリを作る際の30のこと

Building Android Apps — 30 things that experience made me learn the hard way — Medium

読んでみましたが, 納得できることばかりです.

一読の価値はあると思います.

実際は, 35個ありました.

1. サード・パーティのライブラリを追加する前に2度考えよう. それは本当に重要な決意なのです.

2. ユーザーがそれを見ることができないならば, 描画してはならない.

見えないところは塗りつぶすな – 不要なオーバードロー削除で高速化

3. 本当に必要でなければデータベースは使うな.

4. メソッド数 65000個はすぐに到達するが MultiDex が助けてくれる.

[DEX] Sky’s the limit? No, 65K methods is — Medium

5. AsyncTask のベストな代替は RxJava でこれのほうがかなりよい.

Party tricks with RxJava, RxAndroid & Retrolambda — The Startup — Medium

6. Retrofit がベストなネットワークライブラリである.

Retrofit

7. Retrolambda でコードを短縮しよう.

Retrolambda on Android — Android & Tech — Medium

8. RxJava と Retrofit と Retrolambda を一緒につかうと最強.

Party tricks with RxJava, RxAndroid & Retrolambda — The Startup — Medium

9. EventBus は素晴らしいが, コードが乱雑になるので多用するのは控えている.

greenrobot/EventBus: Android optimized event bus that simplifies communication between Activities, Fragments, Threads, Services, etc. Less code, better quality.

10. レイヤーでなく機能によって構成する.

ソースディレクトリの構成時にもっておくべき「会社別」のイメージ

11. アプリケーションスレッドのすべてをOFFにしろ.

12. レイアウトとそのヒエラルヒーを最適化するために lint するべし. 削除できる不要なレイアウトを特定できる.

layoutopt | Android Developers

13. Gradle を使っているなら, いろんな方法でスピードアップしよう.

Android お手軽なビルド時間の短縮メモ

14. ビルド時には プロファイルレポートを使え, それぞれのビルドにかかった時間が分かる.

オプションに「–profile」をつけて Run時間が1分から2秒になった話

15. 有名なアーキテクチャーを使え.

Architecting Android…The evolution – Fernando Cejas

16. テストは時間がかかるが, 一度コツを掴むとテストしないときより高速で堅牢となる.

Is Unit Testing worth the effort? - Stack Overflow

17. Dependency Injection を使え. よりモジュール化されテストしやすくなる.

Tasting Dagger 2 on Android – Fernando Cejas

18. Fragmented の podcast を聞け. きっとあなたにとって素晴らしいものとなる.

Fragmented_–_An_Android_Developer_Podcast

Fragmented – An Android Developer Podcast

19. 個人的メールアドレスは Android Market の公開アカウントに使うな.

Google Play - Only one strike is needed to ruin you : Android

20. 常に適切な入力タイプを使え.

Specifying the Input Method Type | Android Developers

21. (Google) Analytics を使って利用パターンを見つけバグを隔離すべし.

22. 新しいライブラリの人気のあるやつを使え. (dryrun を使って出力をより速く)

【AndroidStudio 不要】サンプルアプリは「dryrun」で試してすぐ捨てよう

cesarferreira/dryrun: Try the demo project of any Android Library

23. Service はできるだけ素早く処理して終了しろ.

24. ユーザ名やメールアドレスのサジェストにアカウントマネージャーを使え.

AccountManager | Android Developers

25. ビルドやベータ版の配布や apk の作成にはCIを使え.

26. 自分の CIサーバは使うな. サーバーのメンテに時間を使う. ディスク容量・セキュリテイの問題・SSL攻撃防御のサーバの更新なども. Circle CI や travis, shippabele を使え. これらは 安価で手間も少ない.

27. PlayStore へのデプロイは自動化しよう.

Triple-T/gradle-play-publisher: Gradle Plugin to upload your APK and metadata to the Google Play Store

28. ライブラリが巨大でその一部しか使ってない場合は, より小さくなる方法を探せ(例えば プロガードを利用する)

Shrink Your Code and Resources | Android Developers

29. 実際に必要以上なモジュールを使うな. もしそのモジュールを頻繁に更新していないのなら, コードからそれらをコンパイルする時間や, 以前のそれぞれのモジュールのビルドが最新版であるかチェックも必要となることについて考えることが重要です. バイナリ .jar/.aar の簡単な読込みにすると4倍くらい向上できます.

30. PNGを捨ててSVG化することを考え始めよう.

Vector Asset Studio | Android Developers

31. ライブラリの抽象化クラスを作れ. ライブラリを変更するときに一箇所の変更で簡単に行うことができる.

JakeWharton/timber: A logger with a small, extensible API which provides utility on top of Android's normal Log class.

32. Connectivity とその種類を監視しろ. (WiFi のときにより多くのデータを更新しているか?)

33. 電源とバッテリーを監視しろ. (充電中に更新データを多くしているか, バッテリーが少ないときには更新を停止しているか?)

34. UIとはジョークのようなものだ. 説明が必要であればそれは良くない.

35. テストのパフォーマンスは偉大です. テストで何も壊れないか確認し、その後ゆっくりと正しい実装を記述する → 最適化

Dan LewさんはTwitterを使っています: "Tests are great for performance: Write slow (but correct) implementation then verify optimizations don't break anything with tests."

しかし, Medium ていい記事ばかりあるけどなぜなのかな.