First and foremost, GitHub is proprietary software. I value free software very highly, and this alone would have made me attempt moving Clima to another forge, but that's not the only issue at hand. I highly recommend reading https://github.com/toastal/toastal/blob/f%F0%9F%92%80ck-github/README.adoc; it articulates my concerns very well.

Thus, I propose moving Clima to a software forge that actually supports free software values. Here are a couple options:

• Codeberg - this is what I personally use for my projects, and it works quite well in my experience. It uses Gitea, an open-source hosting solution for Git.

  Advantages (these apply to any Gitea instance):

  • GitHub-like UI and workflow (not all people will view this as an advantage, me included, but it means that it's familiar to people coming from GitHub)
  • Seamless migration from GitHub, including issues and pull requests

• Sourcehut - this is an open-source forge with a particular focus on simplicity. For instance, it has no PRs; you submit patches to a mailing list.

  Advantages (these apply to any Sourcehut instance, though I'm not aware of any other than https://sr.ht):

  • Very simple and light on resources
  • Participation in projects does not require an account; you can, for instance, send patches and create TODOs (the equivalent of GitHub issues) by sending e-mails, without any need for an account. I consider this one of Sourcehut's biggest advantages.

  Considerations:

  • At some point in the future, hosting repos on https://sr.ht will require subscription (to be clear, people can still contribute without a subscription, only hosting repos will require payment). This isn't a bad thing really, but we have to keep it in mind.
  • It has no migration tools, so we would lose all our PRs and issues coming from GitHub. This may not be a big problem though if we keep our GitHub repo around as an archive/mirror.

Feel free to suggest other options, such as Gitea instances other than Codeberg and GitLab instances (https://gitlab.com is a no-go though, it has proprietary components).

We'll have to lose CI if we move to either of these platforms (Codeberg requires self-hosting CI, and Sourcehut has CI but it requires payment, though I hear it's pretty good), but I don't think that's a big deal. It's a mere convenience, we can still run checks on the code locally.

Ideally, we would archive Clima on GitHub, but I can reluctantly accept keeping it on GitHub as a mirrored repo. However, the issue tracker would be on whatever forge we move to.

Other things to consider:

• Should we accept PRs on GitHub? I'd say no, but I'm open to discussing this.

@PrestoSole what are your thoughts?

Describe the bug When I enter my API Key, it tells me that it is invalid.

To Reproduce Steps to reproduce the behavior:

1. Go to settings
2. Click on API Key
3. Enter an API Key

Expected behavior It should accept the API Key.

Screenshots Screenshot_20220421-140020.png

Smartphone (please complete the following information):

• Device: Pixel 4a
• OS: Android 12.1
• App version 2.0.1

Additional context I have tested multiple keys - I believe they are in fact valid.

Sorry if this isn't the right place for this - I didn't see anywhere else for support.

On the latest master, putting in an invalid city name causes the app to throw an error:

E/flutter (20602): [ERROR:flutter/lib/ui/ui_dart_state.cc(186)] Unhandled Exception: Instance of 'Error' E/flutter (20602): #0 WeatherRepoImpl.getWeather. (package:clima_data/repos/weather_repo_impl.dart:42:34) E/flutter (20602): #1 WeatherRepoImpl.getWeather. (package:clima_data/repos/weather_repo_impl.dart:42:22) E/flutter (20602): #2 Either.getOrElse. (package:dartz/src/either.dart:11:44) E/flutter (20602): #3 Left.fold (package:dartz/src/either.dart:180:63) E/flutter (20602): #4 Either.getOrElse (package:dartz/src/either.dart:11:28) E/flutter (20602): #5 WeatherRepoImpl.getWeather (package:clima_data/repos/weather_repo_impl.dart:42:12) E/flutter (20602): E/flutter (20602): #6 CityRepoImpl.setCity (package:clima_data/repos/city_repo_impl.dart:43:21) E/flutter (20602): E/flutter (20602): #7 CityStateNotifier.setCity (package:clima_ui/state_notifiers/city_state_notifier.dart:76:6) E/flutter (20602): E/flutter (20602): #8 LocationScreen.build. (package:clima_ui/screens/weather_screen.dart:95:11) E/flutter (20602): E/flutter (20602):

Description

Fixes #260

Fix the light theme issue on the license page where some text is invisible. Maybe the text could be darker, I did not really bother with the colors since I do not know the color scheme of the app and what every color is and what it means.

Screenshots

Testing

• [ ] This change adds test coverage for new/changed/fixed functionality

Checklist

• [x] The correct base branch is being used, if not master

~~app-release.apk.zip~~ app-release.apk.zip

Description

Previously it would call DateTime.now directly, which is wrong both because it can be different from the weather date, and because build methods should never return different results if called with an identical environment.

References

• Closes #187

Testing

• [ ] This change adds test coverage for new/changed/fixed functionality

Checklist

• [x] The correct base branch is being used, if not master

Launching Clima from Europe, on Android 10: App displays a loading icon and "Could not parse response" on every launch. I cannot reach the settings screen or any other part of the app.

(Clima 1.1 displays "Can't connect to server" instead.

And the download for Clima 1.0 on F-Droid is broken.)

Is your feature request related to a problem? Please describe. Currently, the app icon isn't adaptive, meaning it is placed on a white background:

Describe the solution you'd like Implement adaptive icon support: https://developer.android.com/guide/practices/ui_guidelines/icon_design_adaptive

It would look something like this mockup

Thanks!!

Description

References

Testing

• [x] This change adds test coverage for new/changed/fixed functionality

Checklist

• [x] The correct base branch is being used, if not master

A barrel file is something like this:

export 'foo/bar.dart';
export 'baz/bat.dart';

As for why we might want to do this, I'll let the data speak (this was run on up-to-date master, with no generated Dart files):

$ grep import -wr */{lib,test} | wc -l
     442
$ cloc */{lib,test}
      82 text files.
      82 unique files.
       0 files ignored.

github.com/AlDanial/cloc v 1.92  T=0.06 s (1382.2 files/s, 84230.6 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Dart                            82            717            467           3813
-------------------------------------------------------------------------------
SUM:                            82            717            467           3813
-------------------------------------------------------------------------------

442 over 3813 comes out to around 11.6% of all non-empty lines of code being imports. That's just ridiculous.

By submitting a PR to this repository, you agree to the terms within our Code of Conduct. Please see the contributing guidelines for how to create and submit a high-quality PR for this repo.

Description

Describe the purpose of this PR along with any background information and the impacts of the proposed change. For the benefit of the community, please do not assume prior context.

Provide details that support your chosen implementation, including: breaking changes, alternatives considered, changes to the API, etc.

If the UI is being changed, please provide screenshots.

References

Include any links supporting this change such as a:

• GitHub Issue/PR number addressed or fixed
• StackOverflow post
• Support forum thread
• Related pull requests/issues from other repos

If there are no references, simply delete this section.

Testing

Describe how this can be tested by reviewers. Be specific about anything not tested and reasons why. If this repository has unit and/or integration testing, tests should be added for new functionality and existing tests should complete without errors.

Please include any manual steps for testing any functionality not covered by unit/integration tests.

Also include details of the environment this PR was developed in (device/platform/version).

• [x] This change adds test coverage for new/changed/fixed functionality

Checklist

• [x] All active GitHub checks for tests, formatting, and security are passing
• [x] The correct base branch is being used, if not master

Describe the bug App labels tomorrow as "Today" and today as the day name

To Reproduce Steps to reproduce the behavior:

1. View weather screen

Expected behavior Today should say "Today" and tomorrow should be the day name

Screenshots This screenshot was taking on Wednesday, 2022-06-08 (yesterday).

Smartphone (please complete the following information):

• Device: Samsung Galaxy Z Flip 3 5G
• OS: Android 12
• App version: 2.0.1 F-Droid

From https://docs.flutter.dev/development/ui/advanced/splash-screen :

Previously, Android Flutter apps would either set io.flutter.embedding.android.SplashScreenDrawable in their application manifest, or implement provideSplashScreen within their Flutter Activity. This would be shown momentarily in between the time after the Android launch screen is shown and when Flutter has drawn the first frame. This is no longer needed and is deprecated – in Flutter 2.5 and later, Flutter automatically keeps the Android launch screen displayed until Flutter has drawn the first frame. Developers should instead remove usage of these APIs.

Description

Implement the wind direction in the shape of an [arrow] that corresponds to the given weatherDirection weather parameter provided by OpenWeatherMap's API.

After trying and failing, I realized how difficult it is to implement one icon that rotates precisely, so I just went with the easier if else statement, even if it's not as precise as the earlier approach.

References

Fixes #289

Testing

app-release.zip

• [x] This change adds test coverage for new/changed/fixed functionality

Checklist

• [x] The correct base branch is being used, if not master

Description

Add a release guide, to help reduce mistakes while releasing new Clima versions.

@PrestoSole please take a look, and leave a review if you think I forgot anything or want to ask a question.

References

Fixes #285.

Checklist

• [x] The correct base branch is being used, if not master

Description

Respect system's locale date format when displaying times/dates.

References

Should fix https://github.com/Lacerte/clima/issues/292, but still needs some work.

Testing

• [ ] This change adds test coverage for new/changed/fixed functionality

Checklist

• [x] The correct base branch is being used, if not master

lint hasn't been updated with Flutter 3 lints in a while. Possible alternatives:

• very_good_analysis: seems to be pretty strict, even more so than lint
• lints: "official" lint rules package, seems to not be as strict as the other two