Kedar

Yeah. Hi. My name is Kedarnagekar. So I started iOS development with the internship. Then I started working in the same company. Since it's a service-based company, I got the chance to work on different apps, like a video editing app, news apps. I worked there for around a year. Then I joined this company called FlipBar, which is into the travel domain. They had their app called Flippar Go, where users can see the places nearby. Code API in Bangalore will show you the carbon park, Lal park, which is the nearest point of interest. Once you click on a place, it will show you the relevant information, like images, videos, audio, etcetera. However, we were doing things differently, using augmented reality. I had a chance to work on different AR experiences, like sticky videos, an audio player in AR, etcetera. Then I started working in Kahya Technology. They were mainly into the Bluetooth and IoT domains. If you have any smartwatch, you need to connect it using the board crash app. We would fetch the user's data from the watch and show it in the app, then upload it to the servers. I had the opportunity to review others' code and take interviews sometimes. I also have experience in IoT and Arduino platforms. It's like assembling different hardware and programming it, and so on. I made a small robotic car that I could move from the app. I could move the car forward, left, right, etcetera.

Yeah, I think that's it. I think we can use the keyword, no, week or the basically, the unknown. So if we can break the return cycle using the weak keyword. So weak is like an option if there is an optional value. And unknown, meaning we always know there is a value to the variable. So, yeah, using the weak and unknown, we can.

award the return cycles. Yeah. I would definitely prefer to start with the MVN. No. It's easier to use once you know it, and it's easily scalable. And the one thing I tried to do now is start one habit, like, the line of code in any file, no, it should not exceed more than 150. So that whenever we want to make changes, we can easily make the required changes. And, also, it's easier to find a bug whenever it is required. No? So, like, with MBWAM, there is a model view model. So, basically, whatever changes we make with respect to a particular screen, we can put those changes in the view model. Basically. And there are different models we can use. And, basically, the UI is where the user interacts, and the view model does not have direct interaction with the screen's UI. It's like, the interaction is made from the controller. No?

So with protocol-oriented programming, what happens is that we can easily communicate from one screen to another using different protocols. Suppose you want to follow certain rules for any feature. No. With protocol-oriented programming, I can write certain protocols, like say, if I write a protocol called "car," and I want someone to use those functions like paint, card function, remove, print card function, add, print card, and so whenever those protocols are used, those methods are being implemented. And also, with protocol-oriented programming, one can easily communicate from one place to another. That is the main advantage. Also, the code now, the number of lines of code decreases with protocol-oriented programming. And basically, we can also use it as a delegate. No, to communicate from one place to another.

So we can use this now if you want to implement a table view, which we can use the lazy keyword, basically. If we want someone to call that variable, that variable should be called or that variable should be in memory. No? Only when it's called, basically, by using the lazy keyword, we can load the images. No? In a table view. Also, we can use the approach where you want to so basically, what Tableau does is only show the cells that are shown to the UI. No? Those cells are called, basically. So using that approach, we can customize the requirements now in the cell for row method, basically, which is being called every time whenever a cell is shown in the UI. And using the lazy keyword, we can implement lazy loading of images in a table view.

So with Core Animation, we can play with the screen's layer, basically. And every view in the UI Kit has a CALayer present. So with the help of the CALayer and Core Animation, suppose you want to draw some bubbles on the screen. So with the help of Core Animation, we can draw certain animations.

I think here, as you can see, the second line, no entity and as entity description, entity, point it in name, user, context, though, there is a force exclamation mark. I think we can or that instead of that, we can use the guard. Let's know. Otherwise, there are chances the app might crash here since if there is no user in the, this no. In the context of this core data. So, basically, there are chances the app might so it's better to use the guard clause. So only if it succeeds, it will go inside, and else it will return. And we can handle the situation using the guard clause.

Yeah, I think here what might happen now, I can see the method, the fetch data. It's called, it's not called on the main thread. So whenever we're assigning the data, no, cell dot data equals fetch data. That should be called on the main thread. So the UI is also the content we know. That data is loaded on the main thread. So here, that's one issue, I think. And, also, we need to implement this protocol here, the view model. I think there's one observable we need to implement. The basically, it's a class view model should inherit the observable protocol here. So based on that, I think those two things are missing, and the main thing is cell dot data equals fetch data should be called on the main thread.

So, basically, you would check using the instruments now where the memory is getting leaked. So that's one way using Xcode provides a tool, no, instruments. Basically, it can be used by using the Xcode and I'll try to debug the code and open the instruments. So upon that, I'll get to know where the memory is getting leaked on which screen. And, also, I'll try to reproduce the steps. No? So there are certain third-party libraries also available like Crashlytics, and then there is Firebase Analytics. So, like, which basically tells you if there is a crash, no, where the crash happened on which line. And, this. So once I get to know whether Firebase or this doesn't help, then I think instruments definitely help. So, yeah. Also, we can use something like a thread sanitizer. Basically, checking on which thread this app crashes or the memory. So, yeah, using the instruments, we can troubleshoot and, yeah. And memory basically happens when there is no automatic reference count when there are retain cycles. So I think we can use the keyword weak or unknown to avoid the memory leak. So whenever in Swift, the automatic reference count happens. So if some variable is not deallocated in a screen, so that time the memory leak happens. So using the weak and unknown keyword, we can fix the memory leak.

So, basically, the code quality definitely improves as you keep working, with different sizes of team. And so, I always prefer using this. No, not definitely MUM, but MUM is preferred and maintaining the number of lines of code, which should not go beyond 150, basically. So that the code readability also improves. You can easily read the code, and it's easier to make changes, basically. And one can improve their skills. No? Like, there are various platforms available online, like HackerRank and, yeah, there are a bunch of others. So I normally practice on HackerRank to improve my core logic. And this main table is, basically, one needs to update the ports if we are using ports, no, or third-party libraries. One can, like, update the ports or third-party libraries monthly or at least once in two months. And also, we can use, initially, we started with Objective-C for iOS development, then moved on from Objective-C to Swift. And this then, now, whenever we make new UI, we should definitely use Swift UI. So, in this way, the code we are using native and the latest features, no, provided by Apple. And, yeah, code quality is something like you should use this. We can always use instruments to check how much, and also, Xcode provides options, like how much RAM is being used, how much memory is being used by the app. So, those are the metrics we can always check. And also, we can rely on app performance. No. There are third-party app performance tools. So, it definitely so, if there are 100, it will tell you how many crashes there are. If there are any crashes, what the app is performing. So, yeah, using those tools also, we can maintain the code quality and, yeah. Also, yeah. And we should definitely keep updating the app. No. At least, like, if there are no crashes, then definitely not if, like, the app is very stable and there are no changes. So we can definitely, like, make an update once in six months, something like that.

I would prefer this. No. I think GitHub provides the CICD option. Basically, continuous integration, continuous development. So GitHub is one option, and there are many others like Bitbucket and some other tools also available where you can prioritize the CICD pipeline for this. And I think Xcode recently came up with Xcode Cloud. So, basically, one can continuously integrate and develop. And CICD should only be used when you are pushing the app every 2 days or 3 days. And that's when CICD comes into play. But if you are publishing at once in 15 days or 30 days, then CICD might not be required because the developer might have enough time on their end. And yeah. So it depends on the number of days. So, if you are launching the app every 2 or 3 days, then only the CICD pipeline should be set for the iOS app project. So there are already tools. No? GitHub, bitbucket, locate where the CICD can come into play, and we should also write some scripts for that.