Manju Krishna Nanjappa BalaKrishna

Can you help me understand about your background? You gave me a brief introduction. Yes, my introduction would be like this: I'm a senior Android developer. I recognize myself as a senior Android developer. I have played an architect role in designing, developing, and also refactoring the code. We also engaged in client or stakeholder meetings, where I had to convert their requirements into code. I split the code or requirement into smaller tasks and submitted POCs for that. Then I assigned the tasks to junior resources and trained them. I also have acted as an individual contributor. I've worked on a team of 10. This is how my role goes.

How would you prevent an ANR from occurring? Basically, an ANR is an application not responding. So it usually happens when you hold a UI thread for more than 5 seconds. So any large tasks or long operations you want to do. Basically, you can do it in a separate thread. And today, I think, we have coroutines, where we can run coroutines on different dispatchers. One is IO, one is main, and one is default. So by doing this, I think, you can avoid the ANR problem.

So, basically, if you want to reuse a UI component, you can create a separate XML file. And then you can include those XML files, which you think can be used in many other places. And, also, if there are certain UI components that you think can be reused, you can make it as a separate XML, and then you could start including those XML into the actual XML code that you write. So if you're writing a main activity, you can have some sub XML, and then you can include those here. Also, you can use themes. You can use styling. Okay. And all these things, you can use where you think there are certain components that can be reused. So break it into small components and keep it as a separate XML. When you require this, you can include that as a part of the main XML that you want.

So, basically, if you want to secure your data and SQLite, you can use AES encryptions. You can encrypt the data and keep it in the SQL, and whenever you want to use it, you can decrypt it and use it. And so in that way, you can usually protect your data. If you want to see, basically, when you look at any Android application, it is isolated in a sandbox. So, it will maintain a different SQLite. Okay? So, when you're giving access to outside the application, we usually use content providers earlier so that it provides a secure way of giving access to the SQLite. If that's not required, if you don't want to share your data with anybody, then you can encrypt the whole data and keep it, and apply SQL.

So there are many profiling tools that you can use. Actually, today, you can see that you have the profiler. You have a profiler for network in Android Studio, a profiler for battery, a profiler for memory, and a profiler to check your UI. You have different profilers. What you can do is when you create an application, you can run the profilers. So if I take an example of a thread, say a particular UI is very slow. The first thing is to look at the hierarchy URL and see if there's any load that's taken. We should avoid any nesting. Once we do that, we go into the memory profiler and see if there's any memory leak happening. The third thing is the systrace. We use that to check if there's any overloading of the threads, and then we can partition that or load the work on a different thread. You know, all this profiling allows us to see whether the app is running efficiently. Also, I believe today that we should have a single responsibility for every class we create, so that we don't define multiple tasks in one particular class. We can split those responsibilities to different classes, so that we can reduce the responsibility on each and every task.

To migrate an existing Java application, so if you want to migrate an existing Java placed application, we use Kotlin based extensions, where you can add those. So, it's like, what I would do is, probably, I have to see. I'm just thinking, you know, what is the right way to do it? I'm not getting this correct statement on this. So I want to skip this question. Okay, I want to skip this question.

Consider the below Java code center. Can you identify this? Okay. So, basically, it is, well, you can see this is HTTPS, which is missing. It's a plain text that you're sending. So that is one of the security Android security issues. Can you identify the issue related to Android security? Yeah. 1 is this, My web load URL, you know, is not secured because it's a plain old HTTP. HTTP is not the most secure way of loading the URL. We need to use HTTPS for the most secure way of loading the URL.

Alright. The database. Basically, this is adding values, you know, it's inserting values to the table. And, it's inserting values to the table, and then it's closing the database connection.

How do you implement error handling strategies to handle how do you implement error handling strategies? So, how do you implement error handling strategies to handle network volatility in an Android app? So, basically, when you're working with the network, you can initially see the read timeout. You know, once you've made a request, you can see if the request has happened. And if the request is not happening or if they're not getting any responses, you need to disconnect the particular session and report it back to the user. Another way to handle volatility is to check for network connectivity in your code. When there's a disruption in the network connectivity, you need to report it back on the UI, telling the user that the network has disconnected or they're offline. You can observe this on YouTube and other platforms, right, when you're watching, and if there's no network, you can identify the change in network using a network class or the system services' network services. You can get system services for the network and identify the change in network. If there is a known network, then you report it back to the UI. And that way, you can make the network stable. You can also just switch to a different network if there's no connection on Wi-Fi. For example, if Wi-Fi is connected, you can move back to your SIM-based or mobile network.

How do you manage the condensation and algorithm? So, basically, when you're managing your network dependency injection, right, so you can add the dependency injection in a common file. Right? So you need to maintain a common file, so that whenever you are including a dependency, so what you can do is you can maintain a normal repository, and you can just add that dependency there. So if somebody is working on a different repository, he can also include that file there. So when you're building, you can see what are the different dependencies that people are having. If any dependency is already present, you can reuse it. You don't have to declare the dependency again. In this fashion, you can manage the dependency across the application, so you need to maintain it as a common file, like on the view model, you know, there is a dependency. I would add it in a common file. In a repository, when you're developing a repository, you can add it as a common file. That's where all the dependency sits. So in this fashion, you can see that your dependency will not get duplicated, and you can maintain the dependency across the app.

So, basically, RS or ProGuard, you know, is on the Gradle file. You need to enable ProGuard and RS on the Gradle file. And then when you're building your application, it will get processed and the RS can be applied there.

What is your experience with Git for branching, merging, resolving conflicts in Gong? So, basically, every Git is a common repository that we all have, which is a code repository. The way we can manage it is that whenever you want to develop a feature, you can create a branch out of the main. So you have a develop branch, and then you branch out of that to create a different branch for your particular feature. Once you complete that feature, you can commit that particular branch back to the main and push it to the Git. Once you push it, you need to raise a PR where people will review your branch. And if there's any review comments, you fix the review comments, and then commit it back to the develop branch.