Prepare release 1.1.0

docs/docs/en/release_notes/32.md

@@ -0,0 +1,50 @@
+This release has once again taken longer than expected, but I think it was worth the wait. This release brings long-wanted features like a map view and is the first release of FOSSWarn, which is funded by NL-Net. As the project is now funded by public money, I would like to give you a more detailed overview of what has happened, what challenges we had, and what comes next.
+
+So first of all:
+What's new in FOSSWarn 0.8.0?
+
+The new version brings the following changes:
+
+- The CAP data structure
+- A map view
+- An error logger
+- Preparations for version 1.0.0 for the FOSS Public Alert Server
+- A thread view of updated alerts
+- some bug fixes
+
+CAP data structure
+
+As I started the project, I wasn't aware of the CAP standard, so I implemented the data structure as I thought would be the best. This was fine in the beginning, but I noticed the limitations later. Therefore, I had to rethink the data structure to make FOSSWarn more future-proof, also with the FOSS Public Alert Server already in mind. FOSSWarn now follows internally, mostly the CAP, too. As one of the consequences of the new data structure and to improve the code quality, I also removed the old legacy API, which was still used to display all alerts if the option "Display all available alerts" was activated. This was replaced by the new API.
+The new map View
+
+This features was on the wish list since the beginning of this project. For a long time, this feature was blocked because I was unsure which OpenStreetMap tiles server (aka the server that gives you the rendered PNGs with the map on it) I could use without any budget. I got the hint that I could use the official server with their permission. So, I asked and got permission.
+
+Handling maps and polygons brings some challenges. The first challenge was to implement a dark mode for the map. I realized that the official OSM tile server does not render a dark mode theme for the map. As I didn't want to blind all the dark mode users, I had to find a workaround. The workaround was then to manipulate the colors of the PNGs. The best solution was to invert the color by 100%, rotate the hue by 180deg, reduce brightness to 95%, and set contrast to 90%, resulting in the map's current dark theme. Let me know what you think about the color theme.
+
+The next step was to draw the polygons on the map. This required some changes in the existing codes as I had not fetched the geoJson files for every alert before. As I already rebuilt the data structure, I also changed the API logic and also fetched every geoJson file. One side effect was that the speed of API requests decreased a bit. For a handful of places, this isn't noticeable, but the view of all available alerts is significantly slower now. As the overview of all available alerts is probably only used out of curiosity, that is manageable.
+
+Polygons also tend to be too detailed, which results in some performance issues. To avoid problems, we use the Douglas Peucker algorithm to reduce the complexity of polygons. This is just the first implementation and will be further improved in the future.
+Error Logger
+
+One feature that makes debugging a lot easier is the new error logger. The error logger is quite simple as it just writes any error thrown into a log file and displays a dialog to the user. The log file is (of couse) locally on your devices. There is no automatic transmission of log informations to a server. However, if an error occurs and you open a Github issue, you can attach the corresponding part of the log file there. This will make it a lot easier to find and fix the error.
+Preparation for FPAS
+
+This version will be the last version with direct support for the Nina-APIs. Starting with version 1.0.0 FOSSWarn will completely switch to our new FOSS Public Alert Server. Volker Krause and I are developing this server, which will feature emergency alerts for over 100 countries and push notifications via unifiedPush. This release already contains a lot of code changes for FPAS, but these have not been activated in this release yet. One of the preparations that is already visible is the new view to select a place. You can find the dialog as feature preview in the development settings. The new view searches with nomination for places and lets the user choose a polygon on the map, which will then be subscribed for.
+Thread view of updated alerts
+
+FOSSWarn now displays only the latest alert in the overview. If there are any previous alerts, the alert will have an additional icon that leads to a thread view of the current and all previous alerts. Notice: If the previous alert is removed from the server, FOSSWarn will not display it anymore.
+Bugfixes
+
+This release fixes some bugs. Among others, we fixed:
+
+- a bug with the read status of alerts. This bug is fixed for now but will require some more changes in the future to create a cleaner solution.
+- in the detailed view of a warning, some tags were challenging to read due to a poor contrast value
+
+Team changes
+
+The majority of the work on FOSSWarn is done by myself. But I also have some contributors. Thanks to every weblate contributor who helped translate the app. This release also brings some updated translations.
+
+Previously, Mats had helped out with the project. Unfortunately, he doesn't have the time anymore. Thanks for your work.
+Next steps
+
+The next step will be version 1.0.0, with the first stable support for the FOSS Public Alert Server. You can follow the development on gitlab or follow the Mastodon account

