Saurabh Lahoti

Hello. My name is Saurabh. I have been working in mobile tech for around eight and a half years now. I graduated from Delhi College of Engineering or Delhi Technological University in 2015, and since then I've been closely working with startups. My first company was ClickLabs, then I briefly worked at press play, and then I spent three years and 10 months at router, and then 3 years at echo. In router, I worked as an Android lead. Router is an online streaming platform where gamers come and stream their content and earn money. In that, I worked mainly on streaming your video on the web using WebRTC with Aurora, which was mainly native Android. I later onboarded with Flutter at ACCO, which is an online general insurance platform. I was working in the health line of business at ACCO. When I started there, I built the health app from the ground up, building all the features for all the health modules. This included payments, policy management, filing of claims, and health fitness tracking, Google Fit, and everything else. So, that's my background.

Optimizing updates in Flutter, interacting with the restful APIs. Stick updates now. So, by optimistic updates, I would assume it is related to updating the UI with APIs when we have integrated APIs with the system. So whenever, for example, you have background API calls in the Flutter app, we use state management basically to make this much more efficient and clean. And whenever we are making an API call on a background thread, we get that response and basically change those states on the UI, reflecting the API call responses on the UI using the states. And whenever the state changes, we have one initial state. Let's say we have started the API call. We emit a state and that would be a loading state, for example. And when the API call completes, we get the response and we emit a state with the complete data point. So that way the UI thread doesn't block itself and we don't block the UI thread and whenever the API response comes, it's reflected on the UI. And let's say there's another case, for example, when we have multiple API responses, for example, on the UI, then we have multiple states related to the different UI updates that we want to do. And depending on that, each state, a particular set of UI content is updated.

With respect to architectural considerations, when we're building a secure mobile app, first of all, if it's using multiple external services, I'm assuming it's related to APIs or external libraries that we're using. First of all, our data shouldn't be exposed in any form. Content providers are basically something in Android which we use to expose a particular app's content to any other app. Those should be used with some sort of encryption if we are providing the content, and the keys should be kept within the app itself, for example. But if we don't have such things on the app, then other things we can make our app secure is through orchestration of code and basically minifying the code of the release build, the signing of the APKs are signed before pushing them on any app store. Apart from that, if we are using external APIs, the connection should be made secure using HTTPS. With that, the keys, for example, if you're using any outside APIs, we have certain keys or secrets for accessing those contents which are shared by different API vendors, for example. So all those are considered when we are using some external services.

By a mobile app. Listing the performance of API endpoints. So, right. So, basically, when we're having our linear stress testing or when we're testing the performance of the API endpoints which our app is using, we generally use tools like Postman to test the APIs independently. We can test a single API by calling it 100 times back to back or in a parallel way to test its performance with the back end API, stress testing the back end architecture or back end services. And on the app for stress testing a particular API, we test it on different network conditions. For example, if we're calling it on a 3G network or a GPRS or Edge network or a 4G or 5G network or a WiFi network, we test the APIs that respond based on these different network types. Apart from that, we also check whether the API payload we're getting is compressed in Gzip and whether it's not a heavy payload. If we have a payload, for example, it's subjective, but generally, we try to keep the payload to a maximum of 5 to 10 kilobytes so that we don't break that. If we have a bigger API response, we try to break that payload into multiple APIs so that the UI or the app doesn't feel laggy or slow waiting for just one API response that takes a lot of time. And obviously, the response time should be less than one second. We try to make it less than one or two seconds so that the app doesn't feel laggy. However, it's all subjective depending on how much work the back end is doing. But when the back end receives the request and sends the response, that time should be very less, independent of what the back end is taking the time to process and get the data. But we try to minimize that.

