A new way to be able to reliably record actual impressions of sponsored stories
was needed and based on this data we can ensure we are promoting fresh stories
(with fewer impressions) or the ones with a higher priority.
PocketStoriesChange was called only once - to clean the shown stories when the
user gets to the homescreen and the Pocket feature is disabled - useful for the
situations in which the user returns after disabling the feature in settings.
Populating the store with recommended stories to show was already happening
based on 'PocketStoriesCategoriesChange' and sponsored stories will be added by
using 'PocketSponsoredStoriesChange' so renaming 'PocketStoriesChange' will
help on reducing any confusion in the future.
Also added documentation for all Pocket related actions from AppStore and
removed the 'UndocumentedPublicClass' detekt suppressions.
The default was already 8. This is now being moved closer to the source from
where the stories to be shown are emitted.
With the addition of sponsored stories at fixed positions having to support a
variable number of stories being returned from AppState#getFilteredStories
means increased complexity with no benefit.
Whenever the ".crashed" property of the currently displayed
TabSessionState -> EngineState is true we will show an in-app crash reporter
with the usual close tab / restore tab options and also the option to report
all current non-fatal crashes to Mozilla if the setting for sending the crash
reports is enabled in app settings.
This closely mimics the previous crash reporter UI but there might be some
subtle differences stemming from migrating to using a ComposeView.
Whenever the ".crashed" property of the currently displayed
TabSessionState -> EngineState is false we will set the in-app crash reporter
to have a View.GONE visibility effectively removing it from the layout.
The functionality for receiving the non-fatal crashes from the AC CrashReporter
through an Intent is still kept and these crashes will be persisted in memory
until the user closes / restores a tab and so also makes a decision about
sending or not these crashes.
Currently more tabs can crash following just one since more share the same
process and as such there is no way to differentiate between them or link a
certain Crash to a certain tab.
They will all be acted upon at once from any tab the user chooses to close or
restore.
Arturo Mejia
Mugurell
mike a
MatthewTighe
Jonathan Almeida
Gabriel Luong
Jonathan Almeida