Munish Kumar

Hey. Hi. Sorry. It took me time to understand that it's recording. So, the thing is, I'd like to ask, could you help me understand more about your background by giving a brief introduction? Okay. So I'm Manish Kumar. Basically, I'm giving this interview for the senior mobile development role. So, basically, I have read the documentation and everything. And as far as my previous experience is concerned, I do have around 13 years of experience right now. I started my career in Java first, and then switched to mobile application development after six months. This is where I started with the Android version and then moved to iOS as well for around a year. I handled a team as well, and I had around seven years of experience from then till now. So, at that point, I got to know about Flutter. I switched to Flutter back in 2018, when it was still in the firm, not even in beta. I started some POC work and everything, and I found it very fascinating, and it was quite good for me. So, I switched to mobile development using Flutter, and that was quite good. And from then on, I've been working in Flutter itself. So, you can consider that I do have around six or more years of experience in Flutter itself. I know in and out everything about architecture and everything. Right now, I'm working as an architect. So, this is it as for my background. And as far as my studies are concerned, I have done my post-graduation from a college in Rajasthan in masters in software systems. And before that, I did my BTEC from Ashland Institute of Technology, which is located in Saiidawal, India, in IT, information technology. So, I do have a good experience in around 13 years now, completely in mobile.

What is the best way to do navigation with large scale of Flutter application? Okay, so there are first of all, if Flutter started with navigation, like, navigator 1.0, but that are not quite good because navigation was pretty hard in the web. So they came up with the navigator 2.2.0. So by the Flutter package itself, you can use that, but I'll suggest, like, you should actually use the route package. Okay? So with the route package, we can actually navigate it through naming conventions. Right? And we can actually guard it as well. So let's suppose there is, like, Amazon. You are creating a site, like, an ecommerce application or maybe a social network where login is mandatory to get product visibility and all. So basically, you can guide it through the navigation. And different parameters we need to pass, so for that, we still need to use the route and other packages as well. They are under the hood used to navigator 2.0, which is in the Flutter. And if we want to scale or we want to actually write it as per this, so we can also do that. There's no big deal because Flutter has already taken care of lots of things. And with the navigator 2.0, the main thing is not related to mobile, I'm talking about. The main thing they are actually handling the web part. Right? So basically, when we have, like, amazon.com/some products/some ID. Right? So we cannot go directly inside the Flutter because it shows some hash. Right? So with that, with the navigator 2.0, we can just directly go inside the child window, and it will be good. Right? Yeah, okay. So with navigator 2.0, we can actually handle it very well.

Okay. I will put a solid principle in the context of designing a new feature for a native application. Okay. So basically, we are talking about the singleton. Right? And then the object-oriented things and observable things. Right? So basically, for the native application, it's not about native mobile app or other application. We are talking about the home mobile here. Basically, mobile works on the M V pattern. It should, basically, as per my opinion, follow the M V pattern. We are not talking about the M V M because MVVM is kind of dead in the mobile world, especially for Android a long time. So right now, we are talking if we talk about the Compose in Android, if we are talking about that SIP UI in iOS, if we talk about the Flutter components, like widget components, So they are all related to the code building of UI. Right? So, basically, you need to write the code. And there should be the segregation of the UI layer, the API layer, and the data handling. So, basically, we can cover those in the different sets of modules. So, basically, when I say MVP service model view, I'll say provide a popup within that. You can talk about it. So when we say MVP is like, there would be a UI layer. It's which will be the view. We actually connect to the provider, whether we can use Retrofit providers, GetX, or BLoC. There are lots of state management tools out there, Libraries are there. So, basically, you can use the provider to present the layer. So you just put the API handling, API calls, data handling, business logic part there. But I'm not talking about that. All the logic of that in network call, everything would be there. So you should actually switch to the network layer has done. So, basically, you need to make that separate class or separate package for the network handling. So all the network handling, which is the async task, should go there. So, this would be the network class. And when you are calling through the provider, you are calling the network, it is giving you the data after some time because it's an async task. Right? Yeah. Till then, you need to be in that state. Like, you need to change the UI state to UI state dot progress bar or something. Like, something is loading. And then your view will get to know. And as soon as you will get the data, based on the data, you can show you can just tell the provider whether you have that error. You got the error or you got the data or you got something else which you are expecting. Okay. So your UI will get to know about after the notifying data. Provider will notify after getting the data from the network. It will notify the view. View will actually render. So, basically, as per my opinion. And every class should be every view responsible for their own data handling, own view part. Right? There should be the object-oriented, and basically, that is based on the object-oriented pattern. We had already talked about using the provider. Right? So, these kinds of nets will be actually dry. And the pattern, basically, when we talk of the factory pattern. Our model class using the serializable already does that. Right? So we need not to use many of the different classes, like providers. So factory pattern is implemented inside the model classes using the serializable as well. We do have different packages for different ones, so we can talk about it if we want.

