Sharukh Mohammed

Yeah. Myself, Sharuk, and, um, I've, uh, have, like, 7 years of experience, uh, mostly in Android app development. Uh, I have worked at product based companies, uh, like, uh, you know, ranging from IITs to, you know, like, cognitive start ups. Um, mostly, my expertise has been in agile based processes, and, uh, I build apps that scale to millions of users. Right now, I'm working at, uh, Silver Labs, uh, which where we have a product called Resin, which is a short video platform, uh, where I get to, uh, uh, also do the team of, uh, 5 to 6 people. And, uh, yeah,

That basically depends. If we were trying to store the data, um, store the data on on the disk, like, uh, like, uh, an access token or something, I would definitely use the, uh, you know, encrypted shared preferences of Android or, you know, the core data. Uh, I'm pretty sure there's there should be a wrapper for this on, uh, Flutter as well. Um, I do not have much hands on experience, uh, you know, on Flutter. Most of my development has been in Android itself, but I'm pretty sure, uh, Flutter also provides, um, wraparound encrypted shared preferences and, um, you know, encrypted core data for iOS. And I would also, um, you know, definitely use HTTPS. And if if the APIs are, you know, so that they should not be listened, maybe I could also use where the JSON data is not not really visible. Maybe so that someone can't, uh, you know, uh, catch the data in between. Yeah. More or less, that's

I am not really sure what the question actually means. Optimistic updates in a flat wrap interacting with the rest full APIs.

Definitely, there are lots of lots of, uh, you know, analytics platforms that make our, uh, you know, life easier. Um, one one of the most popular would be the Firebase Analytics or the Google Analytics, uh, where they provide their own SDKs to, uh, actually, you know, do some tracking analytics. And, uh, definitely, we these should be placed in relevant places on button clicks or, you know, the screen screen moving. Or they should be placed at relevant places so that, you know, duplicate, uh, do not form for these analytics. And, uh, yeah, more or less, yeah, that's it. Uh, I think, uh, Google Firebase Analytics or Google Analytics is the go to unless we want to move to a paid provider.

So, um, I don't have, uh, hands on experience on Ios, though, but I definitely think, uh, iOS provides a way to monitor the performance like the Android Studio does, like, uh, like the, you know, performance monitor, uh, where we see the garbage dumps and garbage corrections that happen, uh, for Android. Pretty sure there's a way for, uh, way for iOS also where the ID itself, uh, the Xcode itself provides a way to, uh, actually see, uh, where the performance and frames are dip dipping and, you know, uh, if anything, uh, happens that needs to happen on, uh, the IO thread, but it is actually happening on the UI thread. Um, so these kinds of performance issues can be noted using

Which design pad will do? Multiple. I would suggest, uh, you know, probably think of, uh, maybe so so so so there is something called, uh, where where it's a reactive kind of database, where, um, the data automatically reflects onto the local Relum database. I think we can go with that, but that's that's, uh, you know, a tightly mobile first, uh, DB, which might not be okay with the back end. I think instead of going through any kind of design pattern, I think we should go through a pattern where, there is a single source of truth, uh, where we load the data from, uh, the DB to, uh, the UI. Basically, be it any TV, we should be definitely using a single source source of food pattern for mobile platform so that, uh, uh, you know, the data always stays in sync and no discrepancies between the data and the what the user sees.

Of course. I think we should be using a better library itself. Uh, instead of doing plain HTTP calls. And, uh, and that library would, uh, would, you know, throw exceptions where we should use try catch. And we should also wrap all of this stuff into a class where where where it is actually a base, uh, network response class with with the with the type d, uh, which is dynamic type, where we could, uh, specify different kinds of, uh, body. It will come, and, uh, we can actually parse that, um, on the flight. So we should we should be having a base class where all the serialization and deserialization happens somewhere else, and our code looks clean. Only our business logic, uh, you know, is visible here.

So, uh, I can see that, uh, we have a stream of of of some data that is being listened for every second. And, uh, that subscription subscribed whenever the which it is initialized, but it is never, uh, discarded or, you know, unlistened or unlistened, uh, at any point of time. So whenever the dispose is called, uh, we should also do something called subscription or dispose or something where we stop listening or else it would cause memory leaks.

Um, an offline first mobile app, I would definitely go choose a a proper DB first, probably like Relm or something. And, uh, I I should, uh, you know, be giving out streams from the, um, you know, model to the, uh, widgets, virtual widgets. And, um, I would also go with a single source of truth pattern where my network calls happen and always the responses right to the DB itself. And the DB reflects back using streams or, you know, observables back to the, um, you know, widgets. And the widget should be able to dispose whenever the widget is, you know, disposed. The subscription should be, you know, disposing when the widget is disposed. So this kind of architecture of where, uh, you know, single source of 2 single source of food pattern is implemented, there will definitely will not be any kind of data integrity errors. So data is always uh, exactly what the is, uh, is is reflecting the DB. Um, maybe we can also implement few kinds of data synchronizing techniques, uh, where we can maintain a last updated time stamp for the DB and, you know, periodically do calls in the background and update the data in the background. Uh, but still, anyways, the d v always reflects the UI, which is the single source of

I actually have never used any kind of, uh, hands on with the React Native application. So I do not have any idea of how the React Native's application life cycle is, uh, how the states are and stuff, how the 6 states are and stuff. So, uh, I cannot answer this question.

So, um, I definitely think, uh, we can use Jenkins on Jenkins and specifying the, uh, build system for every. So, basically, uh, Jenkins should become configured in in such a way that whenever some push happens on the master branch, it will trigger the workflow where it will start the, you know, Flutter build of the release builds for the Android and Ios apps. And whenever the build is present, uh, it'll upload to the App Center and also the Play Store. And, you know, it'll be just queued there. So we'll be just having to push a push out a button to release it to all of the users. So, uh, you know, that's how we can configure a a CSV pipeline using Jenkins. Uh, maybe they can be deployed to Google Cloud, AWS. It's just infrastructure agnostic.