Navpreet Kailay

My name is. I'm from Punjab, Mohali, and I've been working as an AS developer for the last five years and five months. I got a chance to work in service-based companies, and the last company of mine was a product-based company. The product was based on an ecommerce platform. I was a part of the customer success team for over a year. I also got a chance to work in the platform team and the launch team. So I got a chance to work on the core features and the urgent bugs and maintenance of the project, which were revenue-impacting. The platform was based on Shopify APS, GraphQL APS, and a whole lot of customization based on the ecommerce platform. In the past, I got a chance to work on domains like social media, dating apps, productivity apps, utility apps, and a whole lot of other domains and industries, including native development.

While I have not got the chance to work with the core animations along the gesture recognizer, but I believe that to for example let's take an example or a task where a user wants to provide a user an animation while he scrolls or swipes on the screen on a specific point. And if he swipes from one point to another, we can use those points and states of that gesture recognizer instance. And we can for example have the fluid animations or move those views in which the points are enclosed. So we can animate those views based on the position of the gesture recognizer which is being changed by the user.

Okay. So there are multiple instances where we get to use safely unwrap an optional in Swift, and we can do it by optional chaining and optional binding as well. We can use a flatMap to get the unwrapped value out of an optional value. And we can also use guard and allow, and other methods as well. And there is an asymmetry mark that we use to check the unwrapped value, but in an unsafe manner. And we have a question mark, which is our optional operator that we use in the optional unwrapping as well.

Key consideration while designing a reasonable network layer insert. Okay. So there are a few considerations that I take personally. First is to have a loosely decoupling between the layers, between low and high-level modules of the project. In this case, our low-level module would be the API manager, which would be a network layer of our project. Between them would be an abstraction layer, which would get the request and return a generic object, which for this example could be a portable object and include one error if due to some reason the network request got failed. So this is the abstraction point. And the other thing would be using protocols to introduce abstractions. We can have certain services that inject dependencies to use the abstraction layer in between. And so that the view model, which would be the calling entity of the particular network request, would not know what the actual implementation between the layers is and just gets to call and get the desired model out of it.

The architecture pattern depends on the nature of the project, the size, and scope of the project. I generally use MVVM, and the factor that I get to decide what architecture to use is solely dependent on how large the project is going to be, what its nature is, and what the specific requirements are for this particular project. And based on that, I have to choose the architecture pattern. So far, I've used MVC and MVVM patterns, and I'm looking forward to learning more like WIPER and MVP architecture patterns. This is my approach towards choosing the right architectural pattern. And, since I'm learning more about MVVM, I would choose the MVVM pattern because it separates the concerns. It separates the business logic out of the view, and it allows us to keep the maintenance of code in a better way, which makes testability easier. We get to perform tests better, and because we have separate concerns, we can introduce abstraction between the layers, which makes it easier to mock the entities or modules to test with less code and reusable code. So my choice would be MVVM for long-lasting applications.

So as you know, SwiftUI framework allows us to have great UI with lesser code and with less complex code. And since SwiftUI allows us to write a code which is state-driven, which means our view is a function of our state. So it allows us to have control over each state of a view, how the view looks. It is basically dependent on an entity which is our state and which is bound to the view. So our state is bound with the view and it allows us to use those particular animations and transitions directly linked to that particular variable. And using that, we can perform a few available view modifiers inside the SwiftUI or added by SwiftUI like animations. We can pass on a few values like bounce, snappy, and that view modifier animation view modifier allows us to input that parameter which is our binding operator to our animation view modifier that allows us to have scene lamps animations whenever the view renders or if some state of that particular view changes. For example, there is a recent development made to the SF Symbols. They have provided us a view modifier to these views that hold these symbols, like spend some, but for example, when I stay a button changes its state or we can switch one image icon of that particular button to another using and while doing that, we can use this modifier transition effects in which we can pass on this symbol SF symbol effects to appear bouncy. And there are a lot of other options we can pass into it to have a very good-looking animation. Suppose in this example that I used in case of a button image, the button icon can easily be animated while changing its icon. So there are a lot of other provisions as well, like changing colors, transition colors, and there are a whole lot of other possibilities now provided directly by iOS and Apple.