What methods would you use to debug and performance issue on a native iOS application? I'm sorry for that because, like, I don't have that much of XP exposure of the Ios application. So debugging is not, under my, under my expertise, but, yeah, I would like to, like, learn a lot, if I get the chance, definitely. Thank you.

Feature flags can be used to progressively roll out a new feature by allowing you to control when the new feature is enabled for users. This is a kind of weird question, but I'll explain it anyway. When we say feature flags are used, probably rolling out new features in the application. So, basically, a feature flag is a way to control the release of a new feature. If we're talking about a release, so basically, we're using the pipeline or features can increment using the Scrum board. If we do have tasks divided into the Scrum and we're using pipelines, it will actually build that way. The versions will increment, and we'll relate to the release notes throughout that process. So, I think with the new feature, I'll use the pipeline and the release notes with that. For the site for our users, basically, which are our audience, we'll use the update package for the same. We'll get them updated whenever they open up. We'll get them notified through a network notification whenever they open. So, this is how we do have some new releases. And after the release, if there's a hard reset right? So, we've changed a lot. The previous version will break, so that would be the hard reset. We need to block the user from getting that update. That's the thing. Thank you.

Do you use to handle sensitive data with the plateau? Okay. So the thing is, what strategy I need to use? So, basically, I'll use the shared presence with 1, but the shared presence by itself are not, basically, the encrypted one. So, basically, we're gonna use an encrypted shared preferences package. One thing, before API handling, we're gonna use the SHA certificates. So what we'll do is we will actually block the unnecessary API cost. Okay? If the applications are not valid, we are gonna use Proguard as well. And for photo-sensitive users, if users are okay. So if we are seeing the banking application, if we go behind. Right? So when you are actually using the app, and you are checking your recent application, the banking application doesn't show the data because, like, it is the sensitive information that it has. So what we can do is use screen captioning. We can stop record. Right? Record will not allow that user to record, but in iOS, if that's not possible. So what we can do is, like, if somebody is trying to capture a snapshot or screenshot, right, we can try to prevent it. We are but a US gives the data, like, events, basically. So after the event, we can just remove from the gallery, whatever, like, a screenshot they just captured or make it white. Right? So this kind of feature, I'll try to apply. Proguard is the one. Like, text card is the one. And for many outside applications, like, okay, as bomb as they are, like, we're gonna check it with a third-party tool. Definitely, we're gonna get some maybe, like, some issue or some suggestion because it's an iterative process. Google and Apple come up with lots of new things. We cannot actually make the count every time, but some tools we can enroll for. Right? We can go upload the app and get to know whether, like, how it is at what part we were doing the errors. We are exposed to the sensitive data, so definitely we can do that. And for that, the quick good thing, but I'm gonna fix it. First, start with all the data should be saved in the encrypted form inside the application, which is we can use the drift for the data storage, or we can use encrypted shared preferences. And then for the code security, we can use ProGuard, DexGuard. Right? For screen cap stopping the screen capture, there is a flag inside the Android application, so we can use that secure flag. Okay. We can just actually use that, and it will stop the recording and the snapshot captioning. On iOS, the similar way we can do it, but it doesn't stop the captioning. But we can just remove it from the gallery. And other tools we can use, as well we can use. There are a lot of things we can handle. And if around the API, we'll use the SSH. So valid SSH only, API gets hit, and they get the data. And for the data transmitted to the network layer. So at that point of time, we just stop all the log, and it should not capture that way. So these things, I'm gonna do that. Thank you.

