Abhishek Kumar

Sorry. Currently, I'm working at ShareChat. Uh, so I joined ShareChat 2 years back in 2021. When I joined, I joined, uh, I joined, uh, in consumer experience board. And, uh, like, uh, the task Ask of consumer screen point is to take care of all the all the screens related to to to consumers and, uh, act like, Uh, enhance the UI and UX of consumer. So, uh, initially, I started working on the profile. So the code base of profile was written in 2017, 28/8. And it was in MVP architecture using Java. So anything that we, uh, we thought to, you know, uh, change it was very hard to change in that code base. It was very complex. So, uh, my task was to design profile using Jetpack Compose and, uh, in MVVM architecture. So, uh, so I started working on it from scratch. Uh, I worked on that and, uh, using Jetpack Compose and the MVVM architecture. Uh, apart from consumer experience board, I've also worked with the onboarding part of. In onboarding, I my task was to, uh, implement something called silent authentic authentication, uh, using which, uh, we reduced the OTP cost, Uh, like, which which we use to send to users. Uh, so and before I was working with the It was a utility based startup based out in, uh, Bangalore. So my task was to perform, uh, like, Create a application from scratch named under pi, uh, I a video downloader, which is available on Play Store. And also, uh, also, uh, like, I was, uh, maintaining their application called Pie Music Player, Which you which had around 50,000,000 plus users. Um, and my task was to perform. It was a music player. So I used to fix all the bugs. Uh, I improved their ANR rate from 99.2 to 99.9. Uh, and, Like, I started my journey at 2017. Uh, in like, uh, after after my just after my college, I, Uh, worked in a startup in Hyderabad, which was a very early stage startup. So, uh, like, Which was a early at least a startup, and I was a stand alone developer there. Um, I I created this, uh, application from start

Uh, just try to chase and deploy it to manage. So when we talk about state, We talk about UI state. Uh, we can use m v MBI architecture. Using MBI architecture, what happens is intent goes upward from view to view model and, uh, uh, like, uh, view model sends this intent to to model, uh, repository to take care of it. Once the data is data is back from repository to ViewModel, it The model creates the state and gives back to the UI. So this using MBI or MVVM architecture, we can we can, We can do it pretty easily. And, of, uh, of course, like, uh, if we are using Jetpack Compose, in that case, we have to, You know, use stateflow. Even with the even with the XML, we can use stateflow and we can observe this stateflow in our composables or or, uh, in our overridden method. And so so whenever there is a state change in the in the view model, It will be observed in the in the in the view, be it composable or view. And then we can we can change the UI. And also, we can we can use something called sealed classes, uh, to store these states. So sealed classes will Can have 3 state, uh, like, I'm giving just an example. Uh, 1 is loading state, 1 is the data state, and 1 is added state. Suppose you are you tap on 1 something to you give give us some intent to remodel. Um, and so initially, the loading state UI will be in loading state. And, uh, once the data is back from repository, uh, ViewModel will update the state from loading to data state, and the UI will be changed. And if there is any issue or there is any, uh, error from the repository in that case, Your model can, um, update the UI from data loading state to error state and, uh, uh, uh, data UI will be changed according to that.

How is code testing? So, uh, so in Android development, uh, what happens is, uh, we we can write unit test unit test cases, In all the projects that I have written, the, uh, you test coverage was around 85 to 90%. And so what we can do is we can mock, uh, some of the mock mock, uh, we can use Makito And the j unit, uh, and using marketer, we can mark our classes or repository or, uh, uh, or anything. And, Then on top of it, uh, we can use do return, do error. Uh, these APIs on on this. Uh, so so whatever, like, suppose we are mocking some class and, uh, there is some function in the view model which we want to test. In that case, we'll be writing, uh, the cases, uh, and, uh, you know, Like, uh, whenever whenever the method succeeds, in that case, we will be doing something with the do return method or Do next to do return. And also, uh, to do, uh, like, uh, they they are multiple type of test. Right? Unit test using market And all you can you can fake, uh, classes. You can create fake classes or you can mock classes and do unit testing. Uh, apart from this, we also have something called UI testing using we used to use Maestro, uh, to do UI Maestro Aspresso to do UI testing. And this, uh, we used to provide, uh, you know, um, API mocks, API marks for different APIs and, uh, different server APIs. And, uh, like, um, we used to, uh, you know, Provide automated, um, like, uh, YAML classes where, As soon as there is some screen that loads, uh, it gets the, uh, mock data, about your, uh, API data, and, uh, then it, uh, does test its integration test or your, uh, UI test.

