Mohamed Wasib E

I'm Mohammad Wasip, and I'm a Flutter developer currently. I've been working in this industry for more than 6.5 years. In the beginning of my career, I started working as a native Android developer, which was using Java for our development. And later, I switched to Flutter where I can develop for all Android, iOS, web, and I have graduated with a bachelor's degree in computer science.

So we have multiple methods. I use Android Studio for developing the applications. We can use Visual Studio Code also, any other IDE also. So in Android Studio, we have the debugger options. Well, in the code itself, we can put debug stops in any location, anywhere in the code, and we can see the logs also while running the app. And even when the app is terminated, we can see the errors or the messages we have created in the log. And we can use a debugger also. There is another method which I used at the beginning of my career. I would just print if I failed, if I needed to see something in the console, or I needed to confirm whether we had reached a certain line in the project. I would just print or log whatever was in the code so I could see it in the logs.

Dependency injection, we have multiple methods. Even the state managing is actually a dependency injection. Instead of state management, I'll go with creating singleton classes, which will create a class, and we'll create an instance of the class. We can initialize a class, and we can have multiple methods. We can now save like we can initialize variables also locally in the class so we can access them from anywhere. It's like suppose I'm creating a local storage class where local storage we'll create internal methods, and we'll call local storage, which the local storage has 2 brackets open and close, and we can directly access the methods, the variables, and everything within the singleton class.

We have two methods. I usually do it feature-wise folder structure, and logical-wise folder structure. It's like we create a data folder for keeping all the models, response models, and internal models. And I'll keep the logic file where I'll keep all the blocks, the helper folder which will create all the resources and everything, and utils to save all strings, colors, and everything. And the views folder where we'll create the widgets folder and screen folder inside. The widget folder will contain all the custom widgets we'll use globally inside the entire screens, and the screen folder will contain all the screen files. Or else we'll create a specific file for a screen folder for this screen, and we'll keep widgets used inside the specific screen also. And to improve performance and maintainability using the block package flow, if I'm calling an API and I have to update a specific part of the UI or the specific widget only, then I'll build a block builder. And we just need to update that specific UI instead of updating the entire screen, the UI, the scaffold. Just update that specific part of the UI so it won't take up that much memory.

I usually create an API service class where I'll save, I answered this question before. For future reference in the meetings. I'll create an API service class where we'll have multiple methods for get, post, and patch, delete, and all these types of API calls, and we'll document everything. I'll put comments everywhere. What is this? What's the use of that? And what else you have to pass in which format we have to pass? Mostly we'll pass body, query, and the params in query, a map of string and string, and we'll pass endpoints in a string. It will be like that. I will create an introduction. And if there is any endpoint, we'll create an endpoint file also where we'll save all the endpoints, base URL, and everything. We'll group the endpoints by the type of feature. If it's a blog feature, we'll group the endpoints by blog, and add a comment about this blog endpoint specific blog endpoints. And if there are any users or endpoints, we'll put comments about all the users and keep it together.

How would you optimize a fraudulent network request when dealing with large payloads? Okay, most of the random Flutter HTTP or like the API rest API calls won't have much issue with the large payload. And if there is any, we can split it and send it later, or else we can keep it in a separate isolate. It's very easy, and we can do that.

It's test widgets. Load that event update. State. I'm not sure about this thing. I want to test which, like, I want to run the test, actually.

Okay, so if we have multiple UIs, and like, mobile, a tab, fab, so I usually create different layouts for each. Like, we'll use reuse of components. We'll create the components different in different, and we'll create the main UI layout. Like, if it's below 360 or 400, it's mobile. And if it's between 700 and 800, or if it's between 700 and 400, it's a tab. And if it's above 700, I'll like, assume it's a web. So by doing that, we can easily put these widgets we have already created in specific questions. It's too easy. And we have one more thing to add, and we have we can wrap the if there is any something in instead of a row, we can wrap it or change. If there is a grid view, we can change the cross axis count by the width. Like, is it a mobile, is it a tab, or is it a web? By creating a responsive helper class, which will whenever we call the responsive helper class, we just need to pass the context. It will tell us if it's a mobile or a tab or a web.

If something is not, like, to minimize the app size and improve the launch time of a local application. Okay. Instead of using PNG and JPG file formats for images, we'll use SVG files, which will be very less in memory, and we'll use all the assets, like images, videos, or GIF files. So we'll tell the design team to create them according to the mobile design, which has to be in the mobile design. So we'll tell them to create them according to the mobile design so they won't be much bigger. And another thing is, instead of saving all the images in the app locally, we can send those screens which users don't use that much through the URL of the file through APIs, which we'll get from the backend, and we'll show them. And, for that, it's better to reduce the functions that I have. We are calling at the beginning in the main file of the app. So it's reducing the functions we are calling by putting a weight on this thing. So reducing it will increase the performance of the app while it's loading. Yeah.

Open source Flutter project you admire. Not that much into our own account. I can't remember kind of open source Flutter project. Okay. I have in the beginning of my career, I have gone through many Flutter projects in GitHub to learn all these things. I have, I've then in the beginning, started with state management using Git instead of any state management, then I started with Provider. And in the next stage, you started using KedX, and I used it for almost a year. And then I started with Bloc. It's too good for the app's performance. And I have learned many things, like folder structuring and creating specific service classes for, like, a request and if there is any data that we have to use across the application, creating single instance classes which we can access from anywhere. And creating models in a different directory and dividing the folder structure by response models and request models, which we'll send through the body and structuring the entire app through the clean architecture.

I have used CICD, using Fastlane to distribute the app through Firebase distribution, and could we suggest a strategy to enhance it? Yep. Streamline code deployment. I'm not sure about streamlining code deployment, but I'll tell you how I deployed through like through Fastlane. So I created the Fastlane folder, inserted the app and the CICD folder with files. And I kept all the rules on how to create the bundle ID or the APK, giving all the filter build APK split by API level if needed. I also used flavors, so I put the specific flavor name. And Firebase was already connected. So we just need to put the project number and these things, and it was successfully working. And there's another option, GitHub Actions, which we can also use for CICD, which I used a couple of times also.