Fixes #241

[GlebMikhailov]

This MR fixes issues found in closed MR #241. In particular, the NotificationUtils class has been split, the function has been renamed from jitsiCallIntent to getCallIntent, and a new method for removing notifications from the user side - rejectNotification - has been added.

[SpiritCroc]

Note of advice, if you want to have any chance that I review this PR to maybe get it merged at some point, changes should be minimal to achieve the goal, while being as upstream-merge-friendly as possible. Currently the diff is way too huge and touches lots of upstream files. You may want to read up on #250 as well for some hints.

[GlebMikhailov]

This MR incorporates all the logic that appeared in MR #241 and includes fixes for all comments. In order to improve maintainability and readability, the NotificationsUtils class was refactored. As a result, three new classes were created: NotificationBuilderUtils, NotificationCommonUtils, and NotificationUtils. This entailed changes to a number of files related to method porting.

[GlebMikhailov]

Made changes: put all utils for jitsi into a separate class - JitsiNotificationsUtils. Went through the whole code - significantly reduced upstream issues.

Could you please take a look at this MP?

[alexander-potemkin]

Note of advice, if you want to have any chance that I review this PR to maybe get it merged at some point, changes should be minimal to achieve the goal, while being as upstream-merge-friendly as possible. Currently the diff is way too huge and touches lots of upstream files. You may want to read up on #250 as well for some hints.

Hey @SpiritCroc , Merry Christmas! :)

And thank you for checking that PR - it was me, who asked @GlebMikhailov to take over where it was left earlier, with the respect to all the comments you made earlier, to make sure the PR will be easy to accept and maintain.

I remember you do it in your free time and I understand if you will refuse it, I hope however, that there will be a way to make it all right and comfortable for you to accept - please, don't hesitate to let us know on anything that shall be adjusted 🙏🏻

[SpiritCroc]

Thanks. On first glance I thinks it looks better than the old PR. Like usual, I don't know when/if I'll have time to properly review this though.

One remark from my first look, does anybody actually need settings_labs_enable_jitsi_call_notifications_default? I think I removed it in my clean up of the old PR before but it's again here in this one. For me looks just like a useless source of merge conflicts, since we don't have the use-case that upstream has for such config resources. If it's needed for anything, should be moved into something like config-settings_sc.xml but probably best to just drop it

[GlebMikhailov]

Good afternoon!

Thanks for the feedback! Made the changes, can you please take a look at it when you have time?

[SpiritCroc]

I'm sorry, after some more consideration I decided I will not add any bigger new features to the codebase. Main reasons being

• Element is starting to prompt users to the new app already, so the upstream codebase is quite close to EOL
• I don't really use the old app myself anymore

Which means I want to prioritize stability and minimize maintenance effort, I hope this is understandable.
Forks are welcome if people want to continue adding new features to the old codebase, of course.

[alexander-potemkin]

I'm sorry, after some more consideration I decided I will not add any bigger new features to the codebase. Main reasons being

• Element is starting to prompt users to the new app already, so the upstream codebase is quite close to EOL
• I don't really use the old app myself anymore

Which means I want to prioritize stability and minimize maintenance effort, I hope this is understandable. Forks are welcome if people want to continue adding new features to the old codebase, of course.

Thanks for letting us know - that makes perfect sense.

If that's not too much to ask - may I kindly ask you to highlight key steps required to create production build working with Google Push notifications?
I've tried to find a proper build 'target' - there are tons of them... And, whatever the target, I ended up with background notifications and not with Google's Push...

I will certainly understand if not, but if you can share / highlight anything at all - that would be of great help!!

[SpiritCroc]

If that's not too much to ask - may I kindly ask you to highlight key steps required to create production build working with Google Push notifications? I've tried to find a proper build 'target' - there are tons of them... And, whatever the target, I ended up with background notifications and not with Google's Push...

I will certainly understand if not, but if you can share / highlight anything at all - that would be of great help!!

Just do a normal release build with gplay flavor. You can probably find how to do release builds for Android apps somewhere online. Push should also work in debug builds though, the flavor is what matters for that.

You could switch the FCM API keys and server address to your own or the matrix.org one as found in upstream Element code if you don't want to rely on SchildiChat infrastructure, but it should work without modifying these too.