Welcome to the ios and swift programming tutorial in Hindi channel Codecat15 😊
I am a full-stack developer with 12 years of experience.
My channel is all about teaching swift programming, iOS app development, and writing clean code in swift.
And this channel is focused on swift for beginners and advanced programmers to help them learn swift programming and iOS programming with easy examples.
I want to show how small improvements in your code can have long-term benefits and save you from hours of debugging and sleepless nights if you get it right the first time.
You can learn swift with easy examples and get familiar with design patterns in swift as I will show how I implemented things like protocol, delegate protocol, singleton, MVC, MVVM, dependency injection, and many more in the coming days of ios tutorials.
I am here to simplify swift programming for beginners and everyone. Please subscribe :)
Thank you very much! It was really very helpful for me 💯🤛. I tries three day pass data from one vc to another, and was not able to understand why every time I could receive nothing exept nil🤪
Great video!! That is a very detailed explanation. Found one issue: Since your queue is concurrent, there is no guarantee that your Task with getAvailablePhones() will be called post purchaseTask. This will create an unwanted issue. Please correct me if I am wrong
Hi Ravi in 8:55 time duration you said Hstack will not work, but now 2024 june and Hstack also work maybe swiftUI upgraded because it's 4 years passes. Hstack works outer the VStack { } Can you please upload new video. this is very helpful for me.
Choosing between weak and unowned depends on the specific relationship and lifecycle guarantees between the objects involved, weak is used for optional reference whereas unwoned is used for non-optional references. You should unowned only on those types which are never expected to be nil but if for some reason they do end up being nil then it will crash the app and hence weak should be the choice as it won't crash the app.
19:30 - A reference cycle only occurs if both types involved are reference types, not if one is a value type. Therefore, conforming to AnyObject is unnecessary when one side is a struct. The reason a ViewModel (VM) should be a class rather than a struct is due to state management. When a property of a struct is changed, the entire struct is recreated with the new value, causing the rest of the state to be lost. This means we would need to retain the shared instance every time the value of the struct-based VM is changed, which is not practical. Please correct me if I'm wrong, @codecat15 @ravi.
right, but then as I explained in the video that mostly devs prefer class over struct and the explanation was given to ensure that if the view-model (VM) is a class then ensure the AnyObject conformation and the implementation of weak. A VM should never hold state whatsoever it is an orchestration class and not a class that manages state of the objects.
The reason why they are forced unwrapped is because by the time your storyboard or your code initializes the UIControl it's guranteed that it will be available for you to use and operate on. The force unwrapping in my opinion is kind of a check that ensures that this control is on the view and is available to use avoiding the need to optional unwrap. Let me know if that answers your question and if not then feel free to ask more.
My apologies for not having the two-way binding video for UIKit, the way I implemented it back then was using the Observer class and the code for that is not pretty. With Observation framework now, we can surely use two-way binding as it's naturally supported in the system.
I think this design decision was made by apple to fit the need to reflect the instant changes on the view, structs are value types and hence when an existing value is updated in the struct it creates a new copy this provides predictable behavior, making it easier to reason about the state and identity of views and since structs are copied by value, the framework can easily determine when a view has changed and needs to be re-rendered. In Swift, the `@frozen` attribute is used to indicate that a public enumeration or struct's cases or properties will not change in future versions of the library or module
there's plenty of content for iOS app development but sadly only few of them adheres to good programming practices or explain why they went for solution A instead of solution B or solution C.
Hi Ravi Thanks for detailed session. All your videos are really good and knowledgeable. and those can be referred even by beginner or experienced one. Only thing I would like to suggest is to start the { on same line for more clear code (for guidelines). (I know you add those for better understanding, but may be I have OCD for it 😂)
hahaha I get it, that irritated me too for sometime as the formatting was not happening correct so I did plenty of re-takes on this video due to the formatting but then I was like ye na ho payega ab isko aise he live karna hoga
@CodeCat15 can you add a few things please, so that it will prove, that the object of Superclass can be replaceable or substituted by the object of subclass, Which is the main concept of the Liskov Substitute Principle. Not finding any concept of super and sub-class,
@CodeCat15, At 6:45 min, Just noticed something that I want to bring to your attention. If we make a transaction of 1 Crore in the above example. It is obviously a huge transaction to be authenticated. But, what if we make a deposit of 10 rupee right next to depositing 1Cr. It will again call the method senMesssageToAuditor() as the newAccountBalance will be having 1 crore + 10 rupees and we are doing a conditional check on the accountBalance not the amount that we are setting it through addMoney method. I think we can take it as a bug and any idea how can we fix this ?
If you have declared John object in viewcontorller class then you need to assign it nil, and if you have declare it in viewdidload then you don't have to assign it nil, because object goes out of scope and it will be deallocate automatically, that's why in this case you do not need to assign nil in unowned also.