docs/docs/en/release_notes/38.md

@@ -0,0 +1,44 @@
+After a long development phase, it is now time to publish the next release of FOSSWarn. Version 1.0.0 brings a lot of changes and states out the future of this project.
+
+A lot has happened since the last stable release with version 0.8.1. Basically, no code line stayed untouched. This release note gives you an overview of what has happened, what the state is today, and what will happen in the future.
+
+What's new or changed in version 1.0.0?
+
+- code refactoring
+- replaced the old APIs with the FOSS Public Alert Server API
+- use push notifications now
+- auto refresh instead of pull to refresh
+- updated dialogs
+- Linux support
+- Bug fixes
+
+Code refactoring
+
+Refactoring is a permanent task to constantly improve the code quality and to clean-up the codebase. With a lot of the help of @pureTryOut, we changed the naming scheme of files, replaced old plugins like the 'provider' with 'riverpod', implemented a new view routing with GoRouter, and improved the code structure in general.
+FOSS Public Alert Server
+
+This is the major change in this new version. We are now using the FOSS Public Alert Server to receive push notifications about alerts. The FOSS Public Alert Server is being developed by KDE and the FOSSWarn team. Over the last year, we developed this server to aggregate and distribute CAP alerts globally. This not only allows FOSSWarn to be used in more countries but also provides the first open source push notification infrastructure for emergency alerts. We are using the open source and decentralized UnifiedPush system to deliver near-real-time notifications about alerts.
+
+This completely replaced the old polling for alerts and should drastically reduce delays and improve the battery life. Developing our own server also allows us to ensure that we do not rely on undocumented third-party APIs. This is now handled by the server.
+Test alerts
+
+The new system required new testing methods. Therefore, we developed a test alert system on the server. To avoid interference with real alerts, we publish alerts at the point of the Earth with the largest distance to the nearest coast. This place is also called Point Nemo. In the developer options of FOSSWarn, you can subscribe to these alerts. You should receive a new test alert every 5 minutes.
+Auto refresh instead of pull-to-refresh
+
+This is one of the noticeable changes in the UX of the new app version. If you are on the "My Places view" or the "all Warnings view", there is no option to pull to refresh anymore - instead, the app updates automatically as long as it is open.
+Updated dialogs
+
+The implementation of the FOSS Public Alert Server required updating some dialogs. The introduction has now been updated, and there are some new dialogs, e.g., for missing UnifiedPush distributors. We used the opportunity to update the graphics in the introduction to give it a more unified look.
+Linux support
+
+FOSSWarn now supports Linux. This brings the app closer to Linux desktop applications or even Linux on mobile applications. This was mainly done by @PureTryOut. We are still working on packaging the app and bringing it into the Flathub store. This will still take some time, but experienced users can already try out the GitHub release.
+Bug fixes
+
+In the process, we fixed, created, and fixed again a lot of small or medium bugs. It is expected that there will be some minor bugs that will be fixed with some bug-fix releases.
+Next steps
+
+First of all, we need to see how the server can handle more users. Currently, we only have about 150 subscriptions. We expect that this number will increase as soon as the update reaches the F-Droid store. After that, we will see if we need to fix things on the server side.
+
+We plan to implement improved filtering for alerts to allow more precise settings for which event type you would like to receive alerts and for which not. We also need to re-implement the silent notifications for updated alerts.
+
+In a later release, we also plan to implement an automatic location-based subscription for alerts.

docs/docs/en/release_notes/41.md

@@ -0,0 +1,41 @@
+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.

docs/docs/en/release_notes/44.md

