Nice! I didn't even notice this bug when checking it out.
My only concern is with the debugPrint. It also prints in production, which is concerning, because if an error occurs with any of the apis, and this prints it then any of the api-keys could be compromised. What was wrong with the normal prints?

Yeah it might be a good idea to write unit tests for the business logics. My suggestion is to separate all the logics such as calling APIs, calculating certain info, post processing data and ... into the new services folder I created, for better code readability and making it easier to maintain the code especially for contributors. This also helps with writing unit tests specific to each service and function. You can also take this to the next level and make sure the tests are run via GitHub actions and enforce a PR rule that the tests must pass before merging the PR.
An example: https://calmcode.io/course/github-actions/prevent-merge

Regarding your concern, well your concern is valid 🙃; however, we have the same risk using the existing print(). I changed the code to printDebug() because it is

• Primarily intended for use in debug mode, but can also be used in release mode. However, print() always prints, regardless of the build mode (debug, release, or profile).
• Has better performance than print(). Print may lead to performance issues if used excessively.

and that is why it is actually recommended to avoid using it (https://dart.dev/tools/diagnostic-messages#avoid_print).
It is a lint rule, if you enable the Flutter extension on VS Code it would show you these kinda warnings.

Back to your point, although debugPrint is better, neither is safe in production in the context of exposing sensitive info. My suggestion is either to explicitly limit debugPrint using kDebugMode or kReleaseMode (https://api.flutter.dev/flutter/foundation/kDebugMode-constant.html) or use a proper logging framework instead of just printing the exceptions.
Implementation Example: https://blog.logrocket.com/flutter-logging-best-practices/

Oh, I thought normal prints would stop in production...
Then you are right with the debugPrint.

About putting the api calls and calculations into the Services file I think that's a good idea, and i am already planning putting stuff like the image and radar apis in there in a separate file for each because it was kind of unnecessarily cluttered into the extra_info.dart file. I think the weather provider code can stay in the decoders folder though.

About the pr tests, i think they are at the moment way too overkill because you are the only one who has submitted pull requests here, aside from the translations. Maybe when there are more of them, and start to begin to get unmanageable.

The kDebugMode check is a good idea though, and i will probably put that into the main because that is the only part that can print sensitive data.