Saifur Rahman

Hello. My name is Safur Rahman, and, uh, I have done my bachelor's in computer science in 2018. Then I got a personal to work as an iOS developer, and I've been working as an iOS developer for past, uh, around, uh, 5.4 years. So I've done, uh, projects around 14 to 13 projects I've done where, uh, 9 are live. And I've worked in team also. I've also worked as an individual also. Largest team I've worked is around 23 members. And, uh, I've done some projects alone also and then also done some, uh, also led some projects. So and and the domain which I've worked into social media, marketing apps, uh, health apps, medical related apps, uh, AI, CoreML, speech recognition, all these things. And, uh, I I I I have, uh, I would say I'm more of a swift swift enthusiast, uh, and but also have experience in Objective c. I've done some projects in Objective c, but my main experience is in Swift. So I would say I'm a Swift enthusiast. And I I I use MBPM pattern, and I'm learning SwiftUI now. But, uh, for now, I have been using, uh, MVVM part pattern for past 2 years. So that was from my side.

To safely unwrap optionals, uh, in SIP, we can use guard. Uh, we can use, uh, a slit. So guard will do what? It it will check if, uh, the value is nil. It will return and not execute the next code. If let will also do the same thing. Uh, if let, uh, if let variable name equals to the optional value your optional variable, it will check for the value. And if the value is there, it will come inside the scope of the iflet. Else, it will go out of the scope. So this is the approach to safely unwrap options in Swift.

Uh, the architecture pattern which I'll be using is MVVM pattern, uh, model view view model. So, uh, MVVM is like, uh, the main entry point is view model. We don't as soon as they, like, it it, uh, uh, first of all, it is scalable, maintainable, easy to load code, easy to write, easy to read, and easily understandable code. And it is easily scalable, easily maintainable. And, uh, when, uh, the the entry point here is view model, and the data is put into the model. And as soon as the model the data changes in the model, the UI itself updates. We don't need to, uh, update the UI again and again when the API comes and value comes, data changes. So we, itself, don't need to. It itself changes the UI. It itself updates the UI as soon as the model changes.

The best practice for managing memory when dealing with large collection of data models in iOS? The best practice is, uh, we we we we should, uh, we should check that there there there are, like, uh, the the return cycles should not be made. We should use weak or unknown, uh, strong references, uh, should not be made. And, uh, we we should see that, uh, the allocation is called, the unit is called, written cycles are not called, and the strong references are not there. So this is how we can manage the memory. We can check the, uh, instrument, uh, memory panel there, memory management panel. We can check what is the memory right now, how much memory it is using, if there are many leaks or not. So all these things we can check for the better, uh, memory leaks.

Uh, how can shift protocol oriented programming help in managing dependencies in an iOS application? Uh, in in shift protocol oriented programming, uh, helps in managing dependencies in our application. It is like like, uh, in the protocols. These are blue blueprints. These are blueprints. So managing dependencies, like, as soon as we, uh, through the delegates and with the help of protocols, as soon as that protocol is assigned, as soon as that protocol is put into a class or something, all the functions which we want, all the dependencies, extra dependencies which we want in a class or something, so those are called. We can also go for a required method or, uh, an unrequired not required method. We can go for both. Like, if if it's a required method, then if a protocol is there, then that method has to be there. If it is not required, then that function may or may not be there. It's according to the user. So this is how Swift's protocol oriented programming help in managing dependencies in iOS application.

Key considerations when designing a reusable network clear in Swift. Key considerations. Uh, well, for a reusable network, we can go for a singleton pattern where where the class can be private, and we'll create a singleton class so that it instance is not created again and again. Not memory is used again and again, and the object isn't created again and again. So for that, we can use singleton pattern. It is very helpful for reusable network, uh, layer insert.

What we can do is, like, uh, we can create a single new class for this position container dot view context so that again and again, we are not creating object of this persistent container. And, uh, if if you use a singleton task, the app performance will be better, or else, the memory will be more and more and more and more, uh, memory will be keep on occupying. So we can use this, uh, singleton class here.

Given this code snippet. Has a view model dot fetch data is called inside the scope of dot and appear? So this might happen that, uh, the response from the API is not there, and we will be able to see the text field here. So the text field will be shown, but the, uh, this uh, the data may be fetching at that time. So this problem may occur.

For, like, first of all, uh, we we we will say that, uh, g for GCD, like, uh, it is called Grand Central Dispatch. It is it it is for it it is for, uh, background threat, first of all, and, uh, for, uh, like, uh, like like I said, just for background thread. Whatever task has to perform in the background and the UI shouldn't be hampered or that can shouldn't crash. So the main thread, uh, should not be used while, uh, doing some background, uh, background task. So what we do is we use this GCD for the background task. And when the response comes, we we we go for the dispatch to dot main dot async. And after that, the, like, like, uh, how like, uh, we we can update the UI on the, uh, main thread. So, like, in in this question, it is all, like, how to perform concurring operation. So in the concurrent, uh, con concrete operations, what what we can do is, like, we take, like, uh, for example, we can do is, like, we take let, uh, let let some concurrent queue equals to dispatch 2, and we give a label. And, uh, the label name may be concurrent queue, and, uh, it it attribute is concurrent. So when we took this concrete queue now, concurrent queue dot, uh, async, we will perform one task. Let's say I have print inside something, print task 1 running, then the scope of that, uh, async closes. After that, concurrent queue dot async. Uh, again, the scope opens. Uh, the we print some other task is running or task 2 or performance 2. So this is how it is done. And, uh, uh, we can we can also do do this with the completion handler also.

Secure data in iOS, uh, is, uh, we can we can use keychain to keep the data and, uh, or, like, the the best practice is to best practice is to use the Keychain. And, uh, second, we can do is, uh, encrypt the data. We can, uh, and we can encrypt the data. Uh, we can use, uh, like, crypto chip service for that. And, uh, there there are some data production APIs also. We can make some data production API for that. So but but but the best I know best I know is we can use keychain for that in which the data is the data is saved in case a class, case a cat, attribute account. All these things are used, and the data is saved inside the Keychain.

Uh, to ensure good quality. To ensure code, Kaldi, we can do is what we can do unit testing, and, uh, we can, uh, we can do as a, like, the proper documentation should be there. And, uh, CICD, we can use. Continuous integration and, uh, continuous deployment can be done. It's, like, for a day or half day we work, and then we deploy it and and we integrate it into the main project, deploy it, and it is checked again and again. We can refactor it, uh, like, regular refactor code to, uh, we for for improving the performance and maintainability. So all these things can be done.