Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(#600) Notification system for settings (for crash logs and apk updates) #656

Merged
merged 15 commits into from Mar 9, 2020

Conversation

K1rakishou
Copy link

@K1rakishou K1rakishou commented Feb 15, 2020

Closes #600

Not ready yet.

So, basically, instead of spamming AlertDialogs on every important update (like new apk update or new crash log that awaits to be either uploaded or not) there is now a more user-friendly system which does not nag the user with any windows whatsoever. Instead, a small alert icon is being shown in specific setting option (and in the drawer too) so the user sees it every time he opens the drawer or the settings. Once the conditions for this icon are all satisfied it disappears (like all crash logs are either uploaded or deleted). If there are multiple notifications (say apk update and couple crash logs) then a notification with highest priority is shown in the drawer (once it's cleared the other one replaces it, etc).

It's pretty easy to add new notifications, too.

Oh yeah, you can now also review crash logs and decide which you upload and which not (you can even delete them all). No crash logs are now being uploaded automatically.

- Implement SettingsNotificationManager to accumulate update events and distribute them to observers.
- Implement displaying of the notifications in the settings' views.
@K1rakishou K1rakishou changed the title WIP: (#600) Notification system for settings (for crash logs and apk updates) (#600) Notification system for settings (for crash logs and apk updates) Feb 16, 2020
@K1rakishou
Copy link
Author

Alright, now it's ready.

@K1rakishou
Copy link
Author

I had to change a couple of things in UpdateManager so you better review it more carefully.

…ystem-for-settings

# Conflicts:
#	Kuroba/app/src/main/java/com/github/adamantcheese/chan/core/manager/UpdateManager.java
…ystem-for-settings

# Conflicts:
#	Kuroba/app/src/main/java/com/github/adamantcheese/chan/Chan.java
#	Kuroba/app/src/main/java/com/github/adamantcheese/chan/core/manager/UpdateManager.java
#	Kuroba/app/src/main/java/com/github/adamantcheese/chan/core/settings/ChanSettings.java
#	Kuroba/app/src/main/res/values/strings.xml
return false;
}

private void notifyNewApkUpdate() {
ChanSettings.hasNewApkUpdate.set(true);
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a setting. This is a persistable app state. I think I should extract it into a separate class that uses it's own shared preferences file.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You probably won't need a setting at all since the update API is run on every startup.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But it only checks for the new apk only once in 24h, or is it not?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It checks for a new APK only when the app is started cold, with a minimum delay of 24h for dev and 5 days for stable. There's no scheduled task to check for an update, just like how it was in Clover.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well that's why I needed "hasNewApkUpdate" flag. Because if we start the app during the 24h or 5d window when we do not check for the updates, and there were actually an update the last time we checked it, the notification won't show up.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's still fine to keep it in ChanSettings anyways, there's a bunch of things in there that aren't strictly settings.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well those will have to be moved too. But we can do that later. Or I could move them.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please just keep it to one thing per PR if possible, these super huge PRs with all sorts of barely related stuff in them makes it difficult to review.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright then I will just move this one setting to a new class.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@K1rakishou
Copy link
Author

K1rakishou commented Feb 25, 2020

I should also only upload crashes that are not older than, let's say, 3 days (and delete older crashes) to avoid endless spam. Also should check and handle http codes 429 (when client attempted to send way too many crash logs) and 500.

Already done in another PR and already merged.

…ystem-for-settings

# Conflicts:
#	Kuroba/app/src/main/java/com/github/adamantcheese/chan/Chan.java
#	Kuroba/app/src/main/java/com/github/adamantcheese/chan/ui/controller/settings/DeveloperSettingsController.java
…ystem-for-settings

# Conflicts:
#	Kuroba/app/src/main/res/values/strings.xml
…ystem-for-settings

# Conflicts:
#	Kuroba/app/src/main/java/com/github/adamantcheese/chan/ui/layout/ReportProblemLayout.kt
@Adamantcheese Adamantcheese merged commit 4eb2a13 into multi-feature Mar 9, 2020
@K1rakishou K1rakishou deleted the (#600)-notification-system-for-settings branch March 9, 2020 06:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[IMPROVEMENT] Make automatic crash reporting not as sneaky as it is right now
2 participants