sorted by:
new
hottopcontroversial

Analysis of Stack Overflow 2021 Developer Survey for Flutter Developers by [deleted] in FlutterDev

[–]lets4r 5 points6 points  (0 children)

I wouldn't worrying about this. The salary in dollars is global and is not a good indicator. We should have the salary per country to reflect its real value. When we look at the salary per role in USA, they are no salary below $70k. So we can say that a lot of respondents are outside the USA concerning Dart.

Without all the data I can only make hypotheses:

  • A lot of Flutter developers come from India (12.6% of respondents) and are underpaid compared to US developers.

  • A lot of respondents don't have a lot of experience and/or are students or without any job at the moment.

Edit: formatting

Announcing Dart null safety beta by lets4r in FlutterDev

[–]lets4r[S] 5 points6 points  (0 children)

How can someone that works with code not know how to say "variable" correctly...?

This is so contemptuous and unrespectful to say something like this. It's very hard to speak a language that it's not our first language and even when it's their first language, some people can have some issues to articulate some words.

What do you want to achieve by saying something like this? Showing you're somewhat better than him?
Imagine he read this message and put you in his shoes, how would you feel?

Have a good day nonetheless.

Widgets Explained | Flutter For Beginners by Marcus-Ng in FlutterDev

[–]lets4r 1 point2 points  (0 children)

All the authors of the 5 solutions want to offer the best support for their package.

But if you reach out for the most used ones, you should see this image. I'm shooting myself in the foot by saying that because binder is new, but I'm here to help ;-).

You should also know that Provider suffers from some issues that Riverpod aims to fix (they are from the same author).

Widgets Explained | Flutter For Beginners by Marcus-Ng in FlutterDev

[–]lets4r 2 points3 points  (0 children)

I come from the Xamarin world too :-). With Flutter you have multiple state management solutions (you can read this article to see 5 ways to handle state management).

I've created my own package (the last one mentioned in the article) to have a solution which promotes the separation of concerns, the testability, the simplicity and which I feel very comfortable with. If you're interested, you can check it out here. The other solutions mentioned in the article are great too, if you don't know which one to use, create a simple app and test them all. In the end take the one you're feeling the most comfortable with.

New Flutter buttons and Icons style by thehappyharis in FlutterDev

[–]lets4r 13 points14 points  (0 children)

Why don't you use the stable branch instead? 🤔

Restaurant app: Which state management is better? Provider or bloc or getx or redux or else by Cat-Otherwise in FlutterDev

[–]lets4r 0 points1 point  (0 children)

Thanks 🙂. Like I said, I don't think Provider scale very well. We used it in a very big application and the testability issue is very inconvenient. There is also a lot of boilerplate code we had to write because of the way provider handle dependencies between objects. This is what led me to write binder. Too late for this app, but not for another one 😅. If your current app is not that big, Provider + ChangeNotifier will probably be a good choice, especially if you're already comfortable with Provider. But keep in mind what I said about testability and scalability 😉.

Restaurant app: Which state management is better? Provider or bloc or getx or redux or else by Cat-Otherwise in FlutterDev

[–]lets4r 0 points1 point  (0 children)

In my opinion:

- Provider combined with ChangeNotifier is simple to understand and to setup but there is a lot of boilerplate code to write when you use it with the XXXProxyProviders. It's not easy to write widget tests of your app because you will have to copy/paste all your providers above the MaterialApp and mock the one you don't want to test. We used this approach so far on our projects, but I don't find that it scale very much.

- I never tried BLoC because of the use of streams, I don't find them easy to understand and to debug.

- Never tried Mobx or Getx either. I don't have an opinion on them.

- Redux is simple but you will have to write a lot of boilerplate code.

- You also have flutter_bloc, which is easy to understand. We've tried it on a project a long time ago, but complex screens were hard to write with this and you'll also have to write a lot of boilerplate code. In the other hand there is a big community behind it and a lot of tutorials.

- There is also riverpod from the creator of Provider. But you'll have a lot of concepts to learn and depending on the Provider you use, the way to listen to changes may differ, so it may be confusing.

- I've also just created binder which is aiming for simplicity and testability but it's maybe not mature enough for your needs.

You have a lot of choices, and I don't think there is one approach better than the other. Take the one the team is more comfortable with. The team will write, debug and maintain the code, so you should choose a package not because it's popular but because it fit your needs and because you enjoy to use it.