Right. So basically, for example, if you have a large-scale Flutter application, for instance, a larger one by large scale, I would say there are multiple modules. For example, payment is one module. In our case, the Aco app had multiple lines of business. One was health, one was travel, one was auto. In auto, there were two big modules: cars and bikes. Then there was life insurance. So everybody had their routing to different pages for navigating to different pages. Now if all of that would be part of a central code or, for us, one place, it would be a very long and lengthy code, and it would be understandable. For example, two lines of business code or two modules could have the same sort of signature for the same navigation. So, first of all, the navigation at each module or this thing can be broken down into two things. One is the namespace of that module, for example, health slash or the module a slash module b slash module c slash. Then the module's individual pages can come in after that. And that itself can be part of the module. Each module could have its own navigation reference file from which the navigation routes can be exposed. So, whenever anything is built inside any one module, it can be part of that. If something is common to the complete app, that can be placed as the core or at the common navigation file. For example, if I want to navigate to different modules, that can be part of the common navigation file or the navigation from the splash screen to the main screen. That can be part of the common navigation file. But if I want to navigate to the homepage of a particular module, that can be part of that module. So I'll be referencing a particular navigation function of that module, and it will be referring to that navigation route inside that module. That module will have the definition for all the navigation.

Design pattern will be implemented for data synchronization across multiple mobile platforms and why so design pattern would be implemented for data sync between multiple mobile platforms? I'm not, I'm if I'm not understanding it wrongly, basically, our data the design pattern would be a central store of all the data which can be a back end API, which can be a Firestore or anything. And the other platforms would be, okay. So basically, there's a two-way communication. Whenever something updates, it should be sent across all the mobile devices. So a broadcaster and a receiver is sort of in play here where there's a consumer and producer. The consumer is basically our back end service which emits or sends out a broadcast to all the synced devices or all the linked devices to it. It's like the chat application that we have when the server sends anything and the phones are constantly listening to that particular endpoint. So it's like a channel or a socket where there are multiple devices continuously connected to the endpoint. And whenever something changes on it, all are updated at the same time. The example of this would be a Firestore. In Firebase Firestore, there are documents and entities and all the devices which are connected to it can be connected to it and they can keep the connection alive as long as the app is open. And then when anything changes in that document, everything is reflected onto the mobiles as soon as anything changes. So all the devices are constantly connected and the connection is kept alive. And thereby, we can basically sync a particular content across multiple platforms.

Identify what might cause an exception to the same moment. We will probably dispose these stateful widgets. Stateful widgets' state. So it's a stateful widget. Stream.periodic(Duration stream). Okay. There is a stream which is emitting something after every second and there's a subscription which is listening to it. Right? Now when we close this widget or this widget is disposed off, if we are not closing the stream, it would be constantly emitting and basically there would be this mode, I think, when the app's when we keep on opening this custom widget or let's say this custom widget is part of a recycler view and that keeps on loading or creating this widget, there will be multiple streams which have been created in the system and are not disposing off. We are not canceling the subscription at any point. That should be canceled in this dispose function before super.dispose is called and the stream should be closed. If you don't close it, there will be multiple streams existing in the system at one point and might cause out of memory error or memory leaks as well. Then we close this particular stream.

HTTP request and response to improve error handling and maintainability. So HTTP.get gets a user, but we get the user data. As we throw the exception, fail to load user. So basically, first of all, the request and API calls should be like a generic call for a particular request or sort of a request template. A response should be a part in the format of a template. That template should have the type of data that we are going to get. Right? And that should be part of the invoking call. Like, say, we are calling FetchUserData. First of all, the future here should be having a sort of type. Like in this case, it should be a user type which is a user object that we are returning by this function. The future should have that. Next is when we are getting this JSON response, the response should be a class. Basically, it should have the see here. Response is basically a yeah. It's an object with a status code and the data is part of the body. Now we are decoding that body to get the user. Now basically, this would be repeated across this is a sort of a redundant thing and would be repeated across multiple API calls. So here, the JSON decoder something should be actually part of the main API. HTTP.get should be moved to a particular, this thing at the network layer. And the layer should be dealing with the API making the API calls and transforming those responses into an object. We'll be passing to the network layer what object type we need, what is the type of API call, and what is the API parameters and API input that we are calling. That network layer will be giving us the different after JSON decode is called and the responses turn into an object, that object will be sent to us through that network layer. That should be responsible to our network layer and we should be getting the objects at the end or the errors. Errors will just not be a simple fail to load user. To understand more about the error, it should be based on the status codes. Like for example if you are getting 500 or 501, it is an internal server error that you are getting or 502 for unreachable backend, unreachable host. 404 could be the API if we are not getting. All those errors should be specified explicitly as part of that error. error should be understandable, and that will be thrown by the network layer to the caller.

