Flutter Dimple

Yes, hello. So I'm a Flutter engineer with over 6 years of experience overall. I started my journey with Android development as a native developer. I was using Kotlin back then. And my first application was developing a hospital management system. And then as my company acquired, I shifted to Flutter development. And since Flutter, I've worked there for more than four and a half years. I worked with medium to large-scale applications to higher-level complex applications as well. Some of the domains I can mention include social media, lifestyle, and home care domains. I have worked with B2B and B2C applications as well and have performed cycles on features like billing, notifying, and purchasing, etcetera. My recent project was a stock marketing application for US Securities, if you know some stock exchange mediums for India. So we developed an application for them. And yes, it has technical features like over 1,000 screens in that. We have 4 or 5 backend major things to implement that are coming from different domains and APIs, so we managed the application as a state management with TDD architecture very well. And we can say that it is performing well in the market. And its user base is coming in at over 1 million users. So, yeah, it can be considered a great level of complexity and a good scalable application as well. So that was about me. And other than that, my hobbies are traveling, walking on the beach, and visiting hidden gems often. So that's about me. Thanks.

Yes. So I can follow some things. We can mainly focus on network calls, like caching the data wherever is required, pagination, chunking, and data compression. And more than that, we can utilize data formats. And optimizing image loading is mandatory when we are loading the list that has image operations and all. So let's focus on the first module. Like, there is a cash management. For that implementation, the mechanism to store frequently accessed data locally on the device is required. And so we can reduce the redundant network requests. And that way, we can improve the responsiveness of the features that the user cannot totally rely on the connection, that can be loaded with cache and all. So we are having this package in the plugin library, Flutter cache manager. I have used it later. I will go with that for this particular process as well. So I can send the cache with expiry time and the strategies for handling state data. Next, the major thing I need to focus on there is pagination and chunking. So if you are dealing with a very large database, then we can have collaboration with the API developer, and we can get data by pages. So that can be useful while reducing the initial page loading time and where our performance is improved and lazy loading is possible as well. So, yeah, that can be helpful for handling this large payload. Next can be data compression. So we can use the compression techniques available for Flutter. So we can reduce the payload size that we are transmitting over the network. So I can think of one or two libraries, like HTTP auth and HTTP interceptor, that can help us to compress the data. And we can have a good trade-off between the API and our user interface. Other than that, we need to optimize the large images. For that, I know this library that is called cache network image so that we can compress the images and the image as well by using other techniques. So that way, we can optimize our data, and we can reduce the network requests as well. So, yeah, this is my overall approach for optimizing Flutter app's network requests when dealing with the large payload in complex levels of application. Yeah.

Yeah. Let's see that having this experience by building in many applications, I have observed these things that can cause bottlenecks in Flutter applications. Like, it may crash the application or reduce the performance or the user gets stuck on a screen or something. And these bottlenecks are unnecessary widget rebuilds. While we are designing the Flutter application's UI, we can see that the build method of the Flutter widget is running at 60 frames per second. So if we are not using constant keywords or some proper inherited widgets provider, and there is one property that should rebuild the method is there. So if we are not utilizing these properly, then we can see unnecessary widget rebuilds in our code, and it may affect the performance. If there is some infinite list also, then it may get stuck and the code can be done in an infinite state. So that way, the user gets stuck on some screen, and it may also crash the application, like, for building the UI the wrong way. Other than that, let's come to the network part. If we are not calling the network calls in an efficient way, then we may face some problems when we are fetching some large amounts of data. So for that, we can use the Flutter cache manager. That is some third-party API, and we can install it in our pubspec file. And other than that, we can use the HTTP, network management strategies for using HTTP auth and HTTP interceptor. Other than that, we can use the profiling tab that is in the Flutter Dev Tools, and that gives us the janks that are happening in our UI while scrolling through the list or some big complex screen or some complex network calls are happening, like, subsequently, or there is some big complex mathematical equation to be calculated. So that way, there could be some bottlenecks. But those all are preventable if we are following all the good practices of data development, and we are following the principles. So it's about resolving bottlenecks and preventing them.

Yes, so there can be some cases when we need to handle our synchronous data flow, and we need to call the APIs in an asynchronous manner. So as we know, the cutting block is excellent at managing asynchronous data, and it provides clear separation of concerns between UI, like, we have this presentation layer in TVD architecture, and we have this business logic layer in block. That block layer in business logic is there. So, how can we do it? Like, we can follow some typical steps that are given in the documentation of block. Let's say that we are having this event that is calling us in Jonas operation. So we can put an on-tap in the widgets, and that event can be dispatched from that event step, and we can call the relevant block. Like, the relevant block is matching that event to the state. So, the second step can be the block is processing the events. We are triggering this event of an asynchronous call, and it will map this event to the state. Now we have to perform some operation that we need to do, and then we can emit the state that is relevant. Like, some if it is not successful, then we can emit the error state. Or else, if it is successful, then we can give the relevant data that has been requested. And after that, we are using the which is given by block package that are block consumer, block provider. And that way, we are updating our UI based on the state that we have received from the block itself while we were emitting the state and triggering the events. So these are the key concepts to be used in our block applications, our synchronous data flow. So, let me provide it, like, we can use events. Events can be triggered by widgets, and then it is going to block is mapping the event. Next, we are emitting some state that is relevant, failure or success, and then we are listening to that state and updating our UI as our user's request or widget click. Yeah. So that was about handling asynchronous data flow in Flutter application with Flutterblock.