@@ -0,0 +1,48 @@
+# 1.1.0: Bring FOSSWarn to a stable state again.
+
+It has been a journey since the release of version 1.0.0. Many things were not working as expected, so version 1.0.1 focused on fixing some bugs. But there were still many remaining. User complained about the removal of features present in version < 1.0.0, and the entire push notification system proved unreliable.
+So this release focuses on bringing FOSSWarn back on track.
+
+<!--begin_changelog -->
+What's new or changed in version 1.1.0 compared to 1.0.1?
+
+- Over 150 commits just with bug fixes.
+- A new feature to get alerts for the current location
+- Implement an alert filtering based on the alert categories
+- Implement an alternative to push notifications
+- Some small UI improvements
+- A brand-new documentation hosted on docs.fosswarn.org
+<!--end_changelog -->
+
+
+## Bug fixes
+This turned out to be a bigger thing than expected. FOSSWarn was full of both minor and major bugs. Some things were known issues, and I was lacking the time to finally fix them. Other things were noticeable while using the app, but I did not know where this was coming from, and some aspects were just working, but could have failed at some point in the future. People who are interested in all the improvements take a look at the commit messages.
+There are still some known issues remaining that need to be addressed in the future, but hopefully, I caught the most important ones now. Let's see.
+
+
+## Alerts for current location
+A feature that was on my own wishlist since starting to work on the FOSS Public Alert Server was getting alerts automatically for your current location. You can now enable this optional feature in the settings, and FOSSWarn will subscribe to your current location, and you will get
+alerts at this location. FOSSWarn currently tries to update the location every 1.5h. This is still an experimental feature, so expect it not to be perfect. One known limitation is that you might get notifications twice
+if you manually select the same area, as the current location feature is also subscribed to.
+Try it out and let me know what you think and how it works for you.
+
+
+## Alert filtering based on the alert categories
+Long-time users will remember that in version < 1.0.0, FOSSWarn provided a feature to select the alert notifications they want to get based on the alert source. This feature was not usable anymore with the server. Listing >150 sources was not a suitable approach, so this feature was removed. Of course, the user complained about that, and indeed, this was
+a lacking feature. This release introduces a new filtering feature. This filtering is based on the alert categories that are defined in the CAP standard. You can now select either a global level or, if you want, select a higher level for some alert categories. Like this, you can, e.g., only get severe weather alerts but minor alerts in
+all other categories. This is an effective and even better replacement for the old filtering.
+
+## Alternative to push notifications
+Push notifications are the way to go, and the FOSS community must work on making them easy to use and reliable. Bother is currently limited, and some others just do not want to use them. So this brings back a similar feature that was used in the previous version. If you select "legacy polling," FOSSWarn can wake up in periods to check for new notifications. This will delay notifications and drain your battery more than push notifications, but it is simple and requires no additional applications or push server. As I was working
+on it, I directly added two more modes. One is to combine push and poll. So, using the polling as backup in case
+push fails (still very much experimental) or disabling notification at all if you only want to see
+alerts when you open the app. To test if everything is working, you can subscribe to Point Nemo and
+get test notifications every 5 minutes.
+
+Side note: In the developer options, there is now a toggle to turn off the search map search restriction. If you turn that off, you can search for everything (also for point Nemo) that OSM has to offer.
+
+## UI improvements
+While implementing bug fixes and other features, I made some small touches to the UI.
+
+## Documentation
+To reduce my email volume and improve the user experience, I wrote documentation for FOSSWarn. Hosted under docs.fosswarn.org. It provides basic information and an explanation to make FOSSWarn self-understandable. The docs will be expanded in the future, and I would really appreciate any help with that. It's just Markdown, so there is no reason why you can not help improve these docs. Check it out. 

docs/mkdocs.yml

@@ -52,6 +52,11 @@ nav:
       - Location Tracking: features/location_tracking.md
       - Notification Setting: features/notification_settings.md
       - Notification Self Check: features/notification_self_check.md
+  - Release Notes:
+      - 0.8.0: release_notes/32.md
+      - 1.0.0: release_notes/38.md
+      - 1.0.1: release_notes/41.md
+      - 1.1.0: release_notes/44.md
   - FAQ: faq.md
   - Contribute: contribute.md
 
@@ -72,7 +77,7 @@ plugins:
           # Navigation (EN) – Übersetzungen
           nav_translations:
             Getting Started: Einführung
-            Installtion: Installation
+            Installation: Installation
             Android: Android
             iOS: iOS
             Features: Funktionen

fastlane/metadata/android/en-US/changelogs/44.txt

@@ -0,0 +1,6 @@
+- Over 150 commits just with bug fixes.
+- A new feature to get alerts for the current location
+- Implement an alert filtering based on the alert categories
+- Implement an alternative to push notifications
+- Some small UI improvements
+- A brand-new documentation hosted on docs.fosswarn.org

lib/constants.dart

@@ -1,6 +1,6 @@
 const String defaultFPASServerUrl = "alerts.kde.org";
 const String httpUserAgent =
-    "FOSSWarn/1.0.1 (Android)"; //@TODO (Nucleus) fetch data automatically
+    "FOSSWarn/1.1.0 (Android)"; //@TODO (Nucleus) fetch data automatically
 const List<String> serverThatAreNotWorking = ["ntfy.sh"];
 const List<String> serversWithIssues = ["unifiedpush.kde.org"];