ABHIJIT KATARIYA

Hey. Hi. My name is Abhijit Kataria. I'm done with my, uh, MCA science in 2016. Then, uh, I'm having the total year of in Android development of 7.10 years. So in my last organization, I was working for Delta IoT Solutions for the client John Deere. So over there, I have, Uh, work, uh, four and a half years. So as you know that, uh, John Deere is working in agricultural domain, so they are having their own applications for multiple vehicles, uh, related to the agriculture. Right? Tractors, mowers, sugarcane harvester, that kind of applications I work for. So, mostly, basically, the applications are, uh, containing the hardware inside each and every equipment, and we need to communicate those, communicate with these machines to our applications by using the Bluetooth services. And there are some ecommerce kind of applications as well. By using this, user can easily, uh, access to their stores for ordering any, uh, damaged part for their vehicle or any kind of servicing they need. So, accordingly, we'll get, uh, the reminder for the time to time service so that user can easily, uh, maintain their vehicles. Yeah. That's it from my end. And having the other applications, uh, experience in other organization, uh, just previous to this, Uh, then I was working for geofencing, then Google Maps, tracking kind of applications, uh, beacons. Yeah. That's it from my

Okay. So frame layout, uh, we mostly use for the scenarios considering if there are multiple, Uh, layout you need to change on a single screen just having some minor kind of differences. So this kind of you need to do the, Multiple pop ups pop ups, uh, over and over, uh, just in case, uh, when you install the applications. And in that case, you need to ask some, uh, basic questionnaires or some steps you need to follow while using that app. These kind of pop ups, we are showing continuously to the users. So in that scenario, mostly, we use the frame layouts to just do the single screen, and inside that, you will just appear 1 by 1 frames, uh, to the users, whenever they are done with that particular, uh, pop ups of screens. So in a single screen, we'll develop those applications using frame layout. And, uh, and regarding the performance, yeah, it's definitely regarding 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, alternatively in case of overlapping many views, uh, 1 by 1. So it's very hard to maintain constant layout so that What, uh, that's what in a single screen by using the, uh, frame layout, we will achieve these scenarios and, uh, we'll, uh

Okay. So, basically, solid principle we need to follow, and we'll try to get all solid principle to achieve while developing the Android app using Kotlin. So, basically, Uh, the main purpose of solid app, uh, solid principle using in Kotlin, uh, it's like, uh, you need, Uh, single responsible principle we need to maintain, basically, for writing each and every call. 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 as compare, uh, by con considering your functionality. So make sure that you'll write a single, uh, a small code, with the single functionality only. It, uh, it should not merge multiple functionality in a single function so that your code will not break for It generated functionality, and the code is very separately written and segregated. So that's why user, uh, anyone can easily read your code and easily understand as well. And, uh, it's a good practice for, uh, uh, making sure that your code will not break in, uh, any kind of scenario by taking care of this functionality. If in case your code is breaking, then you can just easily, uh, find out where it's breaking. Uh, it's very, uh, helpful for, uh, tracking the any conditions as well if you are get, uh, find found or getting any errors. So user can easily track and, uh, get those error. Then open close principle, we need to follow. Then interface segregation as well. If you are writing, uh, interfaces, Then make sure that if you are writing a common interface, then it should not contain the methods that was not used by the common, uh, classes. Like, I'm writing 1 interface, and in that, I'm writing the 4, uh, methods, And that interface is common for 2 classes. When I implement, then insert so make sure that all the formatters are accessible and used by both the classes. It should not happen that 1 class is using 2 methods and other class is using 2 methods. So that is called the interface segregation as well. Make sure that while writing the interface and make sure that you are just, uh, segregating your interfaces as per your need only. What are the methods you are declaring in that, then it 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 close principle. In both, uh, we need to use, uh, the same procedure. Then dependency inverse principle, we mostly use. Uh, I, uh, I personally, uh, not used that much in my last organization, but, uh, most focus on the single responsible functionality, open close principles, and the integral segregation. These 3 principles are very uh

