Is there a list of Flutter stable widgets?
I've found several lists of nice flutter widgets, but as many of them have just been released, I'd like to select the stable ones and build over them. This way I'll keep the newer versions for a future version of my App.
You probably want to select a specific Flutter build release channel:
master & dev are probably not what you are looking for as they get updates basically as soon as possible (dev only once fully-tested)
beta has most of the latest functionality but the most stable / "best [..] build of the previous month"
stable. If you were really concerned, you could choose this, however, this will lack features of the pat few months.
In general, everything that makes it to beta has proven to be pretty "stable". Flutter uses continous integration and is pretty well-tested.
All of the official Flutter widgets should work without any issues and if you ever encountered an "unpredictable" bug, you could just open an issue or fix it yourself.
Related
Hay, I want to make a "Privacy Policy Checkbox" that includes a Text Hyperlink, and I found Link Plugin in pub.dev that what I want to use, but unfortunately it doesn't support Null Safety. I am running in flutter 2.5.1.
When I used the Link Widget from that package it shows a notification
the library 'package:link/link.dart' is legacy, and should not be imported into a null safe library
and I can't hot reload my project anymore. What other method can use to show a Hyperlink text in flutter?
Use it like this
link:
git:
url: https://github.com/phansier/link.git
I am going to make this a longer answer not just specifically for your exact library because this is an issue that I can see happen more often. The options below may not all work in your usecase but will cover other cases as well.
Option 1 - Check for beta releases
Sometimes the migration has been completed but not yet released as stable. You can have a look in the Version tab on pub to see if one of the prereleases is marked with the Null Safety badge:
Option 2 - Check the repository
Sometimes the migration has been completed but not yet released on pub at all. There are a few ways of checking:
Look into the pubspec.yaml, the environment.sdk key should list '>=2.12.0 <3.0.0' (the lower bound may be higher; there are libraries that use '>=2.14.0 <3.0.0' but 2.12.0 is required for null safety).
Look into pull requests and search for null safety; maybe one is merged already which would indicate that the change is on the branch it was merged on
Look into issues and search for null safety; maybe one is closed and the maintainer dropped "Done" or something alike in the thread which would indicate that the change is on the branch it was merged on
If you find that indeed, the repository is on a version where it's null safe, you can use a git reference in your pubspec file:
link:
git:
url: https://github.com/galonsos/link
ref: master
Read more about referencing a package from git in the pub docs.
Option 3 - Check forks of the repository
This is something you will likely do together with option 2. When scrolling through issues and PRs, you might stumble over someone who says "I did this on my fork" or an open PR by someone who has converted the library over (this happened in your case: relevant PR). If you find an actively maintained fork that meets your requirements, reference that with a git reference in your pubspec file, just as before.
Option 4 - Open an issue and wait (if none exists yet)
This obviously depends on whether the author of the package is still active somewhere around or whether you have the time to wait. Either way, it's never a bad idea to open an issue for an issue.
Option 5 - Do it yourself
Migrating a library to null safety can be time consuming, depending on its size and complexity. Regardless, it may be your only option in case you have an extremely specific library you don't want to rewrite from the ground up and it's a good exercise to better understand the library and dart itself.
If you are nice, be the person you hoped you had found before you and open a PR to the original repository when you are done, so someone else is already helped with option 3 :) And, of course, use a git reference to use your newly upgraded package.
Option 6 - Use an alternative
This might not always work but could be faster than doing the null safety migration yourself. There are often other packages that do something similar in a slightly different way. And even if not, you can sometimes build a quick alternative yourself. A link can quickly be built using some GestureDetector or InkWell and the url_launcher package (which is the same setup used in the link package) for example.
Option 7 - Drop sound null safety
If none of the other options are valid for you, you can drop sound null safety by running your app with --no-sound-null-safety. You can silence the analyzer warning with a comment:
// ignore: import_of_legacy_library_into_null_safe
import 'package:link/link.dart';
I am not sure how that impacts hot reloading however and it's a good idea to try and use one of the other options before going for this.
I recently upgraded to Flutter 2.0. I have dozens of Flatbuttons that are now deprecated. It's going to take me a few days to fix them all. What are the consequences of shipping an update before then with deprecation warnings? The app still builds and runs fine.
Basically this code will be deleted in future releases of flutter/flutter packages. Most of the time, api's get deprecated when a bug that requires a completely new implementation that will break compatibility or a better implementation that will break compatibility.
Therefore, you can use deprecated code but you should be very careful as they are not maintained and might stop working or deleted in the future. So as long as you are not updating versions you should be fine but it is highly unadvisable.
The problem is that your code will be updated and the flutter will no longer support this widget.
But flutter 2.0 has a tool to help with that. Run the command on your terminal to see what has been depreciated and needs to be updated.
dart fix --dry-run
And execute this other command for fix the depreciated items.
dart fix --apply
For more details about fix, click here
https://pub.dev/packages/firebase_admob
https://pub.dev/packages/admob_flutter
What are the differences between these 2 packages?
firebase_admob is the official one while admob_flutter will support native ads soon (apparently). I have tried them both and found no issues but I wanted to know which one is better than the other.
The message that they will support native ads was listed since Dec. 10 2018, the first version.
Also even though it is called firebase_admob and it may seem like it is directly constructed for Flutter if you look at the GitHub repo readme, it shows that it is part FlutterFire.
[firebase-admob] tag exists while [admob-flutter] on Stack Overflow which makes it seem like it would be harder to get help when using since both of the packages don't have a proper API doc
It seems like firebase_admob would be better than admob_flutter as it seems to have a bit more features and can be more trusted to be maintained and up to date.
Update Edit: Now google_mobile_ads has been released with native ads for flutter.
I have started learning flutter after 5 years of android dev. And right now i am trying to implement multi modular clean architecture as i used to, when developing android, example of such architecture: https://github.com/android10/Android-CleanArchitecture
And i have ran into two issues i can't solve by on my own.
1) What type of flutter module should i use module/plugin/package? I want to make domian layer as simple as it could be(list of interfaces,mappers and dto's), in android it was written in plain kotlin without any android sdk's usage. It seems like domain layer should be package(because it doesn't have any platform specific code and seems to be the simplest module possible) and data layer should be plugin in case i would be forced to make some platform specific code here, but i am not sure. It would be great to have some suggestions here.
2) Maybe there is a github repo example, as I have shown above? All git repos i have found so far are implementing clean architecture with just folders and this approach always ends up with dependencies mess, loosing all the profit you can get from clean architecture.
Any help is appreciated!
You could pay attention to the library clean_architecture (https://pub.dev/packages/clean_architecture).
It may be possible to implement a clean architecture not by all the rules, but it brings a certain useful result.
In the near future I will add instructions on how to use it
The Dart FakeAsync package seems to have the same functionality as quiver.testing.async inside the Quiver package so as a Flutter and Dart app developer I'm confused as to which one to use?
Is one supposed to be used over the other in particular circumstances? nothing in the documentation for either package gives any guidance on this either. Both packages also seem to be authored and maintained by members of the Google Flutter and Dart teams which makes it even more confusing.
The only thing I can see is that FakeAsync package is last updated in July 2018 while Quiver was in Nov 2019, so is FakeAsync deprecated? if so it's not labelled as such. And also a small number of core packages currently depend on FakeAsync, while a very large number of diverse package depend on quiver (though can't know if they depend on quivers testing.async).
I tried (with limited success) to dig into the muddled history.
FakeAsync was a third-party contribution to quiver, and a few months later, the author forked package:fake_async from quiver's version. I don't know what the rationale was for having two separate implementations, but I could guess that perhaps the author wanted to have more direct control over the code. (In other words, package:fake_async initially was not authored nor owned by Google.)
I asked around, and my understanding is that package:fake_async stopped being maintained, and Google's Dart team ended up taking ownership of package:fake_async so that it could be updated for Dart 2.
From package:fake_async's changelog, it does appear that it was meant to be a superset of quiver's version, but the implementations have since diverged so that it's no longer fully backward compatible.
At this point, I personally would use the quiver version: it's better maintained and is what Flutter uses, so I expect that it has much more inertia behind it.
I've also filed https://github.com/dart-lang/fake_async/issues/16 requesting that guidance be added to the documentation.
Update
I now recommend using package:fake_async. Flutter moved in the other direction and switched to using package:fake_async instead. package:fake_async has been updated to be a proper superset of of the quiver version. Also see https://github.com/google/quiver-dart/issues/590.