Category:

flutter

write tests or don't but read this
flutterprogrammingsoftware engineering

Write Tests or don’t, But read this – Flutter Testing

by easazade
written by easazade 7 minutes read

Writing tests can save you a lot of headaches. There are a lot of articles and youtube videos out there about why you should write tests. But have you ever wondered why many developers don’t write tests?

Ok, We’re not going to talk about what you’ll miss or what problems you’ll face if you don’t write tests. I think there is enough content about it out there. Instead, we will talk about the reasons why some developers do not write tests for their software, even though many admit that writing tests is a good practice.

How important is it?

Not writing tests is a serious issue. A lot of money is lost because of this issue in the software industry. Developers lose their credibility or even jobs because they didn’t write tests for the codes they delivered. There can be unsatisfied users. There can be lawsuits and legal troubles just because of a simple mistake or bug that could have been avoided by writing tests. So for sure, Not writing tests is an important issue and worth diving into to figure out why it happens.

I strongly believe if developers realize the issues not writing tests can lead to, many of the reasons that compelled them not to write tests won’t be strong enough to do that anymore. We will discuss some of the reasons behind this issue, So read on.

Not knowing the How

There are many developers that really don’t know how to write tests. They write them, But they don’t know how to write them. If you want to write flutter tests, you need to check out Flutter testing documentation. Flutter framework provides 3 ways of testing, unit test, widget test, and integration test. Each one has its pros and cons. I’d say the docs on Flutter testing are pretty good, But That doesn’t teach you how to write good tests.

Think about automated tests for a few seconds. You want to write code that tests another code’s behavior. Whether it behaves as expected or not. Let’s talk about it with a simple example. Let’s say you have a single unit (class, function, etc), and you want to make sure it works fine. You write 6 tests to cover different scenarios. Great, Now you want to make a small change in your unit, and suddenly all your tests show a syntax error. These tests are called broken tests. Now you have to go refactor the tests again. Here is the thing you need to know about how to write tests.

You need to write your code in a way so that your tests will break less often, and if they are broken, they take much less of your time to refactor them. If broken tests and refactoring them bother you, you’re probably doing something wrong.

So what is it that developers should know?

In short, when writing code, you should also think about how you should test it. It’s called writing testable code. You can try to improve the testability of your code by following the SOLID principle and writing your units as loosely coupled as possible. My suggestion to you would be to think about the testability of your software as you want to write it or Do TDD, for which you should write the test first and then implement the actual unit those unit tests are written for.

When you’re looking at testable software, it should be like a good car when you pop the hood. When you look under the hood, you see different parts connected together through wires and tubes. Even though these parts work together, they are not tightly coupled together. You can remove a part if you think there is a problem with it. Run some tests on it in isolation and find the problem and fix it. You don’t have to dismantle the whole car in order to replace a part or isolate it from other and test it. This is all possible because these parts and components are loosely coupled.

Not knowing the Why

If there are developers that don’t know how to write tests, then I would argue that there are definitely developers that don’t know why they should write them.

There are developers that truly don’t know why they should write tests. If you talk to them about writing tests, they agree and admit it is a good practice. And some of these developers even practice what they say. Yes, some developers write tests just because everyone else is doing it, and it is a good practice. And there are people that are very honest with themselves and think, if I see no reason to write tests, why should I write tests?

Not knowing why is not a good enough reason to forsake writing tests for good. While knowing why you should write that test is a must. (Well, I guess you should know why you’re doing what you’re doing in life as a general rule). But if there are many fellow developers out there doing something, you should at least figure out why they are doing that. If you figured out the reason and still don’t want to do it, that is respectable. There is a saying where I come from which says

Not Knowing isn’t a bad thing, But not asking is one

Not feeling the Why

This may sound like the above argument, but it isn’t. Sometimes developers know exactly what they should write tests, but they don’t. And it isn’t because of laziness or being irresponsible or anything. It’s just because they haven’t felt the pain of the issues it can cause. Some will feel those painful moments, like when you created a local database for your Flutter app and didn’t write tests for it, and it caused a series of annoying bugs that tortured you during the course of development. Or when you messed it up big time in your company and lost your credibility. Think about that moment when you wished you had written tests for your app. Or when you finally did write those tests, you wished you would have started writing tests sooner. The moment that made you feel the importance of WHY you should write tests.

Limitations of the framework or language