Offline first mobile app using Flutter by data integrity is critical. So since an offline first mobile app, basically, everything is supposed to be stored on the mobile itself. There is no external API communication or anything. So whatever we are storing, first of all, the local database that we are having, it should be encrypted and those keys should be part of either we dynamically create those keys and refresh those keys on the server or add some if it's completely offline app, then we could have a salt which is baked into the Gradle and it's injected at the time of the app creation. And that salt, apart from that API key that we are having, will be basically encrypting the data for us and whatever data that we are storing on locally should be encrypted. First of all, the shared preferences file, their use should be minimalist because a rooted phone can be used to access that shared preference file and everything that we are storing in it, that should also be encrypted as well. If you're not using it for just simple flags, even then we should just use it minimally, not for the user-specific data. Apart from that, the database, as I said, should be encrypted, and there should not be any open content providers. All should be signed for that specific app signature. And token creation and everything, yeah, everything should be on Firebase. Firebase token, we should be having that should be registered on Firebase. And since that, basically, nobody can nobody else can have that particular package ID and create a replicating app. Right? So our app should be registered. And data integrity is good. And since we are not storing it online, the data is everything is being saved onto the device. For one thing, here, what we can do is keep that we can ask or make that we can have that option of keeping the data as not part of the app's storage in the file structure. We can keep it as part of a separate folder in the Android file storage and we can reference that particular thing or database whenever our app is installed. For example, if the user installs, we can store that whole data as part of our app's folder and storage, emulated and slash, and the root path or any folder, but not the Android's internal Android folder basically. Android folder for the app. We can have it part of the root or anywhere else and whenever the app is uninstalled and relaunched, that same folder can be referenced and the data will be still there for the offline app. It won't be destroyed unless the user goes specifically to that folder and deletes it. Clearing data won't affect the data.

So I haven't worked on React Native as such, but since Flutter is nearly the same thing, it has the same principle. So, Firebase backend, first, would be to create a package name, register that package name with Firebase, add our app, both Android drivers, and get the packageservices. JSON file and integrate with our Firebase services on the app. Next, thing would be to either use Firebase Realtime Database or Firestore. Both of them can be used depending on what we want to do with it. So, in this case, if we're using real-time database, we would just integrate the dependencies. Firebase has a Firebase core dependency which manages the versioning, and then there are Firebase packages. In Flutter, there is a firebase-firestore package, and in Android, in the Gradle, we can add the file-based dependency. And next, thing is to have the connection setup, create the structure on this thing. Decide on the structure based on your architecture or entities. Create those entities on the database. Right? Or, basically, then write and read the data from it, depending on whether it's just to consume only data, we are not going to manipulate it. We can just read the data from it. If you want to write and update it, then you can write onto that data.

So the key factors are basically when I'm integrating any third-party APIs or anything. Firstly, I'll go through the documentation to see what and all they are using. Then I'll check out the branch from my project and see whether adding their dependency conflicts with any other. If there are any other conflicting dependencies, I will resolve them or try to resolve their versions. If still they're not being resolved, I'll raise the query to the third-party support. After that, the next steps are to initialize those libraries. This depends on whether I want to initialize it in the application scope when the app launches or if I want to initialize it when they are actually being used through a particular activity or a particular screen. Apart from that, what packages they are using and how their keys are being exposed are also key factors. Are they through the developer dashboard or anything? Security and everything can be changed, including the network traffic and what data they're taking at my end. We can track that in the debug application, where we can track the network payloads, what we're actually sending, and what API calls the package is internally doing. Therefore, we can have an idea about what the third-party application is intending to do, whether it's doing what it's made for or something else. For example, if it's a chat application, it should be active only when the screen is open and should be sending my payload only when I want it to. We should not be sending my device locations or anything unless I ask the chat application to do so. Apart from that, what's the size of that third-party tool that I'm integrating? Am I integrating that and increasing my app size by a considerable amount or just making a small change in the app size? That's also a big consideration. And it should be easily integratable and maintainable. For example, the package versions should be continuously thoroughly updated. With time, are those out of date? Like, was the last change made six months ago, one year ago, or just one month ago? That's also a key factor to understand whether it's maintained or not. Apart from that, is it available for all the platforms that I'm using? Or is it that robust? Yeah. All these things I'll be considering.