Dheeraj Giroti

Hi. Um, I'm Dheeraj Giruti. I have 11 years experience in Android domain, And I'm working with Kotlin from last 7 years. I have, uh, particularly experience with Jetpack Compose as well from last 2 years. I'm certified with Agile as well as, um, doing my AWS training as well with some spring boot. And, currently, I'm working with the application for Zipcar, which is Application in US where we can rent a car, and it's a Avis subsidiary company. I'm currently, I'm working as the lead architect here, and I'm well versed with Kotlin MVVM model, Jetpack Compose, uh, RxJava, RxAndroid, as well as with Gradle plugins, And, um, I'm supporting near about 7 countries currently, and I'll create 7 different bills for different different country with different languages support. Um

Java to Kotlin number, what is the equivalent of Java static keyboard in Kotlin? So, Currently, we are using, um, for Java, for particularly the static. We don't use static keywords in Kotlin. So so we use directly the constant values as well as we use the companion object for, uh, defining the, uh, statics, particularly in Kotlin. So we have constants. We have well, and we have this companion object where we define all those functions as well as that which can be available with different different functionalities and different modules as well. We can define with the, uh, access modifiers as well.

Use of Kotlin coroutine scope in the context of Android view model for network operation. So Kotlin coroutine scope is sorry. So Kotlin coroutine scope is most probably we are using the scope variables for making the observable calls. The coroutine is particularly launching the background task, uh, which is the particular scope of view model or scope of the main application per particular if it is a scope of view model, then it should be once the view model has been or the view has been changed. This particular scope has been, uh, redefined, and it should be you know, the coroutine has been canceled in that particular time. And if you are defining with the application class with the, uh, in the in the application cloud, the scope should be the whole over the application until the application should be canceled. So that is, um, probably, we are using the work manager kind of scopes for defining the, uh, in a background task, which, uh, works on for the whole application.

So primary benefits for profiler tools is mostly when we have these cleaners. Particularly, we use for that, uh, to just for the check of, um, how much the, uh, space or the, uh, heap size we are defining and what's, uh, particularly in the quiz where we are, uh, using these profilers for submitting the images. When we have lot of images, we don't hold those bytes particularly. So use this, uh, profiler to just to check on the heap sizes, and if it is generally, uh, passing all those, uh, objects directly the serializable object directly to different, uh, via bundle to different particular activities or fragment. We use this profiler tool to just for the sake of defining the heap sizes, what are the size we are increasing, or how much the process we are, uh, the actual size is taking up, and how much is it is the how many fragments. Particularly, when we use a nav graph, we have a multiple fragments to be action on that particular item. So we have to hold those particular memories back, and we use this profiler just to clear the particular caches as well as, uh, don't provide, uh, don't call the APIs every time when we have a cache hit particular implementation. So we use this profiler in both. Uh, previously, we used with the, uh, JAVEN. Now we are using with the Cortolin.

Prefer approach to architect a responsive user interface on different Android device size and density using both Kotlin. So, particularly, the UI interfaces is, uh, particularly, I'm using GJETEC Tech Compose for in which the, uh, the UI has been more responsive. And, uh, for each and every devices, we don't have to create, Uh, different, uh, layouts. Coordinate layouts are most most probably we are using previously, uh, for so that we can, Uh, define the particularly the left and right, it's a combination of relative, linear, and all that stuff. But, uh, currently, Uh, with the Jetpack Compose, we are composing that particular layout with the help of the themes as well as the, uh, the button, formats and the styles in eventually in the dead pack compose. So this is more about we are, Enclose those particularly options of defining each and every dimensions and parameters for particularly in Jetpack Compose.

So currently, the merge conflict is we are defining this in a we have a structure of, uh, defining a developer branch, then we have a different different tickets branch, and then we have a master branch where the release has been cut. A so once the developer has done if you are working on different different, uh, tickets with, a, uh, with particularly the, uh, whatever the ticket size it is. And if you're taking a subtask or if you're making this particularly, uh, in different task. We'll create a different branch for that. And once that's particularly, um, the it's reviewed, the code has been reviewed. This particular branch should be merge and, uh, developer branch where, uh, all those developers who are working a it's working on a, uh, same. And once the merge conflict arise, um, we just have, a what are the commits has been made in the previously and of which commit has been making the merge conflict. As well as if something is, uh, has to be reversed, it our in the, uh, cherry pick for that. And if it is, uh, required to be changed, then the the person who is doing this particular conflict. He has to resolve those conflict and merge to a developer branch. And once it's merged to developer branch to be tested thoroughly with a tester, and then, our, uh, we'll merge this particular developer branch to master when we have to create a release build. So developer branch is always up to date for, uh, particularly for application, as well as we are main maintaining the versions as well as the, uh, version properties as well as the, release properties. So, uh, we know which version is to be defined in a developer branch to make a release cut for that.

