We were currently ignoring both deprecation and serial warnings. This
prevents warnings during the build, but hides useful information about
code that could/should be changed for all sorts of reasons.
In some instances of such warnings, the appropriate action is already
being taken (e.g. StorageUtils), so instead of ignoring all warnings, we
can just add a @SuppressWarnings("deprecation") in the appropriate
methods. Others scenarios will require more effort, like replacing
ProgressDialogs with something else. Let's re-enable the lint warnings
and work our way through them.
Closes: #3273
This allows the user to better search through an episode, by allowing
them to rewind less than what was just forwarded. It is also aligned
with how other apps out there behave.
Closes: #3262
Previously this method considered a date within the last 365 days to
be in the same year as today. Instead compare the actual years to
avoid confusion. Fixes#3255.
The `emptyViewHandler` already handles hiding and showing both the empty
view and the recycler view on data changes, so this commit removes this
part of the logic from the episodes fragment.
It also hides the empty view right after creating the recycle adapter
for the first time (when the fragment is created) to prevent the
progress bar and the empty view from being displayed at the same time.
`createRecycleAdapter()` signature was changed to make it explicit that
it depends on both the `recyclerView` and `emptyViewHandler`. Similarly,
`onFragmentLoaded()`, since it also depends on the new data that gets
loaded.
Unregistering from the EventDistributor on stop will prevent downloads
from updating when an episode finishes playing while the screen was off
(#2747), so this registers/unregisters on view create/destroy.
Disposing of the request to load items on stop could potentially cause
the same issue. Since we're disposing of this request on destroy,
there's no need to keep checking and disposing of it in the several
lifecycle methods.
There's no need to call `onFragmentLoaded()` on attach, since this is
the first lifecycle method to be called [[1]], meaning the items will
always be null by the time this method is called.
Finally, since `loadItems` depends on the view being created, it is now
only called on view create to avoid having to store state in the class
about whether the view has been created, taking advantage of the native
fragment lifecycle.
[1]: https://developer.android.com/guide/components/fragmentsCloses: #2747