I'm reviewing the Flutter widget snippet. Identify what might cause an exception and suggest an improvement to ensure widget properly dispose. 1st of all, we are creating my custom widget, which is straightforward and okay. My custom widget and the rest of the code, my custom widget state is perfect. We are subscribing to a stream subscription. During its duration, the subscription is equal to may and internally, yes. This is causing an error. Basically, you are making an extreme basic mistake and making the stream listen to data. So, maybe after 3 or 1 second, it needs to restart it. So, after that, you have the subscription. You are not exposing it. So, when you go back, maybe just close this screen. Maybe there's a press button or the back button, and you go. But the screen stream is still there. Every second, it's gonna get the data, and the problem is, again, with it, you are subscribing multiple streams as well. There are a couple of issues with the streams. They are actually running inside the state first, then it's actually giving the data to the subscription itself all the time, every time, when my streams come, and it gives you that it starts listening, and it is giving to the subscription. So, it's subscribing again and again, and then it's not disposing itself as well. So, basically, we need to dispose both, my stream and the subscription first. And the thing is, we should not actually keep listening again and again. We can just make the stream and let's listen to it and dispose it, both the stream and my subscription.

Some of the code blocks for an API call in the Flutter. Is there any way to handle HTTP request and response to improve error handling and maintain it? Let me check. Okay. Future. Like, future, async is there. Like, I'm getting the response. A way it is there. I should be get. I'm digest, like, getting it. if we are getting a data, so it is just converting it to the decode and the variable user and the otherwise, through the user. Right? So, basically okay. So it is kind of, fine code, but the problem with this code is it is just giving the future. It is returning back. Right? It's not giving that, the user object. So first of all, we can actually bound it to the user object first. Right? And, I don't know if, okay, so whether responses await if you were using the HTTP. HTTP is fine. Like, I'll I'll use the diaphragm. So that's really fine. I need to, like, JSON dot decode. My response dot body gonna give the string. You are just, decoding, and why are we using the JSON dot decode? I don't know. And user use user data. User data is fine. So, basically, the problem with this code I'm I'm figuring out is there should be some valid return type first at the 1st place. Because, like, you cannot just dependent on the future and then ask, okay, they're dependent on the code which is calling it. So it will return the user object. Probably should not. And the try cache should be handled there. Maybe, like, you we can use the null as well. Thank you.

Discuss a study and a real-time data synchronization across multiple user devices in the prediction. So, basically, there are a couple of ways I found it. The difficulty is very high, but I don't think so. It's very difficult because they are the protocols. Except for people, it's a wide socket connection. So, basically, if you let me take the example of checking an application, like WhatsApp. Maybe my WhatsApp is open on the web, on my mobile, and maybe on another tablet as well. So whenever I get a message from my friend, I get it on the three devices. So how do we get the synchronization? I delete it on one device and it synchronizes on all devices. So how do I do it, basically. We're using the XMPP protocol. So how the XMPP or socket connection works for us. So, basically, every device after login, it actually makes the connection to the server. So, basically, it's not a connection directly open always. This is kind of based on the observable pattern. Socket connections sometimes open a connection for a particular chat, maybe for another socket connection for all the chats, but in terms of XMPP, you just need to make the connection and subscribe to the server, and the server can actually send you back about the events that occur for a particular user. So, basically, my three devices are connected to the server. The server actually wakes up and sends a push notification, and based on that push notification, I can manage my device to do what needs to be done here. So, basically, what events occur? Maybe my one device, so now you send me a message. I get the same message on the three devices because I get three notifications on different devices. But when I send a notification message from my device, I delete that message. So, that is even triggered by my device. I'm not going to get that even back, but on my couple of more devices, which are actually registered with that server. So these kinds of things we can do. We can use multiple user devices in Flutter, so we can do that. It's not only particular to the Flutter. It's valid across devices, basically. And other things is if we talk about some maybe third-party tools, right, we don't want to make all the XMPP protocol. We don't want to write the Jabber and all, maybe the socket connection, so we can use Firebase, basically. So, Firebase is the core thing. Right? It's a Google product. We can use that. We can just get the leverage of the real-time database and the push notification from them, like analytics are there. And I'm not going to go into analytics, but Firebase push notification and the real-time database is the key. So, we can use that and sync across the multiple devices and, under the hood, work from the XMPP protocol and the push notification. Thank you.