Sometimes the framework or stack we’re working with makes it hard for us to test the code we are writing in that framework/stack. In Flutter, if you’re writing unit tests and widget tests, it is very simple to do that. However, if you’re creating a plugin and you want to write tests for that, that can be somewhat challenging. If writing tests for your code is hard and challenging, it would be a compelling reason not to write those tests.

Not Knowing the When

There are projects where you want to write tests, but you don’t want to fully cover all units and scenarios. And that can be reasonable based on your software and its components and units. But there are parts of your software that, if it doesn’t behave as it is supposed to do (bug), Will cost you a lot. For example, if you’re creating a wallet feature for your user, that is when a feature needs to be fully tested both on the backend and front end. Because if bugs happen here, this is gonna cost you a lot. You may even get into legal problems.

Bad Experiences in the Past with writing tests

Sometimes in life, we have bad experiences in the past that will shape how we perceive things in our life and make decisions. Programming is not different. If in the past you didn’t know how to write tests, you probably had bad experiences with software testing. Hence in the future, you may avoid writing tests because you don’t find it helpful for your project, which will also slow you down.

Not realizing the damage it can cause

This is a very important one if you realize the damage it can cause to either the business/client or even to you. You can lose your credibility, or the business or client could lose their credibility, especially in this competitive market. Bugs, in the best-case scenario, will worsen User experience, which is still a bad thing. In worst-case scenarios, you could cause you’re company or client to lose users, money, resources, opportunities, stock shares, and so forth.

Your code is your reputation

Being lazy and irresponsible

I don’t see that I need to explain much here. If you care about the value of the code you deliver and how it may affect others and their lives or livelihood, you should write tests when needed.

Not given the opportunity

Ok, it’s not always the developers’ fault. Sometimes you’re going to work on legacy code or some software that has very low testability. Just because it was developed that way without any tests, and now in order to write tests for that software, you have to refactor and rewrite the whole thing. And sometimes, in these cases, companies, based on good/bad decisions, decide that the cost of dealing with bugs in production is less than refactoring the software. So they decide not to do anything about it. So the developers continue maintaining and developing the software without writing any tests.

your flutter state management makes no
dartflutterprogrammingsoftware engineering

This is why your flutter state management makes no sense – part 2

by easazade
written by easazade 9 minutes read

In part 1 of this series, we discussed how many of the problems we face in our flutter state management are actually from how we define our state And that these problems usually start when our state gets bigger and bigger. This section will discuss what issues will appear in our flutter state management when breaking a state into smaller ones.

Let’s continue where we left off

If you haven’t read part 1, make sure you go and read that part first.

In the last part, our example of a single page of an app evolved into something bigger. We started with a simple page, then in the course of 3 iterations of changes, the page became more complex, and so did the state management unit that populated the page. Below you can see our page.

Above, we have our user profile screen. A screen where the user’s profile image is shown and can be changed. There are also two lists of posts and pictures. And each time a new tag is selected from the tag section, posts, and images relevant to the selected tag will be loaded.

Below is the state class we use for our flutter state management unit (imagine Bloc, for example). It’s big and a mess.

class UserState {
  final UserProfile profile;
  final Tag selectedTag; // new property
  final List<Post> posts;
  final List<String> images; // new property
  final bool isLoading;
  final bool isLoadingAvatar;
  final bool isLoadingPosts; // new property
  final bool isLoadingImages; // new property
  final Error error;
  final Error postsError; // new property
  final Error imagesError; // new property

  UserState(...);
}

// tags shown in screen are read from profile.tags

Separating flutter state management units into multiple ones

Ok, we decided to fix the mess we made above, And one of the most common ways is to separate the state into smaller ones. which also means separating our logic into smaller units. If we are using Bloc, then we will have multiple blocs. Let’s see how it will turn out. 

class UserState {
  final UserProfile profile;
  final Tag selectedTag;
  final bool isLoading;
  final bool isLoadingAvatar;
  final Error error;


  UserState(...);
}

class UserPostsState{
  final List<Post> posts;
  final bool isLoading;
  final Error error;

  UserPostsState(...);
}

class UserImagesState{
  final List<String> images;
  final bool isLoading;
  final Error error;

  UserImagesState(...);
}

Was that a solution or just a new problem?

