gen0083 / filteredhatebu Goto Github PK

そもそもRxJava使っていたのは、スレッド処理の切り替えが目的だったと思う
(当時のことをよく覚えていないので、それだけではなかったかもしれないが)

RxJavaを使っていながらtoBlocking()でリストにして処理をしている箇所がある
例えばCrawlFeedsWork
https://github.com/gen0083/FilteredHatebu/blob/develop/app/src/main/java/jp/gcreate/product/filteredhatebu/domain/CrawlFeedsWork.kt

toBlockingを使っているということは、単にスレッド処理のためだけにRxJavaを使っていると思われる
それならCoroutineに置き換えてしまった方が適切ではないだろうか

• Retrofictのcoroutineサポートを導入
• apiパッケージの戻り値書き換え
• CrawlFeedsWorkなどのコードを書き換える

というタスクがある。

現在のMockデータはかなり適当
各記事で考えられるパターンを用意して、想定通りの動作をするか確認できるようにしたい

記事の取得日による分類

• 当日の記事
• 取得から1日たった記事
• 取得から1週間たった記事
• 取得から10日間たった記事
• 取得から2周間たった記事
• 取得から1ヶ月たった記事

それぞれの記事は以下のパターンがある

• 未読の記事
• アーカイブした記事
• お気に入りにした記事
• お気に入りにしてアーカイブした記事

フィルタを考えるとさらに記事パターンが増える

• フィルタされていない記事
• フィルタされた記事

アプリ初回起動時にダイアログを表示して協力を願い出る
設定画面でCrashlyticsのクラッシュレポートの有効・向こうを切り替えできるようにする

現在はCrashlyticsをインストールしているけれど、自動収集を無効化してる
・・・はずなんだけど、そういえばテストクラッシュがFirebaseに上がってたような気がするな？

入り口がActivityなんだけど主体がFragmentみたいな感じなのが話をこじらせている気がする。

FragmentごとにPresenterを持たせておきたいのだけど、FragmentごとにPresenterをもたせることは難しい。
というのも、このFragmentはsetArgumentで渡すカテゴリキーによって挙動が異なる。
これをFragmentのインスタンスで識別することはできないので、ActivityPresenterにFragmentのPresenterを持たせている。
するとActivityPresenterがFragmentの数だけFragmentPresenterを持っている状態になる。
この時点ですでにややこしい。
FragmentPresenterをFragmentが取得するには、自身に設定されたカテゴリキーを元にActivityにアクセス、ActivityからPresenterの参照を取ってActivityPresenterからFragmentPresenterを取得するというプロセスを経る。
遠回りし過ぎではないかと思う。
現状の設計では、変にこんがらがっていて正直なところ触りたくなくなってきている。

現在、BottomSheetがEXPANDEDのときはまずBottomSheetをたたむように動いている

コメントが画面いっぱいに広がっているときはあった方がいいと思ってつけている。

しかし、BottomSheetが画面を覆うほどではない場合（コメントが数件しかなくて広げても画面半分くらいにしかならない場合）や、そもそもコメントがない場合にはBottomSheetの状態に関わらず前の画面に戻って欲しい。

今は固定でトピック拾っている
興味のないものが延々並んでしまうので、カスタマイズできるようにする

前のアイテムで読み込み→スクロールで次のアイテムになったあとで前のurlのfaviconがセットされてしまうと思われる

ViewPagerで表示しているので、現在表示中のFragmentだけでなく、次のFragmentも生成されている。
そのため記事の読み込み処理が走り、その結果新着記事があった・なかったといった通知が画面に表示されてしまう。
現在表示中のFragmentに関する通知のみを表示するようにしたい。

なんか思ってるのと違う。
アイテムの削除メッセージが表示されるのを待ってから、前に削除したやつをremoveするようにしたい

やってること

whatsnewの更新
versionCode, versionNameの更新
./gradlew assembleProdRelease
./gradlew publishProdRelease

Google Playへの公開自体はgradleコマンドでできるが、その前段階のversionCode上げたりする部分も自動化したい（手動で書き換えはめんどうくさいし、よく忘れる）

アプリアイコンをAdaptive Iconにする

https://developer.android.com/topic/libraries/architecture/workmanager/how-to/testing

依存関係として入れているので、せっかくなのでWorkManagerのテストを書く
フィルタされている記事の一覧を消すWorkManagerがきちんと動作するかの確認テストが特にほしい

コメントを読み込むタイミングは、記事詳細を表示したタイミングのみになっている
コメントを再読込するには画面遷移が必要
更新する機能をつけてもいいと思う

アプリ内では時刻をUTCで扱っていて、表示に関してもそのままUTCが使われている

記事一覧は記事を取得した日付でStickyHeaderを表示しているが、これがUTCとの時差分ずれる
例えば7月29日1時に取得した記事は7月28日の7月28日の記事扱いされる
7月29日の9時以降に取得した記事が29日のヘッダーに属する記事と扱われる

#10 とりあえずPicasoを使わない形で回避したが、気持ち悪いので原因を調べる