Examine this Kotlin function which handles tuning a user profile picture within the app. Image URI is not empty. Okay. So image URI So image URI can be an empty string. It can be a null. In this, particularly, if it is a null, we are not handling those null values. We have to define the lead blocks particularly For image, you are right. Because most of the time, when we, uh, capture the image as well, the URL is not, uh, defining because of the heap size. The, uh, define, uh, the phone size has been increased, and we are not capturing the URI. It should be null. So null is the main particularly in this to be handled.

There's a custom view of displaying user badge. However, the budget does not update when the user data change. What could be the missing piece in the following codes in the page on that? Does not update when the user data change. Okay? You're not using the Okay? The observers are there. We are not setting this observables. So in the data class, Batches view user data, set user data, invalidate. And user data, we wanna observe. Set user data. We are observing the data here, but we are not providing the we are invalidate this particular data particularly. So firstly, we have to Remove this invalidate firstly. And if the user data has been we are we don't have to define the set user data here. When it is observing, it should be observed from a view model, not from the, uh, particular view. And, uh, thirdly, This data class has been has to define the new model. We have to change the data. It can be observed, um, automatically, so we don't have to uh, predefine the particular functions to, um, set the user data. So it should be observed from our view model, firstly. It should not be invalidate in that cases, and it should all those particular functionality of a data model should be goes to the new model instead of view. The observables here is just to observe the data, but not to uh, pass the values from

Data binding. Okay. So how this particularly the bindings, the, uh, view binding as well as data binding, we are actually, uh, working closely with this particularly. So it will particularly this data bind we don't have to provide all the data classes that will bind to the particular object models and as well as for the view binding could be same. It will bind to the particular views. Uh, we don't have to provide externally to to particularly which view of which data has to be mined for the data classes? So in this cases, the data the data class has been defined, and we bind those with a a view models, uh, whatever the live data we are going to use in our view models. And once this particularly it been observed in our views, uh, it will, uh, get those particular values in, um, observable form. So we don't have to define every time which view model we are using, which particular data, uh, we are using for the particular, uh, view? So we'll have to define this particular new model. So the boilerplate code, uh, in this, particularly, we have to explicitly define in our view models, uh, whatever the data we have to pass it and observe in our view. So now we have a data binding. So data binding is particularly we that particular data class has been attached to this particular view model as well as to the particular view. So we'll directly get those values that, uh, we don't have to define every time. And, uh, and this particularly has been resulted in a format? We don't, uh, will already handle those null values as well as the values which is going to be empty, uh, in these data classes. So that's why, uh, data binding is reducing our pilot plate codes. We don't have to set and get for the particular the objects. So that's the main reason we are using data binding? As well as the same goes with the view binding. You don't have to define with the, uh, layout

So we use work manager currently here. So we don't have to optimize much morely. So work managers will synchronize whenever the network failures and all that stuff going to happen or any API error file fails. Particularly, work manager will handle those. We'll retry for it. It don't have to, uh, gain call him back and forth uh, every time. So work manager is the best one to synchronize our applications, uh, and reduce the, particularly, uh, the bet, Uh, reduce the calling the, uh, APIs every time and reserve the battery life. Once it's been done, It the work manager is automatically going to be closed in the background. It should not maintain the object. It will Directly clear the object as well as make it null and make it garbage collected.

In what ways can you leverage Gradle and Android to customize the build configuration different product? So we use, uh, so for the release, we have a different flavors. We have a different, particularly, modules. In a Gradle, we are defining this particularly inside the if you have a debug and we have to debug for different different, uh, location. Uh, we use, um, flavored for the particularly, um, like, CA debug or the US debugs, And, uh, particularly, we have to define in a Gradle project. And same goes for the release. We have a different, uh, eventually, we have to define for different, URLs as well. So we have different prod URL as well as dog food or the Doc food or the debug, particularly, we can define in a flavor format, and that's a flavor we are using, uh, just for, Uh, defining the our HTTP concept as well, as well as, uh, for different languages as well, we can define the Gradle properties, uh, which is more about, like, uh, which language has to be taken from this. Just like for e n US, we are using for US debug and US production, as well as, uh, sign in configs we are using for different different flavor builds as well.