This week we've had a very nice experience talking to a potential client who needs help for evaluating his junior Flutter developer: it is a time for him to get promoted to the more senior role but there is none in a team recently who are experienced in Flutter enough to review his code and make a conclusion, if he deserves to get this promotion or shall be learning and practicing more to get it.
And this brings light to a problem which seems to be pretty common: how you can get if the Flutter developer and the code he or she wrote is 'good' or 'bad'? To give some hints on this we're going to collect 'dos' and 'don'ts' of a Flutter development in this article. Stay tuned if you're interested on a topic, we plan to update it from time to time with more samples and cases. So, let's start with
Dos:
Good code sample #1: Use centralized method to initiate network calls: In this sample above we see single wrapping method to execute a call and process response from it. #2 Here also see the ‘debugPrint’ used to get the prints to the console only in a debug mode. Some nubies use direct print method which bring a lot of a trash into production build output as well.
Sample #3: Use the interface and not the class name to address services methods: Sample #4: Use keys to address the widget to update to when you need rebuild only it and not the whole widget tree: Introduce a key in a widget’s state: And when widget created do it with the key: Access to methods or fields of this particular widget done like
Sample #5: Use properties and listeners to their changes to react on updates: Classes extending PropertyChangeNotifier Instance of this class in helper class: And finally it’s usage in UI widget: Here we also can find the good sample #6: usage of a null-aware ?? operator which gives a default value '' to the _avatarUrl variable in case of NetworkHelper.user.avatarUrl is null.
and now let's mention some
Donts:
Sample #1: Use forced delay working with async calls to ‘ensure call is executed’:
Sample #2: No unit and UI tests introduced to the project is definitely an indication of a low coding skills or a lack of an attitude.