Nikesh Nayak

So, let me tell you about myself. My name is Nikesh Nayak, and I am from Nadiya, a city in Gujarat State, which is situated in the country of India. I completed my bachelor of engineering in 2018 with a 7.85 CGPA. After that, I started my career as a native Android developer. And during that period of time, I developed mobile apps using the Android framework. I used the Android Studio and Java XML. Later on, in my career, I decided to start working on the back end as well. So I learned about BHP, my technical skills, and all that. In 2020, due to the difficult time of COVID, I decided to learn the Flutter framework. And at that time, Flutter was relatively new to the market. Just a few years had passed. So I decided to grab that opportunity and learn Flutter during that period of time. And later on, in my next organization, I started working as a full stack Flutter developer. In my career, I always believe that I have to keep myself in a learning phase. So later on in my career, I faced some issues, like the company I was working for closed due to COVID-19. Due to COVID-19, they lost their business. In that period of time, I started freelancing. And in that period of time, I learned Node JS. And other backend technologies, and improved myself and my skills. I've also started developing websites using the product. So from 2020 till now, I've been working as a full stack developer. And I'm very excited about this opportunity that I'm getting. And I'm very confident about my knowledge. Because, as my mother says, always keep our hearts clear. And always keep yourself transparent with each and everyone. That's my side.

That's the main point. If there's a need to request, which is the last period. I always make it so that payloads can be stored in the map object, you can say it should get stored in the map object. So we can store multiple types of data in a single object. We can pass directly to one function, another function, easy. Like, we can set the data using the map. Okay. And, I think, most HTTP requests are based on REST APIs. Sorry. Based on REST APIs. Okay. So they accept a JSON response and give us a response back as a JSON only. So I use the map object, and I convert to JSON and pass through the URL request. Okay. So it can easily get passed between and, yes, we can handle it very easily because dealing with the last payload, it can be achieved by using the map we have inside the folder. Because if I take multiple variables and pass into the parent, I have to set it manually for each and every parent myself, and that will be very time-consuming, and it will be very hard for a developer. Okay. So I can optimize the Flutter web request by using the map of map data type. Okay. Like, we always use it for a key-value pair. Okay. So that's it for my answer to this question.

Yes. Flutter is great in the architecture design. Okay. Like, we know about the clean architecture. It simply follows the particular feature. Like, if we are targeting the authentication feature, it helps us to divide our app based on the feature. Okay? And we can also use that feature later on with another project without any extra efforts. Okay? So clean architecture basically is one of the finest things Flutter has. Because, if we are defining a login sign up or everything, we can decide that it's a one type of authentication feature. Okay? So we can create one feature. And, it simply divides us into the domain layer and data layer and presentation layer differently. Okay? So we can connect with the local or remote service easily. Okay? We can create our abstract classes. Okay? And, yes, we can use the block architecture in that feature, which is way better than other architecture for the clean architecture. Okay? So my strategy is to implement that I will use the block architecture. And, I will use the tools which rebuild my model like a builder. It will build my model with the help of some builder runner or adjacent annotations. All are the generators which are available on the prospect of that day booking. And over there, they have already built up generators that can generate from JSON to JSON for myself. So I can simply use that I can simply define the fields and declare the annotations and simply reuse that. Okay. And block also helps me to define the states properly, and I can handle it with the real UI. And, yes, there's a benefit of the clean architecture that we can keep the separate models. And each model can be declared inside the feature log. Like, this is the authentication feature. So I can use the authentication model inside only that feature. Okay. And it separates one feature from another feature. Like, we can create a chat feature folder. So the whole chat gets included in that particular folder. It's a conversation list or a message detail list. Okay? Everything which we require for a check. We can keep all that thing in one folder, and that's the main thing that we can use it later on in another projects also. And I think code availability gets very easy, and it's also generally managed easily by other developers also. So they can just refer the code very easily, and they can understand what the app is built. Okay. How it was developed. It's maintained very easy. So that's my strategy from my side.

I usually focus on declaring user-defined exception handling to ensure robust error handling when making API calls in Flutter. Okay? Like, if I have defined some errors and anything else, such as validation errors or input that's not properly validated, I can handle those. Or if required input is missing, that's another type of error I'd handle. For example, in the move, they have defined specific status codes and headers for errors. So, I will handle the status code and errors, and create one common class that handles all these error cases based on the status code. If the status code is 411, for instance, I'd define that as one type of validation error term. I will use that exception class to handle the exception case inside the try block whenever we make a network API call. And I will also handle socket exceptions, which are normal for Internet connection availability or lack thereof. Or, we also have unexpected errors, which I'd catch using the exception class. Because if some error is not defined, it should be caught. So that should be done with the help of the exception class.