Let's look at the code. First of all, when creating this entity, a new user, we are directly hard coding the values without using the models, which can generate the NSObject models directly out of the entities rather than setting up the direct hard coded values in a key-value manner. Rather, we can use the models given by the code data to write a better code to process data in the code data. So that would be one thing, and this is the main thing that I am able to look at. Plus, we are unsafely unwrapping the entity description there in the second line where we are constructing the entity of this user type. So that is also not a good way to write a code in this particular context. And, as I discussed earlier, we can use those as a manager object. When we generate those models, we are given particular properties and functions by the core data to safely get the instances of those entities and the context as well. So these are the 2, 3 things that I can look directly from this code.

Yes, sir. This particular piece of code does not follow the single responsibility principle because along with crude operations for the user, it also has authentication methods. So we can have a different protocol or a different module for the login and logout user. And plus, the fetch users can be different; we can have the fetch user function in a different repository. So we can suggest a better way to refactor it: the class can adopt a protocol which would be the user repository to create and delete the user, or upgrade the user, of course. So these three functions can move out into a different protocol. And to log in and log out, these two functions can move. We can refactored them into a different protocol, and the implementation can be wrapped by any layer that has the implementation details of logging out or logging in the user. Same for the create user, delete, and upgrade user. And we can have the third option. This is the option: we can have the fetch user in a different repository protocol. So we can break down these particular functions into the form of abstraction layers, protocols, and then have different classes or structures like user manager, authentication manager, and they can adapt to those particular protocols and adapt to the solid principle, the single responsibility principle in a better way.

So there can be a number of steps to troubleshoot a memory leak with an Objective C iOS application. So first would be the program can directly look for the strong differences between the entities and between the classes. In this case, if the instances of particular classes are holding stronger references to each other and they are not handled properly, which can introduce these strong retained cycles. So we can use like we have auto release tools to release the memory as soon as we do not require those particular objects in a given context. That would be one thing using weak references. Another approach we can follow is to use weak references everywhere across the board to avoid the strong references. And we can use thread sanitizers to check if there are any data races around the code. We can start that process as well. It takes some time to build the code, and it provides the sanitizer context wherever it finds any data is happening. Two other things would be to use certain debugging tools to find out the memory leaks. I have not got myself exposed to those tools as of now, but I would love to explore more possibilities to find the memory leaks in a better way.

So to manage app secrets, like APIs, keys, passwords, there are certain secure ways to do that in the Xcode given by Apple. One would be to have API keys. Of course, there are other ways as well to secure, store, or process these values. For now, I would say API keys can be placed inside the config file, and that can be securely fetched through the bundle inside our code, rather than storing it directly inside the code. So only the keys will be used to fetch the APIs in the code, using those key names, and their values can be fetched without hard coding the actual values. API keys in the code, using those key names, and their values can be fetched without hard coding the actual values. Passwords can be easily stored in the keychain framework provided by Apple. That could be one way for these particular things. And there are other ways as well to encode, decode the keys to have another encryption layer on top of it.

It's a good question. I have not currently got a chance to set up a CICD pipeline from scratch. From the teams and companies I've been part of, the CICD pipeline has been an integral part of the development and release process. However, yes, I would love to explore more, and I'm looking forward to including a CICD pipeline for testing and quick development, and generally exploring how the whole world of CICD works. And I'm looking forward to learning it in my own project that I'm working on. But, I would still try to look at the question one more time if I can contribute to the answer in a known way. The first priority, I believe, would be to choose a better solution, to decide on a framework or methodology to use for this pipeline. What is the scope of the project that will be incorporating CICD in their workflow? And how is the team using branching? Maybe these factors also might affect this particular decision or how to prioritize it, if it makes sense.