Yeah. So Flutter is giving us this opportunity, like, this facility to adapt on multiple screens. As we know that Flutter is supporting multiple platforms like, Google Chrome, web development, both mobile platforms, iOS and Android, as well as Ubuntu, Linux, and Windows application, Mac application as well. So it is mandatory that our UI adapts to the screen. As we know that all the different let's take an example that Android and iOS. Both platforms have the fab button, floating action button. In both, they have different properties as iOS is following their own design facilities and all. And our Android is following its material design. So that way, we need to adapt to the screen and design as well. Whenever we are listing some UI widgets that are tile or something, then it should follow the design, the material strategies of that specific platform. So for that, we are having this property. Like, we are using list tile. Then we can build it with the constructor that is list tile dot adaptive, and then we can move it further. Other than that, we can leverage the facility of responsive widgets. We are having row, column, stack, and other than that flex, grid view, all things are there. Flexible widget, expandable widget is there. And if we need to check the size of the screen and all, then we can use media query, that is inherited widget given by Flutter itself. We can determine the screen's width, height, and that way we can move further with our designs. We can use expanded flexible. We can give flex property to them. And that way, our UI can be adapted to, like, responsive to different sizes of screens. If we are building, forcing single code base. We are building for web and mobile as well. Then we can use breakpoints that are specific to screen width or the sizes. So that way, if we can see that, if you're having menu in web application, it is laid out in a horizontal manner as per the web applications requirement. And when we are coming to the mobile application, then we are having this hamburger menu with 3 lines, and then we can click on it. So for adapting this design, we can use a point. If screen is getting lesser than 420 pixels, then let's say that we are showing b design. It is bigger than that we are showing a design. So that way, other than that, like, we are having relatively out in Android system. We have a layout builder and dynamic, for creating dynamic layouts in our Flutter application. So it is providing us constraints, like available space and size, height with constraint dot, max width we can get and all. And with that, we can build our UI. So, yeah, these are the widgets given by Flutter only. And if we are not going with these native widgets from Flutter, we can go with the package that is Flutter's screen utility. It is giving us some easy things to do. Yeah. So that was about having multiple screen sizes and orientation adapting to them.

Yes. So there are different approaches. We can use a provider that is used with a change notifier or report that is also approachable. Benefits of using a provider is, like, it is well documented and easy to learn for developers. And it is offering us simplicity and, like, a good balance of flexibility as well. And change notifier. I can see this. That can be the straightforward way forward to manage state and notify the changes to the widgets and all. And there is also that. It is inspired by provider only, and it is also offering us some more concise and streamlined syntax for state management. And, like, if you need to integrate local persistence, solutions like shared references or high, that can also be done with Riverport and provider. Disadvantages of using this approach, I can tell that, it can become very complex or hard to handle for large levels of application if it has complex state management. And, also, we need to implement a lot of boilerplate code. So it takes a little more time at the development side. My favorite one is block. I can say block is my favorite approach for, like, using this interaction of data patching and local file systems. If we are having block, then this will be the advantages. Like, it has one-directional data flow. So we can say that it is predictable and testable code. If we are using some complex levels of state management, then it is really well suited. And, like, as we know, it has asynchronous operating operations and all. And it can handle integration easily. And, we can say that it's having a disadvantage is having a steeper learning curve compared to provider. You will have to get, like, fond of it, and then it can be easier. And, if we are using this approach for large very small levels of application, then it can be an overkill for that. So we can go for medium scale and large scale levels of application. And if, let's say, and if we need to choose the right approach, then we have to focus on these core modules of the application. That is if we are having complex levels of modules or not, if our team knows that or not, or more than that, when our application is going on a bigger level, it can be scalable and it can go globe stage or not. So that we can do. And, these local persistence and testing can be done. And this is the way we can evaluate projects, the specific needs and team's preference, and then we can select the better and best way.

Yes. So I can see that here there is a possibility that there can be three states for general applications. First, when we are loading data, whether it is in a lower initial state or not, then there will be a state record like a "loading" or something that we can mark it as well. If we are then we need to check whether it is successful or some error. So there are three states. The loading state is a loading state. Another will be a successful state. And then also we can check whether there is some failure or not. So these can be some states that can be emitted in order.