Okay. So mostly, uh, while writing the code by considering the different screen sizes, In Android and Kotlin, uh, we follow in case of Java, we should follow the constant layout So that, uh, 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 the Jetpack composes by using the different screen sizes in the scenario and most, uh, preferably use the particular architecture while developing your applications. So most widely used and recently used, uh, architecture is MVVM, model view and view model with clean architecture. So that, uh, in case of clean architecture, you need to use the repository classes. You should use those. So because of that, your code is very clean written, and 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, uh, considering your functionalities, then small model for each and every functionality so that your code is written in a uh, manner that, uh, 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 come it's very, uh, less time computer consuming, uh, 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, uh, you are using the Jetpack compose or constraint layout or, uh, any kind of layout by considering the, Make sure that that app is work 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, uh, simple to use this As there are, uh, 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, uh, weight concept over there. So while developing your Screens. You need to make sure that you are, uh, you are dividing your screen as per your layouts and your views accordingly by using the, uh, weight concepts over there. So it is very, Nice to, uh, 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, so benefits of this, you can easily track your application, how much load your application is taking while each and every functionality he's doing, right, I'm, uh, right, still you are considering if you are creating the 2,000 objects and your, uh, profiler is showing your app is in very, consuming very high RAM or high memory so that your application gets ARR kind of errors or a runtime exception for taking the, uh, index out of bound or memory leak, this kind of operation, uh, errors, you should not get. So you can just check, uh, each and every function, it'll have the operation you have made in your application. So just check-in the profiler how much load your app is taking in case of memories or the RAM, which is used by that functionality so that you can just, uh, check any alternative solution for that. If there is any alternative or better solution for that, uh, so that it can just reduce this profiler or memory usage so that, uh, user cannot, uh, get at runtime errors like memory leak and ANR app not responding, these kind of errors. So 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 of period or long tasks such as if you're hitting the API and getting lots of data from server and then using it in the app by putting it in the database, such a 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 other there is a high proficiency or high, uh, usage of these memories and RAM while doing such a kind of operation, then we will just find the alternatives for these situations, and you can, uh, get a better solution and then, again, check, uh, this profiler scenarios in Android Studio. So it's very benefit beneficiary for the user for taking, uh, 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 are continuously taking the latest code from your main repository in which you are trying to merge your code. So your code should be updated with the latest branch so that you will get Less conflicts, and it's very common for each and every developer to make sure that you are taking a latest code every time before making any PRs so that you will get less conflicts and you will just compare with Whatever the changes you have made and whatever the common changes which is present in the, uh, your main branch or top branch. So it can easily get understand. So what conflicts you're getting. So accordingly, we'll just make changes. If your changes, we need To override with the main branch, then you can just take your changes or just remove your changes and take their changes. So it will very useful that you are continuously update with your main branch or parent branch so that you will get less conflicts while collaborating in a large scale project in Android Studio. So it's very useful and need to take care of this main scenario. You are continuously upgraded with your parent branch uh

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

Actually, I don't, uh, having that much of experience in HMI. So I'm not sure about this particular scenario. So sorry for that. I need to just explore some, uh, basic concept on this, and then I will give you the better answer for that. I don't have any hands on exposure in last organization or did not work that much. I'm skipping this

Okay. So For optimizing the data binding, when I reduce the boilerplate code, so basically follows the Solid principle so that we can just use the common codes for single responsible principles by using this, by segregating the interfaces. So we'll make sure that your code is not getting duplicate for each and every classes. We are just using the common course. So for that purpose, we use some kind of share view models as well for sharing the same code between the multiple classes, but make sure that it's not breaking the functionality. Then, uh, for data binding, we use the dependency injections. By using this, you can just, to remove your boilerplate code as well. So dependence 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 your code from Java and Kotlin by using the add JVM annotation. By using this, we use your Java code in Kotlin and in Kotlin, uh, and vice versa.

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

So while connecting with stakeholder or clients, so make sure that you are considering all scenarios, All normal or minor or major. Any kind of cases, you should need to think on it before. And then while connecting with stakeholder, then make sure that all the major cases and minor cases are covered so that you will not get continuous changes on this. If the changes are continuously you're getting, then, uh, take a call and finalize one scenario, what kind of changes we need to take care so that, uh, it will, uh, not It should not, uh, go in a way that your multiple developers, uh, need to invest their time in that. So it Totally the waste of time and, uh, waste of cost as well for each and every developer and as well as stakeholders as well. So it's a loss for both ends. So make sure that the requirement should be very clear and proper manner so that it will not, in a case that you sure you need to change your code base accordingly and continuously at the last moment. So it's very hard When you are at the end, then you should need to, uh, do the major changes in the rollback kind of. So that kind of scenario should not be happen, then make sure that while starting your project only. So make sure that all the requirements you are having, That should be in the proper documented so that you can just connect with stakeholder that time. And if It's taking a lot of time, then we should need to take this stakeholder. It will more take time because the requirement we are having at the start is totally different from what we are, uh, discussing, uh, right now. So better way, everything You are discussing while starting your project, so it should be in a proper documented.