Kedar Nagekar

Yeah. Hi. My name is Kedarnagekar. So I started iOS development with the internship. And then I started working in the same company So since being a service based company, I got the chance to work on different apps, like, video editing app, news apps, So I worked there around for a year. And then I joined this company called FlipBar, so which were into the travel domain. So, basically, they had their app called Flippar Go. So where user can, see the places which are nearby. So Code API in Bangalore, it will show you the carbon park, Lal park. Which is the nearest point of interest. And, yeah, once you click on a place, it will show you the relevant information, like image, video, audio, etcetera. But we were doing things differently, like, in the augmented reality, Yeah. So there, I had a chance to work on a Different AR experiences like, sticky videos, audio player in AR, etcetera. And, then I started working in, this company called Kahya Technology. So they were mainly into the Bluetooth and IoT domains. Basically, if you device any smartwatch, they need to connect the using the board crash app. So, basically, we will fetch the users data from the watch and show it in the app and upload it on the servers. So yeah. So there I had opportunity to, like, review the other's code and take interviews sometimes. Yeah. Other than that, I have experience in IoT and, Arduino platforms. Basically, it's, like, you can assemble different hardware and, like, we can program it and whatever. Like, I made one small robotic car. I was able to move the car basically, from the app. So I was able to move the car front, left, right, etcetera.

Yeah. I think that's it. Yeah. I think we can use the keyword, no, week or the basically, the unknown. So if it we can break the return cycle using the weak keyword. So weak is, like, a option if there is a 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, like, start with the MVN. No. It's, I think it's easier to use once you know it, and it's easily scalable. And the one thing I tried to now started one habit, like, the line of code in us any file, no, it should not cross more than 150. So that whenever changes we want to make, 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 view model. So, basically, the whatever the any changes we can make with respect to particular screen, we can put those changes in the view model. Basically. And there are different models we can use. And, u is basically the the UI. No? The where the user interacts and, yeah, and view model does not have direct interaction with the screen's UI. It's like, The so the interaction is made from the this. No?

Basically. Yeah. So with protocol oriented, what happens, like, we can easily communicate, no, from one screen to another using different protocols. Suppose you want to tell, follow certain rules. For the any feature. No? Like, I'll write certain protocols like, like, say, if I write a protocol car, and I want someone to use those functions like paint a function paint card function remove print card function, add print card, and so whenever those protocols are used, those methods are being implemented. Dedicate And also the this with protocol one can easily communicate from one place to another That is the main advantage. And also the code now The number of lines of code decreases with protocol oriented programming. And, yeah, And, basically, we can also you use it as a delegate. No? To communicate from one place to another.

So we can use the this now if you want to implement, table view, which, we can use the lazy keyword, basically. If we want to someone like, that variable should be called or that variable should be in memory. No? Only when, when it is called, basically, by using the lazy keyword, we can, this load the images. No? In, table view. Also, we can use the approach where, You want to so basically, what Tableau does, it's, only which the cells are shown to the in the UI. No? Those cells are called, basically. So using that approach, we can, like, customize the requirement 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 UITW.

So with core animation, we can play with the screens layer, no, basically. And, every view in the UI kit has a CL layer present. So with the help of the CL layer and, this code animation, no, Suppose you want to draw some bubbles on the screen. So with the help of the core animation and, like, we can draw certain animation. No? And

I think here, as you can see, the 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 know. Otherwise, there are chances the app might crash here in the since if there is no user in the, uh, this no. In the context of the this core data. So, basically, there are chances the app might so it's better to use the guard light. So only if it succeeds, it will go inside, and else it will return. And we can handle the situation using the guard light.

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

So, basically, I would check the using the instruments now where the memory get is getting linked. So that that is one way using the Xcode provides a tool, no, instruments. Basically, it can, uh, by using the desk and I'll try to debug the code and open the instruments on the Xcode. 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 there are certain third party libraries also available like Crashlytics, Then there is a Firebase Analytics. So, like which basically tells you if there is a crash, no, where the crash happened on which line. And, uh, this. So once I get to know so if the there are if the Firebase or the this it doesn't help, then the I think instruments definitely have helps. So yeah. Also, we can use something like a thread sanitizer. Basically, checking the on which thread the this, uh, it app crashes or the memory. So, yeah, using the instruments, we can, uh, troubleshoot and, uh, yeah. And memory basically happens when there is a this no automatic reference when there are written cycles happens. So I think we can use the keyword weak or the unknown to avoid the memory leak. So whenever the, uh, in Swift, the automatic reference count automatically happens. So if some variable is not deal deallocated in a screen, so that time the memory leak happens. So using the this, what you call, the weak and unknown keyword, we can, uh, fix the memory leak.

So, basically, the code quality definitely, it improves as you keep on working, no, with, uh, like, with, uh, different size of team. And, uh, so I I always prefer, like, uh, using the this. No? Not definitely MUM, but MUM is preferred and maintaining the number of lines of code now, which should not go beyond 150, basically. So that the code readability also, this no. You can easily read the code, and it's easier to make changes, basically. And, uh, one can improve definitely their skills. No? Like, there are platforms various available online, like hacker rank and, uh, yeah, there are a bunch of others. So I I I normally practice on the hack hacker rank to improve my core logic. And, uh, this main table is basically one need to update the ports if we are using the ports, no, or third party libraries. 1 can, like, uh, monthly or, like, at least, uh, once in 2 months, one need to update the ports or third libraries. And, uh, also, we can use like, initially, we started with objective c, the iOS development, then we, like, uh, moved on from objective c to swift. And, uh, this then now whatever, like, whenever we are making the new UI, we should definitely use the swift UI. So in the in this way, the code we are using the native and the latest features, no, provided by the Apple. And, uh, yeah, code quality is something like you should use the this. We can always use the instruments, no, to check how much. And, also, the x code provides you options, like how much RAM 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 the this, like, the app performance. No. There are third party app performance. So it definitely so if you if there are 100, it will it tells you how many, like, uh, how many crashes there are. If there are any crashes, what is the how the app is performing. So, yeah, using those tools also, we can maintain the code quality and, uh, yeah. Also yeah. And we should definitely keep updating the app. No. At least, like, uh, if there are no crashes, then definitely not if, like, app is very stable and there are no changes. So we can definitely, like, make an update once in 6 months, something like that. Yeah.

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