Was separating states and the logic that manipulates and manages that state into multiple classes fixed our problem? Or did we trade our problems for new ones? If you look at the code above, we fixed our problem. The problem was that we had a state object that, when someone would have looked at it, would have made no sense. It was hardly readable and understandable. But at what cost? Let’s see what problems we might have caused by separating our state like this.

Did it make sense to separate it logic-wise?

Ok, We separated the Bloc into multiple blocs because our state was big and unreadable. Ok, we solved the problem of readability. But if we look at our Bloc from the business logic perspective, did it make sense to break this Bloc into multiple blocs? In some cases, it might make sense, and in others, it doesn’t make sense to separate the state and the logic that manipulates that state into multiple units. This will introduce more complexity and can even make the code more unreadable in some other parts, like the UI or our test code. In that case, our first attempt to improve our blocs’ readability has decreased our code’s readability in other places.

Logic code is a mess

We have separated our state into three Blocs, UserBloc, UserPostsBloc, and UserImagesBloc. Even though our states are now separated, the logic that manages them still depends on other states. In our case, we need to know what tag is selected in UserBloc to fetch relevant posts and images from the backend server and update the UserPostsState and UserImagesState. So that makes our blocs tightly coupled.

We also need to write extra codes in our blocs so they can listen to each other. And if the dependency graph between them is complex and there is no way we can make it simpler, the communication between them will also be complex.

Wait, didn’t separating the state supposed to solve this mess? How did we get into a more considerable lot?!!!

Test code is a mess too

We have made three blocs out of one Bloc. If our entire app was going to be just one Bloc turned into three, we could have gotten away with it. But what if it was ten blocs separated into thirty blocs? Without a doubt, we need to write more tests. But it doesn’t end there. Since many of our blocs will depend on each other, we will want to have some tests that test them against each other. Testing how they react against each other. This second issue will result not only in more tests but also in more complex tests.

Also, tests are meant to be readable. If your colleague is reviewing your code and reading the tests you wrote to see how things are supposed to work, or a new developer joins the team, They will have difficulty reading those tests. Also, it will take more of their Time. And let’s mention that this would add to all the excuses developers use not to write tests.

Remember, we said the point we are referring to is that poorly defined states will waste development time. Well, Time being wasted will not be our only problem. Because when we change our states too often and too much, our tests will brake too often. And that will also cost development time, of course. But when tests brake too much and too often, At some point, developers will stop writing tests.

Our UI code is a mess too !!!?

The UI code needs to be updated as well. Because We need to build our UserProfilePage from three blocs instead of one, our UserProfilePage code will probably look like this.

class UserProfilePage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: ListView(
        children:[
          BlocBuilder<UserBloc, UserState>(
            builder: (context, state) => ProfileSection(...),
          ),
          BlocBuilder<UserPostsBloc, UserPostsState>(
            builder: (context, state) => PostsSection(...),
          ),
          BlocBuilder<UserImagesBloc, UserImagesState>(
            builder: (context, state) => ImagesSection(...),
          ),
        ],
      ),
    );
  }
}

In our example, the code will be as clean as above. It is clean. But could it have been a mess?

What if we needed to process data from all three states to get the data required to be shown on our screen? What would our code look like?

In the best-case scenario, that part of our code would have been like

// insde the build method of UserProfilePage
MultiBlocBuilder(
    blocs: [userBloc, userPostsBloc, userImagesBloc],
    builder: (context, states) {
        final userState = states.get<UserState>();
        final userPostsState = states.get<UserPostsState>();
        final userImagesState = states.get<UserImagesState>();
        
        final someData = _processData(userState, userPostsState, userImagesState);
        
        return SomeWidget(someData);
    }
),
.
.

In the worst-case scenario, that part of our code would have been like

// insde the build method of UserProfilePage
MultiBlocBuilder(
    blocs: [userBloc, userPostsBloc, userImagesBloc],
    builder: (context, states) {
        final userState = states.get<UserState>();
        final userPostsState = states.get<UserPostsState>();
        final userImagesState = states.get<UserImagesState>();
        
        if(userState.isDoingThis){
          return SomeWidget(
            child: Text('some text'),
          );
        }else if(userState.isDoingSomethingElse && userPostsState.isLoading){
          return SomeOtherWidget(
            child: Item(
              padding: const EdgeInsets.all(24),
              item: ...
              .
              .
            ),
          );
        }else if(userImagesState.hasError && userState.selectedTag != null){
          if(isThis){
            return ThisWidtet(
              padding: const EdgeInsets.all(24),
              item: ...
              .
              .
            );
            
          } else if(isThat){
            return ThatWidget(
              padding: const EdgeInsets.all(24),
              item: ...
              .
              .
            );
          } else{
            return SomethingDifferent(
              padding: const EdgeInsets.all(24),
              item: ...
              .
              .
            );
          }
        }
    }
),
.
.

