Some questions and suggestions

[accountForIssues]

Hey, I just saw your project on F-droid and was happy to see an alternative to the NC's default dependency on FCM.

Am I correct to guess that you currently poll every few seconds to fetch notifications ? It would be nice to know the average battery consumption on a typical day.

How does your app deal with connection breakages;

• switching wifi/data
• on/off wifi/data
• random connection breaks
• server unreachable
• incorrect response from the server

I currently use this developed by @ASerbinski. It uses server side events instead of polling. It's a bit more advanced to setup but barely uses any battery (like <1% per day) and I receive notifications almost instantly with no delay.

Some suggestions:

• Request auth credentials from the NC app
• Be in sync with the notifications on the server.
  • meaning keep a list of arrived notifications and only delete them from the server when the user deletes it from the history on the device. Something similar to Gotify android app.

[0xf104a]

Hello Yes, the app polls every 3 seconds notifications(I am planning to do this parameter user-adjustable in future) Currently app handles all exceptions occured while polling, so it just logs all network failures as well as any bad responses. In next release(currently this changes are staged locally) there would be also implemented connectivity check which uses Android API and if there is no network connection available the service won't do any requests(so it will handle turned off wifi/data). As for battery usage: on my device it uses about 5-7%(not sure whether settings meant 5-7% relative to all other apps, or relative to fully charged battery), but I have unoptimized debug build installed, so in releases which are built by F-Droid battery usage should be less. Also, thank you very much for your suggestions. I would definetely implement them in future, but first of all I need to fix bugs :)

[0xf104a]

Features to implement:

• [x] Nextcloud SSO for authorization
• [x] Synchronization of notifications deleted on device to the server

[ASerbinski]

I tend to think that anybody who is likely to want to use this software will also definitely be using the main nextcloud application. That being the case, you should NOT be implementing anything with respect to Android accounts api, rather instead you should use Nextcloud's SSO and process everything using Nextcloud API, otherwise you are definitely doing things the hard way.

The way the authentication process works using SSO is such that on application launch, if an account has not been added to YOUR application already, it would call the Nextcloud SSO API, which would present a list of nextcloud accounts that have been configured on the device. User clicks the desired account, it prompts for confirmation, and you're done.

https://github.com/nextcloud/Android-SingleSignOn

[0xf104a]

Yes, I completely agree with you. But I thought that the SSO provided by Android itself(just haven't read the docs yet), so this why I wrote about Android API. Thank you for explanation, by the way :)

[sunjam]

I see nextcloud login preliminary support listed on beta 1.10 and cannot find how to test it yet

[0xf104a]

You need to get the latest beta(i.e. 1.0-beta10) installed. Since F-Droid build takes from 3 days to a week, you should take this apk from releases page. To install it you will need to delete previous version(since it is signed by F-Droid key, warning: this will reset all in-app settings) and then after installing 1.0-beta10 from apk file you can open the app and press "Log in via Nextcloud app" and app should show Nextcloud's account selection dialog.
NOTICE: You will also lose ability to update via F-Droid by the same reason: different signing key.
Another way to test without losing app prefeences and ability to update is using work profile(e.g. Shelter), so you can install Nextcloud Files and the latest beta in work profile and test it there

[sunjam]

F-Droid release of 1.10 beta is available as of today. Thank you.

[0xf104a]

All features which were requested in this issue were implemented as per 1.0-beta12, so I am closing this issue