So, uh, and there are different, uh, consideration you can, uh, take into account when implementing dependency injection. So we in Android, we have both Dagger. We have Hilt. We have coin. Uh, so, uh, uh, I've been using Dagger and Hilt in I in my project to do dependency injection. Uh, so we have uh, we have. So in Dagger, suppose we have component to, um, so, uh, which, uh, like, we have component uh, and which we define in our application class. So and this creates our dependency graph. Uh, uh, so and, uh, like, in this component itself, we provide the different modules that we create, uh, and this creates the dependency graph first. So now now suppose and one of the consideration you can take is, uh, suppose you have login component, uh, which should be available only when only until the login is not done for a user. In that case, uh, you can you can uh, keep that instance of login component alive only until that point. Once the login or sign up is done, that login component should not be there in the, uh, uh, uh, should that instance has to be nullified. So in that case, what we can do is you can create a subcomponent. And, uh, using subcomponent, you can create uh, subgraph inside the parent graph. Okay. How you can do it is you can create a subcon component. Some component is just like component. Uh, uh, and, uh, you can you can just like the component, you were any instantiating component inside your application class. Uh, that's how that the instance was, uh, available throughout the app application life cycle. You will create this some component in your, uh, in your login activity, uh, um, so that, uh, the instance will be alive only when only until the login activity is alive. When the login activity is, uh, destroyed, uh, this instance of subcomponent will also be destroyed. Apart from this, when you are creating a multimodular, uh, one more consideration that you can make is when you when you're creating multi modular project. In that case, also, uh, you need to provide dependencies for different components, um, uh, to these different modules. Uh, one thing that you can consider right now is, uh, different components should have different scope. Uh, so you need to uh, see which is which, uh, uh, which which repository or class is singleton, uh, and should, uh, should be available throughout the life cycle of your on which should be available, uh, for the life cycle of your activity. Um, so according to that, you can provide uh, different scope like singleton scope or activity scope for your, uh, for your, uh, uh, classes or component.

Yeah. So, um, to manage your application history installation after process that in, uh, Android, so we have so, Um, although we have, uh, view model with us, but, uh, uh, but if the process that happens in Android, Even the model is destroyed. So in that case, we, uh, we, uh, we rely on on saved instant state and on restored method, um, of, uh, of Android. So what happens what happens is that Whatever bundle, uh, our data that you provide to that bundle in on state saved instant state, uh, method, um, that, that data, um, is is it's stored outside of your process, uh, application process. And when whenever your, uh, your application process is recreated again, in that case, that data will be using some inter process communication. That data is given back to your process. And, Using on restore instant state method, you can get back, uh, to that data. Even inside the view model, we have something called saved, uh, state handle, And whatever data that you get inside, uh, on create or on restore instant state method in in those bundle, Uh, that same data will be available to view model also using a saved instant saved state handle, uh, uh, bundle. So using this, you can you can manage the application and store