Take a look at the above example. We have some complex logic code to process the data that must be shown on our page. This convoluted logic could have been encapsulated within our flutter state management if we had only one instead of three. This logic code leaks inside our UI simply because our states are defined poorly.

Move the logic out of the UI

One of the points of having a class (unit) to manage our state is to avoid writing logic code in our UI layer as much as possible. But in the above example, we are failing to do that. The solution to the above mess is simple. Move the logic code to another unit. We can move the code written above to one of our state management units that makes sense, but what if it doesn’t make sense to move the code to any of them ???

Ok, we know we don’t want our logic code mixed with our UI code, And we know that we can’t move them to any of the three blocs we defined above because it doesn’t make sense. So the only other options are either to leave the mess be or to create another bloc to process the data we need, and We build UserProfilePage from that Bloc. Let’s see the code for that Bloc. 

class UserProfileBloc extends Cubit<UserProfile> {
  CounterCubit(
    this.userBloc,
    this.userPostsBloc,
    this.userImagesBloc,
  ) : super(UserProfile()) {
  
    [userBloc, userPostsBloc, userImagesBloc].listenAll(state1, state2, state3) {
      // calcualte the new state and update state !!!
    }
  }
  
  final UserBloc userbloc;
  final UserPostsBloc userPostsBloc;
  final UserImagesBloc userImagesBloc;

}

Too many blocs in on page

We have removed our logic code from our UI code, But now we use four blocs in our page. If we could find a way to combine some of these blocs, it would have been much cleaner, hmm. Well, we just did that in UserProfileBloc. What if we could listen to our other three blocs in UserProfileBloc and process the state of those three blocs? Then we need UserPorifleBloc to build the UserProfilePage. Let’s update the state for UserProfileBloc first.

class UserProfileState {
  final UserProfile profile;
  final Tag selectedTag;
  final List<Post> posts;
  final List<String> images;
  final bool isLoading;
  final bool isLoadingAvatar;
  final bool isLoadingPosts;
  final bool isLoadingImages;
  final Error error;
  final Error postsError;
  final Error imagesError;

  UserProfileState(...);
}

Wait, What?!!! We are back at square one. You may think, Ok, there is no way I make this mistake. But many of us do. Because the codes we wrote above are not created in one day, It is developed over several iterations of changes during the development process.

Don’t miss the point

Separating the states is not always a wrong solution. The chances that you simultaneously hit all or none of the problems explained above are low. But when they appear in your project, they’re not going anywhere until you deal with them. Of course, if you put in enough time, you can figure out how to make it work and eliminate said problems while your logic code still makes sense. But should you? The point is you’re still wasting your time on something that shouldn’t require this much Time. Remember, in the software industry, wasting Time is wasting money.

your flutter state management makes no
dartflutterprogrammingsoftware engineering

This is why your flutter state management makes no sense – part 1

by easazade
written by easazade 7 minutes read

Flutter state management. Let’s talk about why sometimes you think something is wrong in your state management, But you can’t really tell what it is. Like those times when your state gets complex. And you can’t really find a way to make it more readable. You think to yourself; this code should be more clear. But you can’t really figure out how to make the code more clear in a way that it still makes sense.

State management patterns are the same

When it comes to flutter state management, there are many options out there. Riverpod, Bloc & Mobx are some of the popular ones out there. But we are not going to talk about any of them. Because they are not the problem. Of course, all of them have their pros and cons, But They all get the job done. And the job is to hold your state and notify the listeners whenever you change that state. The problem that we are talking about is the one that almost always exists no matter which Flutter state management library we use.

State Definition is the problem

So what is the problem if flutter state management solutions out there are not the problem? There might be other kinds of problems, But in this post, we are referring to the state definition problem. The way we define our state is the single cause for most of the problems we face in flutter state management. Let’s talk about it in an example.

