Framework – IMG.LY Blog

How To Resize Images in Flutter

Natalia — Tue, 27 Sep 2022 15:03:53 GMT

Static images are a core part of mobile applications. Usually, you store them in the directory in their original sizes, which requires you to adjust the sizes now and then, depending on where they are displayed. This article discusses how to resize images in Flutter and adjust their width, height, and size with efficient lines of code.

Resizing Methods

For image editing tools, Flutter offers an excellent and easy-in-use Boxfit property that works within the fit parameter, and you can easily integrate it into your application.

child: Image.asset( 'images/pexels.jpg', fit: BoxFit.cover)

Depending on your needs, you can choose between multiple attributes. For example, .cover and .fitHeight properties are similar when called, and both result in maximum frame coverage. Yet, although the image is widened proportionally, these methods can significantly affect the quality of crop image borders if they overfill. On the contrary, with .fitWidth or .scaledown, the asset is resized to the container’s width boundaries, which could be helpful when multiple images are needed to be displayed simultaneously. If you are dealing with a static image of small size, you can also employ .fill attribute that helps stretch your assets without cropping any critical information.

Alternatively, by calling .scale 0.5 the fit parameter will return you a graphical asset based on the scale you define. Note that any value less than 1 would reduce the image size.

Adjusting Image Size with Flutter

Now, let’s look at how Flutter allows applying these image manipulation techniques. The crucial difference from the other frameworks is that in Flutter, images should be stored in a specific folder. In other words, once you upload graphic files, go to the pubspec.yaml file and add the path to the directory around under assets(Note: by default the dependencies corresponding to ****assetsare usually placed around 45-46th lines in the code and need to be uncommented first by eliminating # and one space).

# Don't forget to define the assets folder in your directory
# To do so, find lines 45 - 46 in the **pubspec.yaml** file
# and uncomment the assets section like this:
assets:
  - images/ #Note that this should correspond to the name of your folder

Alternatively, you can specify the path to each image in the list:

assets:
  - assets/images/your_image.jpg
  - assets/images/your_image2.jpg

When the image is uploaded to Flutter, it seeks to occupy as much size as possible. But let’s presume that we have a “frame” or container that differs in size from the visual asset. One way to see the differences in sizes of both canvases is to color one frame, like color: Colors.indigo. Then we provide Flutter with the size specification and render our image in a child node child: Image.asset(‘images/pexels.jpg’). Thus, now we can see the image is placed inside the frame, and we need only to assign one of the filling methods (for example, fit: BoxFit.cover) discussed above.

import 'package:flutter/cupertino.dart';
import 'package:flutter/material.dart';

void main() {
  runApp(const ImgApp());
}

class ImgApp extends StatelessWidget {
  const ImgApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      debugShowCheckedModeBanner: false,
      home: const ResizePage(),
    );
  }
}

class ResizePage extends StatelessWidget {
  const ResizePage({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
        appBar: AppBar(
          title: Text('How to Resize Images'),
          backgroundColor: Color(0xffe55586),
        ),

        body: Center(
            // Enabling the Image Frame
            child: Container(
                color: Colors.indigo, // To see the difference between the image's original size and the frame
                height: 550,
                width: 300,

                // Uploading the Image from Assets
                child: Image.asset(
                  'images/pexels.jpg',

                  // Resizing the Image to the Frame Size
                  fit: BoxFit.cover,
                ))));
  }
}

You can find the associated to this tutorial Git repository ― here. Otherwise, run the following command to clone the complete code to your system:

git clone <https://github.com/nataliakzm/Resizing_Images_with_Flutter>

Conclusion

This article covered Flutter’s approach to the image resizing problem and saw how to use it in practice. However, despite the diversity of suggested methods that could fulfill basic users’ needs, Flutter fails to provide a comfortable integration. Just imagine you are building an app similar to Instagram in its functionality and you need not only upload various images from different assets but also resize them differently. If you want to avoid spending your time writing and maintaining a ton of code, then you may consider using PhotoEditor SDK in your next project.

PhotoEditor SDK is available for various frameworks: first, read this article from the official documentation to set up dependencies for your Flutter-based project. You can also follow our guide on how to integrate video editor for Flutter into your app.

In case you encounter any difficulties with the installation process, don’t hesitate to contact our support who will be happy to help you. Then, as shown in the example below, you can efficiently resize, crop, rotate or flip your visual assets with the transform tool.

Build or Buy?

Daniel — Thu, 02 Nov 2017 00:00:00 GMT

For many years, we at IMG.LY and our partners at 9elements have been developing various applications for customers and ourselves. Often, we had to decide whether to build everything from scratch or to consider third party components. Sounds familiar?

As developers, makers and tinkerers we often tend to build everything ourselves. It seems to be in our nature and part of who we are. Truth be told, this is the point where we often got irrational.