How do I approach writing unit test for a complex Android feature? So to write the unit test, it's the same thing. Uh, so if your, Uh, feature is complex. In those cases, uh, there will be different repository, different, uh, classes, helper class, and all that you would have created? You have to provide mocks or fake implementation for those. Um, so using Makito library, you can provide mocks for the for those classes? Uh, or you can you if if there is any abstraction, you can create a fake implementation of that abstraction, and, Um, you can provide that using fakes. And you can you can also use stops And I'll to provide your dependency. Once those are available, uh, you can use these to, uh, you know, run, uh, different methods to do unit testing. So now one more thing that you have to consider is, Uh, suppose you are you are, um, have you have created a a database. In that case, you have to write unit test on the Memory of so you should be considering that, uh, your database will be available until The memory is alive. So you you'll you can you can use the API. The the do do do do do provide different, uh, APIs. One one of the API, uh, um, just keeps the the room data is alive until the application is alive. So you can create those. Now so if the feature implement, uh, implementation is complex, in that case also, Um, uh, you can have a different module itself for for your feature, uh, unit test purpose. So different, uh, things can be provided from that.

Here, I feel see, you are creating config builder, uh, instance here. Okay? And on that instance, you are, um, in this code base in the in this code snippet On the instance of config builder, we are calling set feature enabled method. Now if you see the The code, set feature enabled doesn't, uh, return anything. But we are, Uh, you know, um, uh, on set feature enabled method, we are again writing Build, uh, we are calling build function, which is not possible actually. Uh, until and unless we we can We can run build function only on the instance of config builder, uh, config builder. We cannot run build, on set feature enabled method. So here, uh, to run build, we have to use something called builder pattern here where set feature builder has to return the instance of config builder itself. Only then the build method which we are running on set feature enabled method will be possible. Otherwise, It do it is not even possible. It will through, uh, compile time error.

We have Kotlin singleton here. And we have counter, intCounter, and a function. And in the function, we are incrementing the counter. So here, one thing I can see it can happen is, uh, in the multithreaded environment, 2 threads, 1 thread can, uh, try to access counter, uh, field. And, uh, another thread, they can try to, you know, try to increment the counter value. And both When when the 2nd thread is trying to increment the counter value counter value, uh, the 1st thread might get the wrong, uh, unassigned or wrong value for counter. This, uh, might be an issue that can happen in here.

So, uh, to, uh, to architect an Android application to adapt for multiple screen sizes and resolution, What you can do is, uh, whenever whenever there is a there is a, there is a, uh, image or there is any drywall that you are creating. In those those cases, you could Create those driables in different resolutions, uh, using SDPI, MDPI, uh, x dpi, um, and all. Even for resolution, you can use 360 as, uh, 3 6480, um, uh, 240, uh, DP, uh, resolutions. So So what happens is at the run time, uh, run time, what can happen is, uh, whatever be the Whatever be the actual, uh, device on which this application will be running on, um, at the run time, it will At as per the resolution and screen size, um, it will select the that particular dryable. Um, suppose the Screen, uh, the devices support is supporting x x h t p I, um, uh, image and or driver. And if you have 4, 3, 4, uh, drive rivals for a particular rival, v two, l dpi, x l dpi, m dpi s s dpi. In that case, it it can directly access the h dpi and, uh, the resolution will be as per the device. Same for the screen size. We can have a 360, 480, um, and, uh, uh, 240 DB images where, um, as per the device screen size, it will adapt to the it will directly access that particular image Which you adapt those, uh, phone size.

What steps do you follow when you create a new feature branch? Or an Android app in collaborative See, whenever you are creating a feature branch in Android, One thing, uh, whenever you are creating this feature branch in Android, uh, your feature branch, Whatever classes, uh, or, uh, dryable or module that will you will be creating, first, you have to, You know, push the code for that. Uh, uh, And once the code is pushed, then only you should start, uh, you know, uh, accessing that particular module from, uh, different modules. So so when you do this, what happens is, Suppose when you do this, what happens is, um, uh, everyone will have the code when you are accessing

Have you interacted with any real time database? I did I did have, uh, I have interacted with the real time databases using, uh, database inspector Inspector. Um, so you connect your device and, uh, whatever debug, uh, APK that you have in your device. Um, if, uh, the database for that is not encrypted, you can directly access, uh, those database. If you are using Zoom database, it's so you can directly access. If you are using SQL and C4, you might not be able to access it directly. You can still do it using some hacks