Sharukh Mohammed

Yeah, myself, Sharuk, and I have, like, 7 years of experience, mostly in Android app development. I have worked at product-based companies, like those at IITs to cognitive start-ups. Mostly, my expertise has been in agile-based processes, and I build apps that scale to millions of users. Right now, I'm working at Silver Labs, which has a product called Resin, a short video platform, where I also lead a team of 5 to 6 people.

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

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

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

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

Which design pad will do? Multiple. I would suggest you know probably think of maybe something called a reactive kind of database, where the data automatically reflects onto the local Relum database. I think we can go with that, but that's a tightly mobile-first 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, where we load the data from the DB to the UI. Basically, be it any TV, we should be definitely using a single source of truth pattern for mobile platforms so that the data always stays in sync and there are no discrepancies between the data and what the user sees.

We should be using a better library itself instead of doing plain HTTP calls. Instead of that, we should use a library that throws exceptions where we should use try catch. We should also wrap all of this stuff into a class where it is actually a base network response class with type D, which is a dynamic type, where we could specify different kinds of body. It will come and we can actually parse that on the flight. So we should have a base class where all the serialization and deserialization happens somewhere else, and our code looks clean. Only our business logic is visible here.

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

An offline-first mobile app, I would definitely choose a proper DB first, probably like Realm or something. And I should be giving out streams from the model to the virtual widgets. And I would also go with a single source of truth pattern where my network calls happen and the responses go directly to the DB itself. The DB reflects back using streams or observables back to the widgets. And the widget should be able to dispose whenever the widget is disposed. The subscription should be disposing when the widget is disposed. So this kind of architecture where the single source of truth pattern is implemented, there will definitely not be any kind of data integrity errors. So data is always exactly what the UI is reflecting from the DB. Maybe we can also implement some data synchronizing techniques where we can maintain a last updated timestamp for the DB and periodically do calls in the background and update the data in the background. But still, the DB always reflects the UI, which is the single source of truth.

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

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