Yes. Definitely. Dependency injection is very required in the current large-scale applications. Okay. Because what we'd want to know is the disadvantage of not using dependency injection. Okay. So the thing is that, we are initializing each and everything whenever we visit a screen or wherever we have declared that thing. It should be recreated and deleted. Okay. We need that whenever a screen is opened, everything which should be created at once, and the same object should be used in the whole app. So for that, dependency injection is used. We are using the get-it package. So using that, we can achieve this. For my previous project, I have used it. So for the block provider, okay. Whenever we have to use the block class, okay. The block which we have declared has to be used. We are calling the block provider of the context. So that block should be available for the whole app, okay. So for that, the block should only be created once. Okay. We have done that in the get-it part. It should be initialized when the main function is called. Okay. And it's a repository, a type of service, everything. Remote services, we have created, like, all three more services or chat remote services. So we can directly call that, and it's a very transparent part. Like, we have to simply pass the object of getting from one class to another to initialize each object because it stores all the objects which are getting created in the app. In a single object, and it tells us I have all the references of all objects. So I will share it to each and everyone, and it simply detects if the reference of the object is available or not, or if we forward to initialize that object in the dependency injection file, okay, wherever we are initializing everything at the start of the app, we will get the error. Okay. Because we haven't passed that. Okay. So it simply makes our work easy. Okay. In short, because our app is lagging and any break occurs, or we are fired, or we are having any problem of the object not being available. This block is not available, or at this block context, we are not having any access. Whatever error we are getting regarding that, we can easily achieve using this dependency injection. And it makes our app very smooth. Okay. It's only initialized everything at the start of the app. That's the main power of dependency injection, and I can achieve it using the get-it package. Okay.

How will you effect our Flutter application to improve performance and maintainability using the Flutter clock? Okay, that's the main thing. Right now, I faced this issue that there was one project where you created in the provider. Okay. And the client said to me that I need to refactor this whole project with the block. So first of all, in that case, I have to look into it that wherever this API calling was happening. That's the main thing because block is basically separating the business logic from the UI part. So what I have to do is decide how many APIs and how many features are there in my app. So based on that, based on the APIs, I can create the block like a login block. We can say that, like, an auth block. In that, we can manage the authentication. Like, another is a get product list. We have created one API. So I can create a get product list API block. This one can get the product list, and I can manage the state of the screen that whenever the product list is fetching from the server. We have to show the different type of data, like a loading screen or a list of products we have to show when the products get back. We have to maintain the state loading state success that fills everything. So we have to create the block on the base of the APIs we have right now and separate the business logic, which we have integrating that particular screen that we have to target from the start. First, we have to target the login screen and then sign up. And whatever the screen which are coming in the path we are getting my which start the migrating. To achieve the performance and maintainability, like you are telling. And blocks itself maintain the code very well. Because one knows the block, knows that maintainability is the main thing. And it's also improves the performance. Because the block has that power. Then it's only will update that particular part over, whichever side you are consuming or like you are listening that part of the UI. You have configured block of that part. That part only will get refreshed, and that's the main thing I like about the block. Inside of other state management like that, refresh all this thing, like the get x and provider and everything. So block is the powerful in that case. So we have the block consumer and block listener and everything. Block consumer has the listener and builder and builder both. So we can use that. And using that, we can refresh the screen. So, I told you that we can create the API calling with the block, convert create the block on the basis of the API and calling that particular screen. And 1 by 1, we can start the migration 1 by 1 screen. That can be achieved like that. I had done that thing like that. That's fine. And if there is another approach, it's acceptable. But I have then done that. What? Like that. Thank you.

I will load the data and then check the state after the load data event. I will use a debugger to see if the state is changing correctly. I will also use the Flutter DevTools to see if the widget tree is updating correctly. We just test instead of sync. The final block equals my data block.add(loadData). K. Calling the event. Tester.com and silent. I expect later, block, and it's in order. Easy. I think I can ensure it by writing a test case for it. So that's the main thing, even that lock part in there. This thing aside, not an issue. But thank you for this question. I can work on it later. Thank you very much. Let's move on to the next question.

How do you go about documenting API interactions for future reference and maintenance? That's the main important thing, that further developers will do. And the document comments will be done on each and every widget, on the particular function. Like, what's the use of it. They have to mention the functional aspect, if the function is regarding some calculation, something. They have written that part in the Flutter app. So they have to mention that right away, that this part is done for this. Like, whatever the use of it. Okay, for example, if my function is doing a procedure of text, okay, using some API on Firebase, and so I have to mention that this function gets called. Okay? And it will do the OCR of the image, and we need to use the text. Then I have to describe that, and I have to write the name of the logic and the description. And apart from that, we also have to mention which API is for which use. So we can easily refer to them. And, yes, documenting API is the main factor. Because we have to document each and every parameter. Because someone will not know why this parameter has been defined. So I have to mention that this email parameter is used to pass the email in string. This password parameter is for this. Okay, whatever the purpose of that parameter is. Like, if it's an optional parameter, you have to mention that this is the optional parameter. Whatever you use, like, with a colon, optional, you write over there in italics, like, fashion. So it will simply improve understandability. Whenever they revisit that function, they can simply view that. Yeah, this function is for issues, because we have to write that this function is for issues and this parameter is for this, and what parameter will accept it. Everything you have to mention. So documenting the API is the main factor right now for Flutter developers because most of the Flutter developers are not focusing on them because they are focused on development. But, yes, you get the time. If you have any way to optimize the code, you have to mention it.

