ABHIJIT KATARIYA

Hi. My name is Abhijit Kataria. I completed my MCA in science in 2016. Then, I have over 7.10 years of experience in Android development. So, in my last organization, I worked for Delta IoT Solutions for the client John Deere. Over there, I worked for four and a half years. As you know, John Deere operates in the agricultural domain, so they have their own applications for multiple vehicles, including tractors, mowers, and sugarcane harvesters, among others. So, mostly, the applications contain hardware inside each equipment, and we need to communicate with these machines using Bluetooth services. We also have ecommerce-type applications, allowing users to access their stores for ordering damaged parts or scheduling servicing. This way, we send reminders for timely service, enabling users to maintain their vehicles easily. That's it from my end. Additionally, I have experience with other applications in a previous organization, where I worked on geofencing, Google Maps, and tracking applications with beacons.

So frame layout, we mostly use for scenarios considering if there are multiple layouts, you need to change on a single screen just having some minor kind of differences. So this kind of scenario, you need to do multiple pop-ups, pop-ups over and over, just in case, when you install the applications. And in that case, you need to ask some basic questionnaires or some steps you need to follow while using that app. These kinds of pop-ups, we are showing continuously to the users. So in that scenario, mostly, we use the frame layouts to just do a single screen, and inside that, you will just appear one frame at a time to the users, whenever they are done with that particular pop-up of a screen. So in a single screen, we'll develop those applications using frame layout. And regarding the performance, yeah, it's definitely about the performance because in a single screen, you'll manage that. But in case of constraint layout, you need to manage all your views according to your constraints, and it's very difficult to manage this constraint, especially in case of overlapping many views. So it's very hard to maintain a constant layout, that's what in a single screen by using the frame layout, we will achieve these scenarios and we'll

So, basically, solid principle we need to follow, and we'll try to get all solid principles to achieve while developing the Android app using Kotlin. So, basically, the main purpose of solid principles is to achieve while developing the Android app using Kotlin. The main purpose of solid principles using in Kotlin is that you need to maintain the single responsible principle for writing each and every class. We'll make sure that your functionality is only single responsible. If you are writing code for sign in, then it should not contain the functionality of sign up page as well. So your code is very tightly segregated compared to considering your functionality. So make sure that you'll write a single, small code with the single functionality only. It should not merge multiple functionalities in a single function so that your code will not break for generated functionality, and the code is very separately written and segregated. So that's why users can easily read your code and easily understand as well. And it's a good practice for making sure that your code will not break in any kind of scenario by taking care of this functionality. If in case your code is breaking, then you can just easily find out where it's breaking. It's very helpful for tracking any conditions as well if you are getting any errors. So users can easily track and get those errors. Then open/closed principle, we need to follow. Then interface segregation as well. If you are writing interfaces, then make sure that if you are writing a common interface, then it should not contain methods that are not used by the common classes. Like, I'm writing one interface, and in that, I'm writing four methods, and that interface is common for two classes. When I implement it, then I should make sure that all the formatters are accessible and used by both the classes. It should not happen that one class is using two methods and the other class is using two methods. So that is called the interface segregation as well. Make sure that while writing the interface, you are just segregating your interfaces as per your need only. What are the methods you are declaring in that, then they should be used by that particular class, each and every method. So, accordingly, you need to use this principle. It's called as interface segregation or open/closed principle. In both, we need to use the same procedure. Then dependency inversion principle, we mostly use. I personally not used that much in my last organization, but most focus on the single responsible functionality, open/closed principles, and the interface segregation. These three principles are very

Okay, so mostly while writing the code considering different screen sizes, in Android and Kotlin, we follow in case of Java, we should follow the constant layout so that we are just maintaining each and every screen size the app will go in a flow. And in case of Kotlin, we'll manage by using Jetpack Compose by using different screen sizes in the scenario and most preferably use the particular architecture while developing your applications. So most widely used and recently used architecture is MVVM, model view and view model with clean architecture. So that in case of clean architecture, you need to use the repository classes. You should use those because of that, your code is very clean written, and the user can easily differentiate your main functionality and your background functionality and to update your UI accordingly, then use the view model as per as much with your considering your functionalities, then a small model for each and every functionality so that your code is written in a manner that you can easily find your breakpoints if there is any. And anyone can easily understand your code in a better way and better shape and start writing their own code as well. So that's very time-consuming it's very less time-consuming the way of writing the code. So do make sure that you are writing the code in a particular MVVM or MVP architecture by considering the clean architecture in Kotlin, and make sure that you are using Jetpack Compose or constraint layout or any kind of layout by considering the app is working on different sizes accurately without interfering or without disturbing the UI. So we need to take care of this thing while developing in XML or Jetpack Compose. In Jetpack Compose, it's very simple to use this as there are the preview option is there, so you can just check your application in multiple screens as well. And in case of XML, you need to make sure that you are using the weight concept over there. So while developing your screens, you need to make sure that you are dividing your screen as per your layouts and your views accordingly by using the weight concepts over there. So it is very nice to work or work your application in multiple screens by considering all the scenarios without affecting your UI in different screens.

