📲 Unifiedpush

[koo5]

This PR adds a new build variant: "unifiedpush".

• uses https://unifiedpush.org/developers/android/

• works with Gotify-UP - with a yet-unreleased push server

problems:

• [ ] does not work with UP-NextPush yet... (Up-Example does not work with it either)
• [ ] currently does not work when there are multiple distributors available - we think this is because UnifiedPush.registerAppWithDialog expects to be called from an activity..
• [ ] another design issue is that unifiedpush.ChatAndCallMessagingService is largely a copy of firebase.ChatAndCallMessagingService - not sure where to create a common ancestor.
• [ ] "ClosedInterface" was a strange name to begin with...

feedback, ideas and corrections appreciated!

[nextcloud-android-bot]

Lint

Type	master	PR
Warnings	116	117
Errors	1	1

SpotBugs (new)

Warning Type	Number
Bad practice Warnings	8
Correctness Warnings	35
Experimental Warnings	2
Internationalization Warnings	9
Malicious code vulnerability Warnings	15
Performance Warnings	22
Security Warnings	2
Dodgy code Warnings	61
Total	154

SpotBugs (master)

Warning Type	Number
Bad practice Warnings	8
Correctness Warnings	35
Experimental Warnings	2
Internationalization Warnings	9
Malicious code vulnerability Warnings	15
Performance Warnings	22
Security Warnings	2
Dodgy code Warnings	61
Total	154

Lint increased!

[AlvaroBrey]

Hey @koo5, thank you very much for the time and effort gone into this. We would love to have this implemented in Talk, as it can help our users become more independent from Google infrastructure.

Can you write some instructions on how to test this (server + android setup)?

[AlvaroBrey]

• another design issue is that unifiedpush.ChatAndCallMessagingService is largely a copy of firebase.ChatAndCallMessagingService - not sure where to create a common ancestor.

You can create an ancestor class in the main sourceset; it doesn't do any harm as it will only be registered in the specific flavor's manifests.

[ASerbinski]

Unified push is interesting, but I think that this is the wrong approach. There are more than one option for not-google push message delivery, another that is probably more helpful is https://gitlab.com/Nextcloud-Push which operates server side as a plugin to nextcloud itself, meaning that you install the proxy into your nextcloud instance, and then Nextcloud can push the messages directly to the client itself.

Another option would be to work somehow with Nextcloud Files HPB.

So the problem then becomes that this approach would lead to the need to publish multiple separate variants of Nextcloud Talk, whereas in my view, a more ideal solution would be to be able to support all of the different push message delivery mechanisms within the SAME variant.

Obviously a google variant has to be kept separately from an "everything else" variant in order to include on F-Droid, but in my opinion, it would be more proper for all of the additional delivery mechanisms to be available on BOTH variants.

The user should be asked which push delivery mechanism to use during initial setup.

[AndyScherzinger]

Sorry for potentially widening the field of option, but linking to the discussion of the Android files app regarding supporting an alternative push solution, see also: https://github.com/nextcloud/android/issues/5510 as well as https://github.com/nextcloud/android/issues/8684