This is something I have seen in a lot of projects. At first, we define a state management unit like Bloc, Store, or even a ChangeNotifier. It doesn’t matter which one we use because they are not our problem. So we have a small state with a few properties in it. Everything looks good and works fine. Then as we develop our flutter app, we start changing our state, adding more and more properties to it. Making it bigger and bigger. It’s not necessarily bad to have a big state unless it’s confusing and not readable. At this point, maybe it is wise to separate our state management unit into smaller state management units. Everything’s still fine. No problem.

Until it doesn’t make sense

But there are times when things just don’t make sense to you. I’m specifically talking about those times that you are sitting on your chair staring at your screen and thinking to yourself, “How should I change the state definition of my bloc (Store or anything else) so it can reflect the new piece of data I want to show on screen, WHILE the code, is still clean and readable”. I’m not saying that you won’t solve the problem.

In the best-case scenario, you will come up with a way to update the state definition while the code is still readable. In the worst-case scenario, you will update the state you defined, but the code is just bad. Either way, you have put time and energy into something that should not have required that much time and energy. And you’re most likely going to do that again when you’re updating that state definition again. Now that is just time and money wasted.

Now even though I have just started explaining the problem and have not exactly made you feel and realize the problem, you may be asking what exactly is wrong with the way we define our state. That is something I will tell you at the end of this series of posts. Right after, I have shown you many of the different problems caused by bad state definitions.

Let’s see the problem in code

We are going to see step by step what these problems are. And then, we are going to see how solutions that are usually used to solve these problems will introduce new problems. At the end, we are going to talk about the real reason why none of these solutions work.

Take a look at the images above. You can see 3 different states of a single screen. We have a user profile screen that shows the user’s avatar at the top and his/her posts below. image 2 shows how our screen looks when the app is getting data from the server. in image 3. We want to define a state management unit that populates data on this screen. Here is what the defined state for that state management unit would look like.

For the sake of not making this article long, we are keeping scenarios and code simple. We’re just gonna see the complexity of the defined state over iterations of change.

class UserState {
  final UserProfile profile;
  final List<Post> posts;
  final bool isLoading;
  final Error error;

  UserState(...);
}

We use profile and posts properties to show the data on the user profile screen. We use isLoading flag to determine if the screen is loading and if there was an error. This defined state will cover all our needs in the above screen for now. So everything is fine for now.

Let’s Add more things to our screen

Ok, we’ve developed and completed our screen and the state management unit used for it. After some time, the design of the user profile screen has been updated. And now, we need to implement the new design.

In image 4, we see that an edit button has been added to our design that allows editing profile images. and in image 5, we see that the user profile screen shows a loader indicator when a new image is being uploaded as the user’s avatar. Now let’s see how our code for our state object will change to implement a new design.

class UserState {
  final UserProfile profile;
  final List<Post> posts;
  final bool isLoading;
  final bool isLoadingAvatar; // new property
  final Error error;

  UserState(...);
}

We just added a new property isAvatarLoading flag, to show the loading on avatar image because we can’t use isLoading flag for that, of course. Everything’s still fine. you might look at the code, and it might annoy you just a tiny bit. But you just leave it at that.

Let’s Change the screen even more

We have a new design for our screen that we need to implement. This is a little bit more complex than the previous design. we load tags from the UserProfile object in our state on screen. Then each time a user selects a tag, the relevant posts and images for tags will be fetched from the server and shown on the screen. In image 7, we see that the shimmer effect is shown when we are fetching relevant posts and images for the selected tag. In image 8, we see that if there was an error during fetching posts and images for the selected tag screen shows a try again button.

Now let’s see how our code for our state object will change to implement the new design

class UserState {
  final UserProfile profile;
  final Tag selectedTag; // new property
  final List<Post> posts;
  final List<String> images; // new property
  final bool isLoading;
  final bool isLoadingAvatar;
  final bool isLoadingPosts; // new property
  final bool isLoadingImages; // new property
  final Error error;
  final Error postsError; // new property
  final Error imagesError; // new property

  UserState(...);
}

// tags shown in screen are read from profile.tags

At this moment, you’re gonna think. Ok, this is getting out of hand. Many of us will see the above code and think this code is really bad. And you come up with solutions like converting the state management unit (Bloc, for example) into multiple ones so you can separate the state and avoid this mess. Or some of us may think, let’s define the state using a Union or Sealed class. It may work in some situations, But they will introduce limitations and problems of their own.