Taking a good look at modern application development, we quickly realize that everything is getting more complex in a tremendous pace. While it was feasible to develop apps without any third party libraries back then, it has become more or less of a standard to employ third party libraries or tools that solve certain problems for us. Nowadays, there are a lot of features that are must haves and simply expected to be in your product.

Thus, we are more aware than ever when it comes to the decision whether to build or buy.

Decisions

Most often, our resources are not endless. With limited time, money, and labour power we always struggle to make the decision whether to build a certain component of our software ourselves or buy it from a third-party.

But why do we struggle? Are we sure we can do it better than everybody else? Are we not trusting the third-party? Do we just think it is cheaper to do it ourselves? Or, do we just underestimate the amount of work that is required to build that one component?

Most certainly we know that software, even a small app, can be a complex beast that is comprised out of a lot of components. Even more surely, our idea or product should stand out of the masses. So, should we really spend too much time building a component or rather focus on getting things done efficiently? How do we set the priorities?

Priorities

Probably, we want to focus on the things that set our product apart from all others, may it be a singular specific feature or a novel combination of already existing ones.

Surely, most of us will never consider writing their own relational database like PostgreSQL. But, what about features such as payment, authentication or a content management system?

Speaking from experience, most of us won’t even think about implementing payment themselves and eventually, we will use a popular SaaS such as Stripe. But, what about authentication? Would we build that ourselves?

Thinking about all the details that you need to account for when building an authentication system, it becomes obvious that more is needed than just providing a simple registration with username and password. Depending on the software we are developing, people might expect to be able to login with their social logins via e.g. Facebook or GitHub. Also, we would need to provide a way to reset passwords, send emails on registration and so on. Over time, the list of requirements will grow and we will be forced to spend our precious resources on it, whether we want it or not.

So, why not just let someone else do the job for you and solve all these problems?

Don’t we trust services like Auth0 to solve all these problems for us, or what is the reason we build those things ourselves? Evidently, if our product is an authentication system we should build it ourselves. But, let’s be honest, most of the time it is just something we need for our product and nothing we care about deeply.

Unfortunately, we know that everything comes at a price. In case of Auth0, the login data may not be any more in our possession. However, are we sure that it is really bad? We tell ourselves that we can protect our data in a way that no one else would have access, no data would be leaked and so on. At least, that is what we would be thinking, right? But, are we sure that we can protect the data better than the service whose one and only task is to care about exactly that? And what about backups? Do we really want to put our resources into creating and checking that our data is properly backed up and restorable in case of a server failure? Probably we won’t and in many cases it would be a good idea to let someone do the job who does it on a day to day basis. Being completely honest with ourselves, we realized that:

By zeroing in on one specific problem, we can build better and more advanced tools than we could by trying to solve multiple problems at once.

We experienced first hand how much time and effort is required to tackle one specific problem when we needed a photo editing solution as part of one of our projects. In that particular case, we needed to go down the rabbit hole and build it ourselves. Back then, we didn’t have any other option as there was no component available that we could have used.

Was it a good idea? Probably not for the project but while building the components we realized that others could benefit from our learnings. This is basically why we started building and advancing our PhotoEditor SDK.

Apart from the previous mentioned pros and cons about building and buying, there is also another important factor: These services cost money and most of us will look at the pricing and believe it may be too expensive. Especially, if you have to take out your credit card and start a subscription that may feel like slowly draining your bank account. Even more so if you’re a small business or startup and every additional expense poses a threat to your project as a whole. However, this is the time to really weigh your options.

Time is Money

We always hear and rephrase the good old time is money slogan. And this is true in many ways. Even if we don’t care much about the cost of our own time, we would still have to invest it to build said feature and by that might delay the whole product. Do we really want to spend that time and delay our whole product?

Ok, assuming we don’t do it ourselves and we have a team of developers and parallelize our efforts, we still need to pay for it with, and let’s be honest … money.

According to PayScale the average salary of a software developer is around 45k€ in Germany. Considering that we work around 220 days per year, each day would at least cost us approximately 200€, but to be fair it will surely be more. Depending on the software component you are considering to build or the SaaS we consider to use, we most surely would get a lot more for our 200€ than what we could build in one day. And, if we are honest, 200€ are definitely not enough to develop any feature that requires more than just a few lines of code.

Final words

Summing it up, we should definitely not just buy every component from a third party or subscribe to every SaaS, but we should weigh carefully in which cases we really have to build it ourselves or when buying is the better option.

The whole point is that whether you buy some of your components or build everything yourself really doesn’t matter as long as it’s the smartest decision for your business. And if you automatically shy away from solutions that cost you something and decide to build it yourself no matter what, that decision might cost you a whole lot more.

The good thing is, that there is a trend that third parties tend to focus on more granular problems, which allows us to make the distinct decision whether to build or buy a specific component of our application.

Thanks for reading! To stay in the loop, subscribe to our Newsletter.