Yeah. So while we are integrating third-party libraries that are available on PubDev package, then these are the things that I keep in mind and also instruct my teammates to keep in mind and check. Like, having these checks will be beneficial. So first, we need to evaluate the library's reputation. And we can also check where it is being originated, who is the writer or developer for that. And also, we can check whether this is having a good documentation and code also. It should be if it is open source, then we can check the code by going through one method to see if it's working well or not, so that we can do. And also, one thing is good to check that it is having a good version history. Most libraries are available that are not updated since 2 or 3 years. So if you are using that sort of library, then eventually, we'll get in trouble because Flutter is keeping releasing the updates. And if it is getting deprecated, some methods used by third-party libraries are getting deprecated, and we can get into trouble in our released application as well. And if we can also minimize data exposure from our side, it should be really minimized. So if we can see that we are using Flutter Secure Storage to store sensitive data, like accessing tokens and encryption keys and all. So these should be platform-specific storage mechanisms. Like, in ours, it should be keychain, key store, or and in Android, it should be key store. So our data is not going anywhere outside, and we are having good trust on that. Other than that, we should scrutinize the network request and data transmission. So if it is having all HTTP methods, HTTPs methods should be there. So it can be more secure and trustworthy. And also, we can inspect the format of the data that is being sent or received as well. So that way we can check, if it is having proper permission handling, if it is using camera and not asking for its permission, then we as a developer need to handle it so that we can see. And also, the most important thing is that it is staying updated with the Flutter updates. And if it is having some vulnerabilities, then they are being monitored by the writer of the plugin, and that can be done properly. So we don't get into any trouble while our application is ready to release or has to release. So thanks.

Yeah. So when we're building the application for the final release, it's known that the app size should be very small, and our launch time should be, like, less. It should be reduced, and we can improve that by using these approaches. First, we can do code optimization while building the application. We should remove any unused code. For that, we have the Flutter analyze command, so we can check whether the code is not in use and remove it. Also, when having the project in hand, we should refactor the code to remove redundancies and use efficient data structures. In Flutter, it's essential to use constant and final keywords as required. This reduces the rebuild of the widget, so many times. Another important thing is to manage the assets properly. For images, we should optimize them. We can do it at the end time by using the Flutter image compress command. This way, we can optimize them at once. It's also helpful to keep in mind since the start of the project to use mostly SVGs and webp files for our icons and vectors. This really helps in reducing our application size and launch time improvement. We can use compressed images and good resolution images but without additional data. We can break down our code base into smaller modules by breaking it into small parts and using the splitting of the Flutter application. We can also use the Flutter modular package, which is used for Flutter's code splitting functionalities. Other than that, we can reduce the use of dependencies. If we have some feature that can be developed natively or has a smaller code base, then we shouldn't use the third-party application. Other than that, we can check if our application size is too big. If so, we can use the specific additional argument in our build apk command, which is split per ABI. We can also use Flutter build app bundle for iOS, which splits per API, and for Android. We can test our app on different devices to see if it's running properly. We can also implement the CICD pipeline with other tools to improve our application's launch time.

Yeah. So I probably cannot remember the name of that application, but this particular application was built for the global Flutter Development Summit. And, they have created this application that was used for the registration of the coming candidate and further things that all things we need for managing the event of clutters that are happening eventually. So they were having really good animations. They were coded by developers at a simple level. There was no such complexity. And, if I was to develop that application by myself, then I would be on my mid-level of career, then there could be some things that I didn't know. And I have learned tools from them, such as beliefs, interests, and animations, working in the flow, and having very good architecture there. If you need some complex level of architecture like TDD and all, for a mid-scale application, then we can always go with very good architecture. The state management of that application was beautiful, and I have learned from it. And, also, at that time, they implemented some little game-like feature there so that I have learned that there should be something that is entertaining the user. And the intuitive user flow was the best. So at the development side, I learned state management and data management. And, at the user side, I learned some intuitive flows that users can go with. It doesn't require the user to think a lot about, what they should do and all. It feels like, let me go there and check this feature and all. So that was pretty impressive. And animations were pretty impressive, and I have learned from them. And, other than that, I also keep checking other open-source projects that are available on GitHub, and I keep learning from them, whenever I need to require some feature or not. So there I see, and I don't remember particular names or authors of them. But, yeah, I know the code and flows so that I like to implement in my application. So that was all. Thanks.

Yeah. So for performance optimization, first thing is to use a suitable architecture, and that should be very proper. And it should be done from scratch. Like, since we're building the application for the first time, it should be done properly. And after analyzing the requirements of our project, we should choose a very appropriate architecture that is optimized. We should go with the perfect state management technique that can be either block or provided depending on the complexity of our application. Other than that, we should not reveal the widgets that are not required. And if we are having some complex level of UI to develop, then we can use the proper widgets. Like, where a row is required, use a row, and use a stack as little as possible. And also, it's important to use stateless widgets over stateful widgets. We know that we will often require stateful widgets in the application. But if it's avoidable, then avoid it and use stateless widgets. And do not call the set state method a lot. Only when it's required, we should call it. This was the UI part, but we should also focus on data handling by using busy loading, caching, and the data structures should be efficient so our code can be optimized. When we are using list views and grid views, it can give us a really good performance other than while or overusing columns and rows and scrollable items. Other than that, there are some things that we need to reduce, like opacity and clipping, which are expensive operations. So we should use them mindfully. And also, when we are releasing the application, we should use profiling tools, such as those available in Visual Studio. So that way we can identify the bottlenecks of our application. Also, we should use the latest version, so we don't use any deprecated methods or properties of the projects. And when we are having a smaller app size, then it will be running faster. So that's something we should keep in mind. There are about performance optimization techniques in our application.