Some of us may say I know how to fix this. But if we are still wasting a lot of time each time we want to change how our states are defined, I say that is not a solution to this problem; that is just a new problem. Creating problems after problems to be solved wastes a lot of time & energy that should have been put elsewhere.

In the next part, we will talk about…

Here we just talked about how states can be big and messy. In the next part, we will talk about how solutions that are used to solve this mess are just new problems.

Future of Flutter
flutter

Flutter will be more widespread than Javascript in the future

by easazade
written by easazade 5 minutes read

Flutter is a portable UI kit and a great one at that. I’m going to explain why Flutter will be much more widely used in the software industry than it is right now. Even more than Javascript.

Flutter is a portable UI kit and nothing else

Before we start Let’s get something out of the way. I’m not going to talk about Flutter web vs Javascript frameworks like React or Vue. This article is not about that at all. For what it’s worth I think Flutter has a long way to go to challenge something like React or Vue. Then what are we going to talk about?

It’s important that we understand what the purpose of Flutter is first. Of course we can create mobile, web and desktop apps with Flutter. But Flutter is not like other cross platform frameworks that only target mobile, web and desktop. Flutter is designed to be a UI kit that can render on any device that has a screen. And the solution that Flutter is using to achieve that is being a portable UI kit. A good example of this is what Toyota did. Toyota is using Flutter’s Embedder API to develop its infotainment systems ( which is the screen that is on your car dashboard ). This is something that other cross platform frameworks like react native cannot achieve.

It’s worth mentioning that other frameworks have never been as successful as Flutter in this aspect.

The Problem of native UI kits

Works only on one platform

The obvious problem of native UI kits is that it only works on its platform. A lot of effort goes into writing code and it works only on a single platform.

Can have its own limitations

Native Platforms can have their own limitations. Take Native Android UI kit for example. it is heavily fragmented. some ui elements work on some versions of it and some don’t. Or they don’t look or behave the same. Some elements like shadows don’t even exist in older versions of Android. It’s not only that. performance is also the problem here. UI kit for older Android versions are not as fast as Newer versions.

With Flutter it doesn’t matter how fast it is now because it will be faster in next versions. And when we update our flutter apps they will run faster as well on all devices.

It’s a complicated situation

It’s not just about the performance and the technical part. Let’s say some company creates a refrigerator that has some smart features in it. And it has a nice screen with a nice user interface which you can interact with. The company has written its own UI kit and also released an sdk which developers can use to define new features or change existing ones. Great!.

Smart devices can be costly for all parties involved. Manufacturers, customers and developers.

Now let’s talk about money. It’s gonna be much more expensive than normal refrigerators because of all the cool smart hardware and software they put in it. probably three times the cost of a normal refrigerator. Now many people won’t buy that refrigerator because a few extra features that make that device smart does not worth paying three times the amount of a normal refrigerator.

When it comes to third party developers they won’t learn the sdk to create new features for that refrigerator either. Because they should spend a lot of time first learning the SDK. And then creating features for a device that does not have a lot of users.

So manufacturers don’t even bother creating smart devices that no one wants to buy. customers don’t buy them and developers don’t write code for them.

Take Smart watches for example. Many people buy them but even with all the applications and cool features they have in them, many people still regret buying them. because they felt it wasn’t worth their money.

Complicated but important

You might be thinking why do we even want walking, talking refrigerators that are expensive. And the answer is we don’t. The important point is if there is a smart device that people think will provide them value considering the amount of money they’re paying for it, they will buy it. And if there are enough people thinking the same then there is a market for that smart device. If there is a market, companies will aim for that market and make that smart device.

Then where do the developers come into play? if developers there are enough users to develop for and profit from they will play. but if they don’t the story will be like windows phones. companies built them and people bought them. but not that much application was created for them compared to the competitors like iPhones and Android phones. so eventually people stopped buying them and companies stopped creating them.

If you look at it it’s like a giant wheel. all parties must be willing to push the wheel so it can spin.

Flutter is the best solution to one problem

If the problem is writing User interface code and running it on many devices that have a screen, then yes. Flutter is the best solution that we have right now. Thanks google. although there are other problems that need to be solved until we get to a future where creating smart devices is not that expensive anymore.

A Future where our smartphones and laptops are not the only smart devices that we really have a use for. A future where writing code for other smart devices other than smartphones and laptops is worth developers time.

come to the dart side and learn dart backend
dartdart backendflutter