Okay. So by using the Android Studio profile tool in Java and Kotlin, the benefits of this are that you can easily track your application, how much load your application is taking while each and every functionality is doing, right. You're still considering if you're creating 2,000 objects and your profiler is showing your app is consuming very high RAM or high memory, so that your application gets ANR kind of errors or runtime exceptions for taking the index out of bounds or memory leaks. You shouldn't get these errors. So you can just check each and every function, it will have the operations you have made in your application. So just check in the profiler how much load your app is taking in case of memory or the RAM used by that functionality, so that you can just check any alternative solution for that. If there is any alternative or better solution for that, so that it can just reduce this profiler or memory usage, so that the user cannot get at runtime errors like memory leaks and ANR app not responding, these kind of errors. The profiler is very helpful for checking your app performance in runtime for each and every background task you have made, which is taking a long time or long tasks, such as if you're hitting the API and getting lots of data from the server and then using it in the app by putting it in the database, such kind of operations. You need to take care of how much memory and RAM your app is using while doing these operations. If your profiler is showing there is a high proficiency or high usage of these memories and RAM while doing such a kind of operation, then you will just find the alternatives for these situations, and you can get a better solution and then, again, check this profiler scenarios in Android Studio. So it's very beneficial for the user for taking such a kind of long operation or heavy operation you are doing in your app.

Okay, so while merging the conflicts, we'll make sure that you're continuously taking the latest code from your main repository in which you're trying to merge your code. So your code should be updated with the latest branch so that you get fewer conflicts, and it's very common for every developer to make sure that you're taking the latest code every time before making any PRs so that you get fewer conflicts and you just compare what the changes you've made and what the common changes are present in your main branch or top branch. So it can be easily understood. So what conflicts you're getting. So accordingly, we'll just make changes. If your changes need to be overridden with the main branch, then you can just take their changes or just remove your changes and take theirs. So it will be very useful that you're continuously updating with your main branch or parent branch so that you get fewer conflicts while collaborating in a large-scale project in Android Studio. It's very useful and you need to take care of this main scenario. You are continuously updated with your parent branch.

So in this scenario, if you are doing any background applications or you're doing any background operations like saving this image in a database or this kind of operation, you make sure that you need to do this operation in a suspend function while using Kotlin. And make sure that if you're checking the image URI, it should be in a string format, then you can just check it's not empty or anything. But if you're doing operations on a database for storing your image, then getting those images from the database and showing in your particular image view, it should be on a different thread. And while showing any error, you need to make sure that you are switching your coroutine context from a background thread to the main thread so that you can easily update your UI. By doing the background operations in a database or any network operations, you need to make sure that you are doing these operations in a coroutine with suspend functions.

I'm not familiar with HMI, so I'm not sure about this particular scenario. I apologize for that. I need to explore some basic concepts on this, and then I'll give you a better answer. I don't have hands-on experience in my previous organization, and I didn't work that much.

For optimizing the data binding, when I reduce the boilerplate code, basically it follows the Solid principle, so we can use common codes for single responsible principles by using this, by segregating the interfaces. We'll make sure that our code is not duplicated for each class. We're just using the common course. So for that purpose, we use shared view models to share the same code between multiple classes, but make sure it's not breaking the functionality. Then, for data binding, we use dependency injections. By using this, you can remove boilerplate code as well. Dependency injection is a better way for data binding as well, Dagger 2. And in Java and Kotlin, we use some extensions so that we can easily migrate our code from Java to Kotlin by using the @JvmName annotation. By using this, we can use our Java code in Kotlin and vice versa.

There is a concept in Jetpack Compose, horizontal scrollable and vertical scrollable. By using this, you can just make your list scroll vertically and horizontally. It's very easy to maintain this kind of scenario in Jetpack Compose. Yeah. So in that, there is no need to use the adapter we use in Java. So in Jetpack Compose, we use those horizontal and vertical scroll concepts. And inside that, you can just make your list.

So while connecting with stakeholders or clients, make sure you're considering all scenarios, both normal or minor or major. Any kind of case, you should think about it beforehand. And when connecting with stakeholders, ensure that all major and minor cases are covered so that you won't get continuous changes. If changes are continuous, take a call and finalize one scenario, considering the kind of changes you need to make so that it won't go in a way that multiple developers need to invest their time in it. This would be a total waste of time and cost for each developer and stakeholder. It's a loss for both parties. So make sure the requirement is clear and well-documented so that you won't need to change your code base at the last minute. It's very hard when you're at the end to make major changes in a rollback kind of scenario. So, make sure that while starting your project, all the requirements you have are properly documented so that you can connect with stakeholders then. And if it's taking a lot of time, we should take this stakeholder. It will take even more time because the requirement we have at the start is totally different from what we're discussing right now. So, the better way is to document everything you're discussing while starting your project.