Dheeraj Giroti

Hi, I'm Dheeraj Giruti. I have 11 years of experience in the Android domain, and I've been working with Kotlin for the last 7 years. I have particularly extensive experience with Jetpack Compose, which I've been working with for the last 2 years. I'm certified in Agile and am currently pursuing AWS training as well as studying Spring Boot. Currently, I'm working on the application for Zipcar, which is an application in the US that allows users to rent a car; it's a subsidiary of Avis. As the lead architect here, I'm well-versed in Kotlin's MVVM model, Jetpack Compose, RxJava, RxAndroid, and Gradle plugins. I'm currently supporting near about 7 countries and will create 7 different bills for each country, with support for different languages.

In Kotlin, the equivalent of Java's static keyword is the companion object, as you mentioned. We can define constants directly and use the companion object to define static functions and variables. We can also use access modifiers to control access to these static members. 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 functionalities and different modules as well. We can define with the access modifiers as well.

So Kotlin coroutine scope is most probably we are using the scope variables for making observable calls. The coroutine is particularly launching the background task, 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 redefined, and it should be the coroutine has been canceled in that particular time. And if you are defining with the application class with the application context, the scope should be the whole over the application until the application should be canceled. So that is probably, we are using the WorkManager kind of scopes for defining the background task, which works for the whole application.

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

Preferably, an approach to architect a responsive user interface on different Android device sizes and densities using both Kotlin is as follows. So, particularly, I'm using Jetpack Compose for which the UI has been more responsive. And, for each and every device, we don't have to create different layouts. We're most probably using Constraint Layout previously, so we can define the layout's dimensions and parameters. But, currently, with Jetpack Compose, we're composing that particular layout with the help of themes, buttons, formats, and styles. So, this is more about enclosing those particular options of defining each and every dimension and parameter for Jetpack Compose.

So currently, the merge conflict is that we're defining this in a structure of defining a developer branch, then a different tickets branch, and then a master branch where the release has been cut. As soon as the developer has done working on different tickets, with a particular ticket size, and if you're taking a subtask or making a different task. We'll create a different branch for that. And once that's reviewed, the code has been reviewed. This particular branch should be merged into the developer branch where all the developers working on the same thing. And once a merge conflict arises, we just have to look at the commits made previously and the commit that caused the merge conflict. As well as any changes that need to be reversed, we'll do a cherry pick for that. And if it's required to be changed, then the person resolving the conflict has to resolve it and merge it to the developer branch. Once it's merged to the developer branch, it's tested thoroughly with a tester, and then we'll merge this particular developer branch to master when we have to create a release build. The developer branch is always up to date for the application, and we're also maintaining the versions as well as the version properties and the release properties. So we know which version to define in the developer branch to make a release cut for that.

The candidate is discussing a Kotlin function that handles tuning a user profile picture. Here is the corrected transcript: Examine this Kotlin function which handles tuning a user profile picture within the app. The 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 logic blocks particularly for handling image, you are right. Because most of the time, when we capture the image as well, the URL is not defined because of the heap size. The phone size has been increased, and we are not capturing the URI. It should be null. So null is the main case 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 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 observable. So in the data class, batches view user data, set user data, and observe user data. Set user data. We are observing the data here, but we are not providing the data to invalidate this particular data. So firstly, we have to remove this invalidate. And if the user data has been changed, 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 particular view. And, thirdly, this data class has to define the new model. We have to change the data to be observed automatically, so we don't have to predefine the particular functions to set the user data. So it should be observed from our view model, firstly. It should not be invalidated in that case, and it should have all those particular functionalities of a data model go to the new model instead of the view. The observables here are just to observe the data, but not to pass the values from the view.

Data binding. Okay. So how this particularly the bindings, the view binding as well as data binding, we are actually 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. We don't have to provide externally to particularly which view of which data has to be mapped for the data classes. So in these cases, the data the data class has been defined, and we bind those with a view models, whatever the live data we are going to use in our view models. And once this particularly it has been observed in our views, it will get those particular values in observable form. So we don't have to define every time which view model we are using, which particular data we are using for the particular view. So we'll have to define this particular new model. The boilerplate code in this, particularly, we have to explicitly define in our view models, whatever the data we have to pass and observe in our view. So now we have 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 we don't have to define every time. And this particularly has resulted in a format. We don't have to handle those null values as well as the values which are going to be empty in these data classes. So that's why data binding is reducing our boilerplate codes. We don't have to set and get for the particular 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 layout.

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

In what ways can you leverage Gradle and Android to customize the build configuration for different products? So for the release, we have different flavors. We have different modules. In Gradle, we define this particularly inside the build type, where we have a debug and we have to debug for different locations. We use flavors for the particular, like, CA debug or the US debugs, and we have to define in the Gradle project. And the same goes for the release. We have a different URL, and eventually we have to define for different URLs as well. So we have different prod URLs as well as debug URLs, and that's a flavor we are using, just for defining our HTTP concept as well as for different languages. We can define Gradle properties, which is more about which language has to be taken from this. Just like for US, we are using US debug and US production, as well as sign-in configs for different flavor builds.