Why as a Flutter Developer, you should come to the Dart Side? (Seriously) – Learn Dart Backend

by easazade
written by easazade 9 minutes read

In this article, we are going to talk about why Dart backend (The Dart Side) is important in the world of software development. And why Flutter Developers should take it more seriously.

Flutter has evolved so much after the first stable release of the framework in December 2018, but so has dart. Folks at Google are doing an excellent job developing Dart. Flutter has become the reason why the dart community has evolved so much in the past few years. So many features have been added to the language. Thanks to the googlers and the open-source community now we have a programming language that is constantly and carefully evolving.

What makes Dart backend interesting?

Being able to write both backend and frontend and frontend in one language is the reason why dart backend is interesting. This is the reason why many developers and software companies are using dart backend frameworks. Some teams even try to make their own dart backend framework.

Now you might be telling yourself “that is not a good enough reason to use dart for backend”. And I tell you, being able to create and deliver software using a single programming language, has (potentially) so many benefits that probably didn’t cross your mind. 

I’m going to explain later why doing things in one language can benefit developers and software companies (also businesses) so much.

It all comes down to profit

There is only one other language that is hugely used for front-end and that is JavaScript. which can be used for backend as well.

When Flutter came out everyone had their doubts about it. There were Developers having doubts about the framework saying it’s not gonna gain popularity, Or become as big as react native. Or that we are better off with native frameworks when it comes down to mobile. But Flutter compared to other frameworks introduced many advantages and benefits for its users, whether they are a software development company, a startup or a full grown business company. They could not just ignore benefits. Things like developing and delivering much faster, easily creating apps with complex UI elements and animations and great performance which greatly affects the user experience. These features of Flutter reduce the cost of creating and maintaining an app and also gives an advantage to whoever is using it over their competitors. 

Same is with Dart backend. Using a single language to create backend and frontend of a project just gives us so many benefits that we just cannot ignore. 

So right now it is not a matter of whether dart backend is going to get traction and be accepted by the community, it’s a matter of which dart backend solution or solutions are going to be accepted by the early adopters which will become the go to options for the majority of the community afterwards.

If you see companies like very good ventures create a dart backend framework of their own, it’s not because they just have the resources and manpower. It’s because it profits them.

Why Dart and not other languages?

Some may say. Ok cool, creating an entire project from back to front in a single language has so many benefits but why Dart and not other languages? Like Javascript. I think Javascript is a good option to compare with Dart when it comes to writing entire softwares using a single programming language.

With Javascript it is possible to use it as a programming language for the entire project. We can use Node.js, React & React-native to create any app that we want but should we do it? When it comes to front end web Javascript is the obvious choice, no argument there. Now about React-native, Do we really want to use react native for creating a mobile application in 2023 when we have Flutter?  (I don’t think so).

Dart has rich language features

Nodejs is great which enables us to run javascript in environments other than web browsers. We can use Nodejs and create a backend for our app. But When it comes to using Javascript in places other than front-end web when there are other languages as options, Javascript gets some negative points just because of some of the language’s limitations and issues. It just hasn’t evolved like other languages (some may say it doesn’t even have types). So It is possible to use Javascript for this purpose and it is being used out there but the language issues are always there.

Dart is more evolved than Javascript. That alone makes Dart a much more reliable language to be used for backend projects. This is probably why Javascript is not on top of the list when it comes to choosing a language for large scale backend projects. Though there are many factors to consider when it comes to choosing a language for a large-scale backend project, Just keep in mind if we compare ONLY Dart and Javascript language features, issues and limitations Dart is the obvious winner.

Here are some of the benefits of using a dart backend for Flutter projects

Faster Development and Delivery

When we use the dart backend alongside flutter which is basically the dart front-end. When all or some of the developers are working on both sides, they can apply changes much faster. make decisions quicker and with more precision. Obviously faster delivery is a result of that.

More developers on projects means faster development (for real)

Usually that is not the case. If you make a project crowded with developers things will go slower. But when you do dart backend along-side flutter. you can just assign developers a task and they will develop. Because they are not going to be blocked by front-end developers or back-end developers. Each developer can handle both back and front of the application.

Faster Delivery is essential to winning over your competitions

There has always been a problem of delivering the software in this industry. It doesn’t matter if it’s a big company with a lot of resources. bigger is even slower in most cases. in any business when you got a product most likely you got competitors. Now if your product is a software, faster delivery is really important to you. It doesn’t matter how good your product is if you can’t deliver as fast as competitors, you will lose the race. dart backend for flutter projects can give this edge to the project.

