1.0.1
The transition from 0.8.1 to version 1.0.0 and the big change to push notifications and a new server were not as smooth as hoped. A lot of people struggled with the new push notification setup, as it was not that straightforward. Together with some server issues (a ddosed server and other servers that rate-limited us), this resulted in a large number of emails, social media posts, and GitHub issues to address. It took quite some time to answer all of them. Creating a detailed explanation of how to set up the push notification in the wiki helped, but the page could have been more visible. Version 1.0.1 addresses some of the issues and bugs.
What's changed in version 1.0.1?
- fix bug with swapped coordinates after a resubscribe
- add a notification self-check view
- add a new dialog to change the UnifiedPush distributor
- other bug fixes
Fix bug with swapped coordinates after a resubscribe
To permanently store subscriptions on the disk, we have to serialize and deserialize the data. Therefore, the coordinates from the LatLng objects are transformed to JSON and stored on the disk, and if the app is started the next time, this JSON object is loaded, and the coordinates are transformed back to a LatLng object. Unfortunately, the LatLng.toJson returns the coordinates in the order [longitude, latitude], but we expected that the coordinates would be in the order [latitude, longitude]. This minor bug resulted in swapped coordinates. As long as the subscription was active, this was not noticeable, but if the subscription expired and the user clicked on the resubscribe button, the subscription was for a completely different area of the world. This indicates that we will have a long way to go in testing to prevent introducing similar bugs in the future. Notification Self-Check
A lot of users complain about missing tools to verify that the push notifications are working. So this update adds a self-check to test the complete notification chain. The current check tests:
- if the app has the permission to send notifications
- if there is a UnifiedPush distributor installed on the system
- if the app is registered for push-notifications
- if the app is able to subscribe with the current config
- if the selected server is known for issues
- if the notification arrives on the device
There is also a new wikipage to explain the tests: https://github.com/nucleus-ffm/foss_warn/wiki/Notification-self-check Simpler way to change the unifiedpush distributor
This update adds a new dialogue to easily change the used UnifiedPush distributor. This also automatically updates every subscription with the new push notification configuration.
I hope that these checks help to identify the most common issues. Other bug fixes
A bug with parsing BiWapp alerts is now fixed. Next steps
Push notifications are a great feature, but the UnifiedPush setup is not as convenient and reliable as it should be. I hope that every component will improve in the future and that we reach a point where no one has to worry about receiving push notifications, and the system just works. Until then, we will bring back the legacy polling mode, which does not require a working push notification setup. Until recently, a bug in the UnifiedPush connector prevented us from using the AlarmManager (which is required for this type of polling) together with Push notifications using UnifiedPush. This bug should be fixed in the meantime, and we can implement the polling mode as a fallback. Next Events
I will be attending the Chaos Communication Congress this year. Volker Krause and I might have a small self-organized session about the FOSS-Public-Alert-Server and FOSSWarn. Feel free to visit us at KDE. If we have details about our self-organized session, we will post that on Mastodon. Make sure to follow us there. Do you want to help?
There is a lot to do, and we could use any help we can get. If you are interested in coding, communication, or just helping with testing, join our Matrix space and contact us.