Smooshes the recently updated and recently added lists into one,
and adds a status line under each app saying which of the two it
is (i.e. "Recnelty Updated" or "Whats New".
It doesn't load up the entire swap activity at this point. Instead it
is an entry point to direct the user to that activity.
Also added stubs for the remaining screens which need to be implemented
to the MainAdapter and MainController.
The fragment was quite straightforward to roll into the activity. Most
of the code moved across almost exactly as is.
Also added a theme for the toolbar so that in the future it will be
easier to support dark/night themes as well.
The following official Android support libraries were added:
* recyclerview-v7
* cardview-v7
* design
* support-vector-drawable
* constraint-layout
* palette
Also, add code to AppDetails2 to match AppDetails, keeping track of
currently viewed app. Moved the nulling of this info to onStop instead
of onPause, since alerts may be shown on top of the details page, while
still visible.
The `setApkInternal` method had to infer the intent of the caller
based on the arguments which were passed on, and then do specific
things depending on the input. Instead, this change has three
distinct actions which can happen (add/remove/update). Each of
these methods does only one thing, and doesn't have to guess
the intent of the caller. The only exception may be "add", which
will (for convenience) delegate to "update" if it already knows
about the apk in question.
The only time `status == null` was when coming from `removeApk()`. By
moving the logic out of `setApkInternal()` into `removeApk()` it makes
it easier to reason about `setApkInternal()` as it now does less. Also,
it was doubling up on the `syncrhonized (appMapping)` and `if (entry !=
null)` logic which is no longer required, because `removeApk()` was
already doing that.
While here, also make explicit the fact that `status` can no longer be
`null`.
Because of the way that this can be misused without the compiler knowing
(e.g. by forgetting to call `endBatchUpdates()`) it may be safer to move
it to an internal implementation detail of the class.
It could probably be done away with completely if the `notify*` methods
were moved out of the respective `*ApkInternal()` methods, but that
requires more significant refactoring to get right without code
duplication.
It seems that `setContentIntent()` will do fine if we pass it a null
argument. The default value is `null` anyway, and it doesn't mandate
a non-null argument.
Given that none of the callers need the functionality of the builder,
lets make it explicit that we don't expect the builder to be further
customized once it is returned. Instead, return a notification to hint
that no further customization is required/desired.
Given that some places where this method is invoked does a null check,
it seems reasonable to make this assumption explicit. That way if devs
use the method in the future, then they will be aware of the contract.
Neither pmd/checkstyle/many-devs are particularly precious about
hard rules of when to wrap a line. In this case we could've brought the
`ErrorDialogActivity` onto the same line as `putExtra`, but instead
opted to chain the method calls as per the `getAppDetailsIntent` method.
Whether a category is "available" or not is not a function of whether it
is in the category table or not. Rather, it is a function of whether there
are any active apps/apks which are in that category. Thus, don't notify
after inserting a category (the notification was wrong anyway as it was
trying to notify the AppProvider Uri instead of the ContentProvider one).
Instead, do it after a repo update is complete.