Less communication between the project management team and developers

When project managers need to communicate with a single (or a single type of) developer instead of two, they will spend less of their time on that project. This means they have more time to spend elsewhere.

Much less communication between Developers

There are so many things that require backend and frontend developers to communicate. We all know how much time can be wasted there. Sometimes even a single bug can take a lot of time. When developers use the same language for both frontend and backend, many of these communications that happen between two developers turn into thoughts of a single developer. a single developer that can write code for both backend and frontend. In most cases we don’t need to go ask a backend developer to fix a bug or change something or explain something that there is no document for. We just do it ourselves since we can do both dart backend and flutter.

Easier Resources Management for software companies

When most backend developers and frontend developers in a company use dart language, resource management is much easier. Developers will be assigned interchangeably to the frontend and backend of a project and between different projects. But it’s not just developers, When communication required to manage projects is decreased. there will be more time for other parties involved in that project as well. Time is an important resource.

Much easier to create quality software

Testing is much easier. Less people are involved in the project. Less code is required to be written to create things which means less code to maintain and debug. Especially with this approach we can write almost any test scenarios, even very complex ones. much more things can be automated. more codes can be auto generated. This can all result in less bugs and mistakes, so better quality.

So many things can be automated

When we don’t separate our application in two different languages there will be more room to automate tasks. If there was anything that we couldn’t automate before, simply because backend and frontend programming languages were different or we didn’t have any knowledge of what is going on in the backend of our program. Now we can simply do it.

Also so many codes can be automatically generated

When we write code for both backend and frontend in a single language there is a lot of time that we know and can predict how the code will be on the dart backend side of our program. When there is room to predict code there is always room for auto generated code.

A very good example of this is serverpod. Serverpod automatically generates your protocol and client-side code by analyzing your server. Calling a remote endpoint is as easy as making a local method call. All these codes are auto generated by serverpod. That is a huge amount of code generation and a lot of time saved.

Test your project in any scenario you like (literally)

before it was hard or impossible to write complex test scenarios because we should have written them in different programming languages. Using dart backend alongside flutter for our frontend app it is simple to write the most complex scenarios. Now it is possible to write code for both our dart backend application and our flutter application in a single test unit. Whether we should do it in our project or not is a different topic. But keep in mind that limitation is no longer there.

Less time wasted pending other tasks

Developers are doing dart backend and frontend. So there is no task assigned to a backend developer whom you need to wait for. You do it yourself.

Bug fixes can be faster

Sometimes there are bugs going back and forth between the frontend and backend. Sometimes bugs require frontend and backend developers to work together to fix that bug. rarely it’s unclear whether the bug is from frontend or backend. Bugs like this can happen in any project. Again when one developer can inspect both backend and frontend side of the project bugs like these will take much less effort and time to fix.

Developers have better understanding of what is going on the entire project

The reason things like openapi standard exist to act as a middleware language between backend and frontend is enough proof that there are programming problems that need to be solved by processing the data and code between two different languages. Where the backend and frontend languages are the same we don’t need a middleware language to figure out what is going on the other side. Note that openapi only specifies what is going on in the backend

This results in better decisions, faster development, faster and cheaper to fix issues, better product quality and so on.

Code reviews are much faster

Writing less code means reading less code when it’s time to review. it’s that simple. And if you use frameworks like Serverpod, most of the backend or client code will be generated, so there is no need to review it.

Less resources are needed to deliver a project

Developers and other people working on a project, time and money spent on a project are the main resources we use for a project. All the benefits and advantages of using Dart backend alongside Flutter for frontend will result in less resources consumed by projects.

More profit for the software companies

Of course, when companies need less resources to deliver a project there is always room for more profit.

Maintaining software projects costs less resources (much less)

Flutter projects that use a dart backend overall need less developers to maintain them. If the backend of our project would have been written in another language, We would have needed at least two developers to maintain it. But it’s not just that it reduces costs. Hiring and managing developers in a software company is not easy. When companies need to manage different kinds of developers that is even harder. If they are not careful in managing resources, it’s money out of their pockets.

Final words

Dart backend will gain traction and will be popular just like Flutter. Maybe not as fast as flutter but it will find its place in the backend community. Be one of the early adopters just like many did with Flutter.