WorkManagerを使って記事を取得しているが、これを定期的にバックグランドで実行する機能を追加する

• Workのスケジューリング
• 通知の追加

フィルタに引っかかってるフィードが削除されていない
確認したところFeedDataDaoで削除に使ってるクエリが悪い
アーカイブされてるかとかでも削除対象を絞り込んでいる
たぶんアーカイブされてるかの条件付を除いたクエリに書き換えてやれば、ちゃんとフィルタ済みのフィードも消えてくれるんじゃないかと思う

adapterの参照してitem数が0でなくなるまで待つようにしているが、これだと記事数が0の場合に対応できない

Loading表示がなくなるまで待つように切り替える
#1 の実装が終わったらやる

Circle CIでビルドできない
play-publisher-pluginの影響か、prodReleaseが解決できずにCIの処理がかなり初期段階で止まっている
リリース用の設定はCIでは読み込まれないようになっているのが原因だと思う

コメント非表示設定されているサイトだとアプリが落ちる？

例
http://www.dangouwasa.com/entry/supermariorun

ViewPagerでカテゴリごとに分けているが、見るときにいちいちカテゴリを移動するのが面倒くさい。
またカテゴリ間で重複している記事がある場合もあり、ViewPagerでカテゴリごとに表示するより、1つのページでまとめて表示できた方が便利だと思う

1. 未読の記事とアーカイブの記事の表示を切り替える(現在のやり方、動かないけど)
2. 未読の記事一覧とアーカイブした記事一覧を別ページに分ける

どちらかで実装すればいいかな。

現段階では10日でハードコードしてる

feeds arw not updated until app truely finished in v16.10.1.

現在は単純にフィードを表示しているだけ

未読記事、既読記事、フィルタした記事と表示する記事を分けて管理するようにしたい。

テスト用の依存があったのでとりあえず入れてるけど、どうやってテストを書くのか

記事一覧 -> 詳細 -> BottmNavigationから別タブに移動（例えば設定） -> バックボタン -> 記事一覧に戻る -> 詳細へ移動しようとするとクラッシュ

java.lang.IllegalArgumentException: navigation destination XXX is unknown to this NavController

https://stackoverflow.com/questions/51060762/java-lang-illegalargumentexception-navigation-destination-xxx-is-unknown-to-thi

いままで使っていたからRxJava継続して入れてる状態だが、このアプリはRxJava本当に必要なのか微妙なところ
これといってイベント(stream)を扱う必要性のある箇所はない気がするが要確認

少なくともRxJava1系の依存は消す
1系は絶対にいらない、2系に置き換えればいい

2系に置き換えた上で、それでも必要なさそうならRxJava自体への依存を消す

なんかスマホから通知がぽこぽこ連続で聞こえて、なんだよこれって思うことがあるんだが、その際に通知欄見ても対して通知が残ってない。
ただFilteredHatebuの通知は出ているので、もしかしてムダに通知を出しているか、ムダにクロールの作業が動いているかしていないだろうか。
そのあたりを確認する。

leakcanaryが2系になってるので、バージョンアップする

https://github.com/square/leakcanary
https://proandroiddev.com/detecting-memory-leaks-in-your-instrumentation-tests-using-leakcanary-1268e911d5ce

Presenterは非同期で処理を行う
今の作りでは処理を行っている最中にViewがアタッチされているとは限らない
すると例えば、新着記事の確認を行って新着記事があった場合、Viewがアタッチされていれば「新着記事がありました」のメッセージとともに最上部にスクロールされるが、そのイベントを通知するタイミングでViewがアタッチされていなかったら、スクロール位置は前に表示していたときのままだし、新着記事があったのかどうかがユーザにわからないことになる
（Viewがアタッチされたときに最新記事に切り替わるので、データが更新されないわけではない）

とりあえず今思いつく対策は2つ

PresenterにViewへイベントを通知したかどうかを判定させる

Pros

• Presenterにコードを加えるだけで良い

Cons

• PresenterにViewへの通知を状態として持たせるのは美しくない（というか、せっかくViewへの依存をなくしたはずのPresenterが、Viewへの依存を持ってしまうのでよくないと思う）
• Presenterのコードが複雑になる

BehaviorSubjectを使って通知イベントをキャッシュさせ、それをViewがsubscribeして処理するようにする

Pros

• Presenterは発生したイベントを粛々と流すだけで済むのでよい
• PresenterはViewへの参照を持つ必要がなくなる（onAttach, onDetachが不要になる）

Cons

• 具体的にどうすればいいのかあやふや
• Viewはそのイベントをどう購読してどう処理するのかという部分を考えないといけない(コマンドパターンを使う？)

Actionに発行された時間を持たせておけば、同じイベントが二重に処理されることを阻止できると思う（例えば画面を回転する度に「新着記事がありました」と一番上に戻ってしまう事態を避けれる）

http://qiita.com/hkusu/items/64a9435e1613e4c20ba7
この記事がヒントになりそうな気がする

mockビルドの場合のみかもしれない

モックで返す画像ファイルのデコードがうまくいっていないだけかもしれない