How would you configure a continuous integration deployment pipeline to a mobile application in the Google Cloud or AWS? Right? So, I have worked with Microsoft, but I'm not sure about the Google Cloud. Okay. So, using the YAML file, we do is, first of all, there are a set of commands. Right? So, I need to connect it to my main private account, where my code is on my private Git account, GitHub. I just need to connect it through the token. So, I'm not talking about logging in and passing on directly. No. We just need to pass on a particular project, which we need to build on, like, the pipeline. And in the pipeline, we do, I'll use that YAML file. The YAML file will start with some command. Maybe I'll try to make the branches, maybe the sprint branch. I want to delete the queue and RC. So, I'll put that into the sprint branch first. I'll make the pipeline in that way. It will. First of all, trigger when there are sprint branch changes. So, whenever a sprint branch gets a change, it will trigger. And this pipeline, this YAML file actually has a set of commands. So, first of all, I'll start with, like, after the trigger, there would be, Java install, JDK install, and then there would be a Flutter install. Then, I'll do the installing of the provisioning profile if I want to add the IUS belt. Right? So, I'll do the manual integration manual signing up, manual signing up the IUS application, and release the I, IPA. And I'll use the App Center for the same. So, yeah. We need, like, some place where we need to release the application, and then that, I'll make that open link, right, using that center. And what I'll do is, I'll just, okay. There would be a command, Flutter. Okay. And then I'll run Flutter run, Flutter build, Flutter clean, and everything. I'll make the I'll tell the device Flutter run and the main file path if there are many main files. But if there is a single run, I need not to. And there would be, then the then finally, then the step would be the Ios configuration. For Ios, like, I need to do install the provisioning profile, everything. And then I need to manually sign it. Right? So, okay, through the command. So, I what? Where the file is, providing file and everything will be placed in the secure vault for the files. And then I need to just give the permission to the pipeline. And then I need to release the, Android build, and I need to name it. Right? But Android and iOS, a IP and a APK need to release. I need to name it. And then finally, I close the pipeline. And there would be a release pipeline as well. Right? CICD, basically, deployment would be there. I need to check I need to tell the deployment CD. Like, what is the CD? So, CD would be, like, my pipeline and QA or RTC, and I'll integrate that. I'll tell that. I'll do the configuration of the app center. Like, API key would be there. The group link would be there, and I need to make that group ID and the name and the release part. And by that, if I run that after the CD, when I run the CD, which is releasing, it will release the application and put that place into the group ID, which I have already made public. And using the public URL, I can access both IP and APK. Thank you.

What solution would you propose for scaling the back-end infrastructure for a quickly growing application? I'm not sure why this is related to the React Native application, then we thought we are talking about the back-end infrastructure. I don't know, is this a trick question or what? Because, like, okay. So, scaling the back-end doesn't impact the React Native application, but the speed of your application is directly impacted by the back-end infrastructure. So, basically, scaling on the back-end, you can use microservices, pagination, and push notifications to improve performance. The back-end scaling completely depends on many factors, such as the performance you're seeking, the amount of bandwidth you have, the kind of capability you need, and the usage you're handling for your front-end application. So, all of this depends on your back-end APIs and their performance.