DEV Community: Carl Wills

5 things to do when NOT writing code...

Carl Wills — Thu, 17 Jun 2021 21:38:24 +0000

As programmers, we love to code! That's what we do, and it's a big part of our lives. But it's not all that we do, and it's not all that we should do as coders. Here are five things that I think everybody that writes code should do when they are not coding to keep themselves sharp and to continue learning.

1. Talk about code

Yes! Talk about code, frameworks, libraries, algorithms, anything that helps you learn more about what you are working on. I think as programmers we often get caught up in the typing of code and lose our skills in other ways to communicate about it. One of the most important skills in our toolset is being able to communicate and explain technology, code, or high level strategy that we are using when solving complex problems. Talking about code helps enforce these skills and even helps us figure out which topics we need to brush up on.

2. Look at code other people wrote

There's soooo many benefits to reading other people's code. Everybody has small little intricate differences when they write code that can be fun to explore and enhance your understanding of how the language works. You might notice some cool new functions you've never noticed before. You may stumble on a pattern that they use that you could easily implement into your project to make it cleaner or more simple. You may even find some mistakes! Reading code other people wrote is a great exercise in checking your level of understanding. It's not easy to jump into a new repository and start understanding what's going on, but by taking some time to explore unknown territory, you'll pick up on a lot!

3. Read

Read a book, I dare you! You might even enjoy it! Many programmers enjoy doing what they do because it is a very focused, heavy brain-power job. If that's you, or if you simply like a good story pick up a book and give it a read. You'll find that doing a quiet solitary task can be really refreshing, especially with all the video calls we are all on constantly.

4. Pick up a hobby

Programmers are, in general, great problem solvers. That means that they are naturally clever, creative people. Pick up a hobby that helps get that creativity out! This can be anything from learning a musical instrument, to going out and geocaching. Finding a hobby that you love can be a great way to redirect your focus away from your code and simply let your brain rest. I've met a number of people that then take those hobbies and combine them. Some examples could be writing an app that records music, making a website for your biking club, or even creating a database to keep track of your board game win/loss record with your friends!

5. Take a break

Simply taking a break can often be the best thing you can do to keep your energy levels up, stay focused and avoid short term burnout. Personally for me, I love going on walks throughout the day. It get's my body moving and physically away from my desk creating some separation from my work. Maybe for you, reading a chapter in a book might be the best way to relax. Other's might even rather sit back and watch an episode of their favorite show. Breaks are great for hitting the "Brain Reset" button and often times when you get back to coding you can approach it from a different prospective, which can be especially useful when tracking down pesky bugs!

What do you do to stay sharp and focused when you aren't coding? Let me know in the comments!

Thanks,
Carl

Why video tutorials should NOT replace reading documentation

Carl Wills — Tue, 15 Jun 2021 14:02:23 +0000

As more and more people start their programming journey, I'm finding that the number of video tutorials are increasing. That shouldn't be a surprise to anyone. Of course people will be making video tutorials showing off the basics of a cool new language, package, or feature. Heck, I might even start making video tutorials. But I'm also finding that more and more learners are solely depending on video tutorials when they start learning something new.

Now, I don't think that video tutorials are bad. I've learned a lot of really good things from them myself. But I'm always amazed at the lack of awareness, by new programmers, that written documentation even exists for whatever they are trying to use.

I use Flutter a lot in my free time, so I'll use it as an example here. Flutter has awesome documentation. Here's an example from the Color class

Being able to read and understand this form of documentation is invaluable as you progress on your development journey. In it you'll find useful constructors, parameter descriptions and even common examples!

There will be many times that all you have to learn from is a set of documentation, and being able to quickly reference it and understand the basics will help you iterate quickly, stand out in the company that you're at, and can even help you be more productive.

Now all of that being said, I want to reiterate that I think video tutorials are good! But I don't think that they replace being able to read and understand documentation. A healthy balance of both is what's needed to really thrive and grow as a developer these days.

If you're just learning your first language, or your fifth, I'd recommend taking a look through the documentation to see what you can find! You might be surprised by the little gems that are hidden away in there!

What do you think? Am I being too harsh? Let me know in the comments if you read through documentation before starting a new project, or if you jump right into video tutorials!

Thanks for reading,
Carl

Flutter Package Preview: shared_preferences

Carl Wills — Sat, 12 Jun 2021 15:15:00 +0000

Welcome to my new series of helpful preview articles, "Flutter Package Preview" where I talk about different packages on pub.dev and how to use them!

For the first entry in this series, I'm excited to introduce shared_preferences!

I always recommend reading through the pub.dev page of any new package before using it, so here's where you can find shared_preferences.

What is shared_preferences

shared_preferences is a package that helps streamline storing persistent data in a users, you guessed it, Shared Preferences! Each device type stores simple data in different ways. On iOS and macOS devices, this simple data is stored in what they call NSUserDefaults. On Android and other platforms, it's stored in what they call SharedPreferences.

This data can be any of the following data types: int, bool, double, String, or List. It also persists between device or app restarts! So your user doesn't have to configure the app every time they open it!

How to include shared_preferences in your project

So you want to use this package in your project?! Awesome! Either run flutter pub add shared_preferences in your terminal or simply add this statement to your pubspec.yaml file.

dependencies:
  shared_preferences: ^2.0.6

How to use it in practice

First, you'll need to include the import statement at the top of whichever class you'd like to use it in.
import 'package:shared_preferences/shared_preferences.dart';

Great! Now before you can save or fetch any data from the persistent storage you need to get an instance of the SharedPreferences object.

    SharedPreferences prefs = await SharedPreferences.getInstance();

You'll notice that this uses the await keyword. This means that getting an instance of SharedPreferences is asynchronous and requires a little extra setup. You'll either need to use a FutureBuilder widget, or simply wrap it in an asynchronous function by using the async keyword, like I've done here:

void setUserNamePref() async {
    SharedPreferences prefs = await SharedPreferences.getInstance();
  }

Although I do not do this in this example. I'd recommend trying to limit the number of times you get an instance of Shared Preferences. That way you can reduce the number of asynchronous calls you make. Separating getting an instance, and using the instance would also be a good idea.

Writing data to persistent storage

Now we are ready to read or write to our preferences! Let's start by writing to our preferences. Since we've done so much setup, writing is easy:

void setUserNamePref(String userName) async {
    SharedPreferences prefs = await SharedPreferences.getInstance();
    prefs.setString('userName', userName);
  }

The new code here is prefs.setString('userName', userName);
Our SharedPreferences object has a number of different set methods. One for each of the supported data types! Make sure when you are using these set methods that you choose the right one for your use case. In this example, userName is a String so I can use prefs.setString.

Reading from persistent storage

Now that we have data in storage, let's read it! By slightly modifying the example we've been working with, I can achieve this pretty easily:

Future<String> getUserNamePref() async {
    SharedPreferences prefs = await SharedPreferences.getInstance();
    prefs.getString('userName');
  }

Again in this example, we are dealing with asynchronous functions so we need to return a Future and mark our function definition with async.

Yay! We're done, right?
Well, not quite, there's one more important thing to think about when getting a shared preference. What if userName doesn't exist yet? What if we've never stored a userName for this user before, and now we try to access it?

Well we can protect ourselves against this by using some of the new null safety features. See this example:

Future<String> getUserNamePref() async {
    SharedPreferences prefs = await SharedPreferences.getInstance();
    return prefs.getString('userName') ?? 'Carl';
  }

If the key 'userName' doesn't exist, we can instead return the String 'Carl' so that the program can proceed!

Wrap up

Using shared_preferences can be really powerful. You can use it to store data about the app settings, like whether the user has selected to use dark mode. Also, since it supports storing Strings, you can serialize your dart objects into JSON and store them! Then when you want to use them you can deserialize them back into their objects! There are so many different ways to use shared preferences, that it's a really flexible way to store simple user data in a fast efficient way.

Thanks so much for getting this far! Hopefully you've enjoyed this brief look into the shared_preferences package! Make sure to follow if you're interested in more Flutter Package Previews!

Carl

Simplify your Flutter app with Provider

Carl Wills — Fri, 11 Jun 2021 11:50:39 +0000

You may be aware of statefull and stateless widgets in flutter, but what if you want to share data between multiple different widgets in your app? You could pass the data between the widgets, but if you're creating something responsive that will change based on screen size, for example, you may need to structure your UI differently based on screen size or rotation. It becomes really tricky to manage the state of your application by passing that data to and from your widgets. Instead, I'd propose that you think about including a system of state management!

What is State Management anyway?

State management is the process to keep and share data across different components. It allows you to store data pertaining to the state of your application, and retrieve that data from anywhere else without needing to pass it around! You could say it helps you manage your state!

Okay, so what is Provider?

Provider is a package that helps with state management! In short, it inserts a widget into your widget tree that holds values of state for your app. Because of this, any children to that Provider widget can access that state because it exists within the same widget tree!

How do I start working with Provider?

Just like with any package, it's a good idea to read through the documentation on pub.dev before continuing. Here's the link to the provider: https://pub.dev/packages/provider

Okay, so you've read the documentation, right?
Now we can import it into our project, simply include this in your pubspec.yaml file:



dependencies:
  provider: ^5.0.0

Now that you've imported the package we need start using it. To create the Provider into the widget tree you need to first identify the best spot in the widget tree (often right at the top level for small projects) and then create a Provider widget. Here's an example where I've decided to wrap my entire app in a Provider I've called MyProvider



void main() {
  runApp(ChangeNotifierProvider(
    create: (_) => MyProvider(),
     child: MyApp()));
}

class MyProvider extends ChangeNotifier {
  int counter = 0;

  void increment() {
    counter++;
    notifyListeners();
  }

  void decrement() {
    counter--;
    notifyListeners();
  }
}

So, how do we access this and update it?

It's easy! There are a few different ways to interact with your provider. If you are trying to access or modify state from outside of a StatelessWidget.build or State.build method you must access it like this:



Provider.of<MyProvider>(context).increment();

If you are trying to access state within the build function, you can use this example:



context.watch<MyProvider>().counter;

There's something really interesting about these two functions. They will trigger an update to the UI! By calling notifyListeners() at the end of the increment and decrement functions, we're telling the UI that it's state has changed and it should rebuild!

There's a few other ways to read state from provider that I'd like to touch on:



context.select((MyProvider myProvider) => myProvider.counter);

The Provider Select/Selector functionality is really powerful! It causes your widget to only watch for changes to a specific member of the state, instead of the whole state entity. This becomes really useful if you have multiple different variables you're trying to keep state in, but you only want your widget to care about a single one of them!



Selector<MyProvider, int>(
        builder: (context, data, child) {
          return Text("$data");
        },
        selector: (_, myProvider) => myProvider.counter,
      ),

That's right! If you're building this directly in the build function and have widgets dependent on this data, you can create the appropriate Widgets that are equivalent to the context statements above! In this case I decided to make an example for the Selector widget.

Lastly, if you're debugging, you can see the values of all of your providers in Flutter DevTools!

I also want to mention that there's a newer state management package out the called Riverpod. It's thought of as "Provider 2.0" by many and offers some awesome improvements. I'll be writing about Riverpod soon!

I hope this quick run-through of the provider package and a few of its uses was helpful to you! I am not an expert at this, but knowledge sharing is always good and it's how we learn together.

Thanks!
Carl