What are some approaches you use to minimize the app size and input the launch time of the Flutter application? Yeah, that's the main factor. Today, for this, I have learned that, for optimizing part, I think this thing usually faced by the Flutter developers, how to decrease the app size. So to decrease the app size, Flutter right now supports tree shaking icons, more tree shaking. I think that's the parameter they are providing. So to achieve that, you can minimize the app size by using no tree shaking icon. And also, you can use some configuration in the gradle part to minimize the app size. Because they have some parameters in the gradle file. Whenever you configure it, like shrink, I think shrink the size or minifying enable type of parameter is minifying enable. That type of parameter is in the proguard file, which helps us to decrease the app size. And also, for the launch time, what you can do is focus on the white screen that's being shown at the app start. So you can change that splash to your app's app icon. So it will look like your app is already loaded. No one will notice that the app takes too much time to load. But you can achieve this using the splash screen. You can place an item, like there's a package available, pop dot dev, named Flutter Flash. But I used the last one so many times. But it helps us to define a logo where you find the wide screen. You can place your logo. And after a few seconds, nowadays Flutter is very fast. So they have improved the app start time. So when the app gets loaded very easily.

What are your approaches for integrating performance optimization techniques in further applications? Okay. For that, I use Flutter. I always run Flutter in profile mode before going for the release. Okay? So to check that the app is behaving, we have to check the behavior in release mode. So for that, I have used the Flutter run -d dev --profile command. Okay? To check the profiling. And also, we have the inspector and product performance tool, okay, which are provided by Flutter. So we can check network calls. We can decrease network calls. Okay? Because the main thing developers face is repeatedly calling network calls, okay? Because whenever you call a network call, it takes some time to load the data. Whenever you are listing your data, okay, you should focus on the pagination part also because if you're not paginating your list, you will face a performance issue. Always try to not be dependent on too many network calls. Okay. Try to store that data if possible. Okay. Try to store that data in the local part. Okay. And also, sometimes, if I think as part of my concern, sometimes a developer faces an issue because of the back end part also. If your back end provider has given you an API and it's returning data that takes more than 5 seconds. Okay. A response taking more than 5 seconds is a risk. Then that API is not developed very well because if it's getting 5 seconds, you will definitely get more time to load the data. Okay. So that's not the optimal way. So back end API should be optimized also. Okay. And try to store the data in the local part if possible. Try to fetch the data from the local and then do the background API call. Okay? And make sure your API doesn't call redundantly. Okay. Make sure. Because if that part is done, then your app is going to lag. And also, you have to focus on the animation part if you are doing that because mostly animation parts lag the app. So when you have to animate the app, you have to focus on that. Okay. So that's why we use the Flutter performance tool, in which we can see wherever the network calls were very high, where memory usage was very high. Because we have to make sure that when you are cleaning any ticker or any controller, you have to dispose it whenever the widget is getting disposed. Okay? Whenever any control is getting disposed. Like, we are animating something. We are able to close it. If the memory gets leaked, your performance will get down. So that's something you should not be happy about. So I think for that approach, you should definitely use the Flutter performance tool. If there are any third party tools, I haven't used them, but I know there are some tools available. But mostly, I test the app manually and also focus on the Flutter tools. Okay? Thank you very much.

Open source project, I think I haven't let me think about it because open source code, Flutter code that we admire and what lessons learned from it and tech we apply in our work. Recently, I in the last month, I got the opportunity to work for a company for one week. They were working on an open source project. They were working on a library of one type of messenger. And in that part, I learned that they had integrated a CI/CD pipeline very efficiently. They were using the e2e or e2h testing and doing user testing. And they had written proper each and every test case for the camera features. They had used the clean architecture. And they followed the rules of data very efficiently. So I learned that we have to use data very efficiently because the milestones they had defined and the work was very professional. So I learned from that sort of project that I have to set up my CI/CD pipeline for my project. So that the delivery of the project gets very easy. Right now I do, but not very efficiently. I'm because we are always learning. So we are learning day by day everything by working on other projects. So from that, I learned that we should use, like, it to be testing. It is one type of cracking testing we were using. So I like that. So that makes your app bug-free. And also, you get a headache off of the testing. Because it simply automates and gives you a report. Also, they were using the GitHub pull request and issues. Everything, they were using very professionally, so I like that. And I learned from that I'm following that pattern. I started following, and it is very useful. I'm learning it right now. So that's the thing I learned from it. From the open source project. That's right. Just tell you from my side, I like the intent, and it was very nice. Thank you very much.