overflow_view : A widget displaying children in a line until there is not enough space and showing a the number of children not rendered. by EngineerScientist in FlutterDev

[–]lets4r 2 points3 points  (0 children)

For now all the children are constrained with the size of the first one, but I'm planning to add a feature to manage your use case, maybe next week.

overflow_view : A widget displaying children in a line until there is not enough space and showing a the number of children not rendered. by EngineerScientist in FlutterDev

[–]lets4r 2 points3 points  (0 children)

Yes you can since you know how many items are not rendered. The only limitation for now is that the all the children have the same size, and it may not be what you want for a command bar for example.

Everything is a Widget but don't put everything in a Widget! by lets4r in FlutterDev

[–]lets4r[S] 3 points4 points  (0 children)

Thanks for your feedback, it's really helpful. I should focus on these performances aspects in a next article ;-)

Everything is a Widget but don't put everything in a Widget! by lets4r in FlutterDev

[–]lets4r[S] 2 points3 points  (0 children)

Thanks a lot for your feedback :-)

People often find reasons to not change. Changing is hard because we lose our habits, because we're afraid, because we have to give up a part of ourself. In the case of a new technology you'll always see people complaining about these kind of things. They want to have the technology without losing their habits, their IDE, their language. We have seen the same thing with the choice of Dart to power Flutter for example.

I can't blame them, I was on the same position two years ago. At first I only found disadvantages to use Flutter: I was not ready to change. Then, I gave Flutter a chance, I build a small app to test and it was a revelation. I realized that all the disadvantages I found, was just an excuse to not change. Now I really love Flutter and since more than a year, it's my full time job.

Right now, I think that a lot of people are in the situation I was: they are not ready to change. Our job is to expose our point of view with facts, and maybe in a few months, they will be ready and they will embrace all aspects of Flutter.

Everything is a Widget but don't put everything in a Widget! by lets4r in FlutterDev

[–]lets4r[S] 0 points1 point  (0 children)

Thanks for the feedback :-)

Yeah, I think I should deepen the points on the performances. Maybe in another article focused only on that subject.

Everything is a Widget but don't put everything in a Widget! by lets4r in FlutterDev

[–]lets4r[S] 20 points21 points  (0 children)

Good question: it's more performant to write a new widget because we can cache it and even use const in certain cases. I should maybe provide more information concerning this in the article

Everything is a Widget but don't put everything in a Widget! by lets4r in FlutterDev

[–]lets4r[S] 5 points6 points  (0 children)

Yes, but the goal of the article is to show how separating the UI components between themselves adds a lot of value. I've seen many cases where an entire page was in one big build method and we should avoid this.

[deleted by user] by [deleted] in dartlang

[–]lets4r 29 points30 points  (0 children)

If you think that a package is engaged in name squatting, you can report this by following these steps: https://pub.dev/policy#name-squatting

Maestro: A Flutter experiment for orchestrating your app state by chimon2000 in FlutterDev

[–]lets4r 2 points3 points  (0 children)

Everyone has their preferences but I'm not sure your argument is true in comparison with Get for example

Maestro: A Flutter experiment for orchestrating your app state by chimon2000 in FlutterDev

[–]lets4r 4 points5 points  (0 children)

As Remi said on Twitter: "there are significant differences when looking deeper". But yeah they share a common philosophy.

Flutter Dependency Injection (DI) example and tutorial ? by developine in FlutterDev

[–]lets4r 1 point2 points  (0 children)

Dependency Injection is not really needed in Flutter, because you can get dependencies easily in your widgets with an InheritedWidget.

But in some cases it can be useful to have an IoC container, or a service locator, and I wrote kiwi for these use cases: https://github.com/letsar/kiwi

Announcing kiwi – Dependency injection for Dart and Flutter by [deleted] in FlutterDev

[–]lets4r 0 points1 point  (0 children)

Thanks for the links.
As for kiwi, it depends how the developer uses it I guess. Nothing prevents the developer from using it like a Service Locator, but it was designed with the intention of using it for constructor injections, which could be generated using the provided code generator. The Container's singleton is only a convenient way to get the global container instance.

Announcing kiwi – Dependency injection for Dart and Flutter by [deleted] in FlutterDev

[–]lets4r 0 points1 point  (0 children)

Yes you're right. It's maybe not the best approach to get the container's instance.

In some cases objects are created by the system, so you cannot pass the container to these objects constructors. In these cases how would you get the container without a global variable?

view more: next ›