Forem: Matheus Ferreira da Silva Nascimento

You know the difference about Weak and Unowned reference in iOS?

Matheus Ferreira da Silva Nascimento — Wed, 07 Aug 2024 13:02:41 +0000

Recently, I was asked about this topic in a interview, and it's made me thinking about this subject, and realize that can pass unseen sometimes. Based on this, I decide write this article to help early iOS Developers, I going to unite two mine passions here, beyond iOS Development, that are Football and Pokémon, to exemplify.

Quick tip: Write subjects like that in post-it's, do smart notes always as a good way to fix the knowleadge and remember when we forget.

What is ARC?

Before talking about weak and unowned, it's important to understand ARC (Automatic Reference Counting). ARC is a system that Swift uses to automatically manage the memory of objects. It tracks how many times an object is referenced and deallocates it from memory when there are no more references to it.

Weak References

Imagine that Pikachu and Ash are friends on a Pokémon journey.

Weak Reference: Pikachu has a weak link with Ash. If Ash decides to leave, Pikachu doesn’t try to stop him or keep the space occupied by Ash.

class Pokemon {
    weak var friend: Pokemon?
}

var pikachu: Pokemon? = Pokemon()
var ash: Pokemon? = Pokemon()
pikachu?.friend = ash
ash?.friend = pikachu

pikachu = nil
// ash?.friend is now nil because pikachu was deallocated

When to use weak?

Reference Cycles: We use weak when we want to avoid reference cycles. This happens when two objects reference each other, preventing ARC from deallocating either of them.

Avoiding Memory Leaks: Since weak doesn't keep the object in memory, it's ideal for situations where the referenced object can be deallocated without issues.

Unowned References

Now, imagine a soccer team with a coach.

Unowned Reference: The coach of the team has a link with a star player, believing that the player will always be there as long as the coach needs him. If the player gets transferred to another team, this could cause a problem.

class Player {
    var coach: Coach?
    init(coach: Coach) {
        self.coach = coach
    }
}

class Coach {
    unowned var starPlayer: Player
    init(starPlayer: Player) {
        self.starPlayer = starPlayer
    }
}

var messi: Player? = Player(coach: Coach(starPlayer: messi!))

messi = nil
// Accessing coach?.starPlayer will now cause an error because messi was deallocated

When to use unowned?

Existence Guarantee: We use unowned when we're sure that the referenced object will be in memory as long as the reference exists.

Master-Detail Relationships: Ideal for situations where a main object (master) guarantees the existence of the referenced object (detail).

Summary

weak:
Doesn’t keep the object in memory.
Optional reference, can become nil.
Used when the referenced object’s lifecycle may be shorter.

unowned:
Doesn’t keep the object in memory.
Non-optional reference, never becomes nil.
Used when the referenced object’s lifecycle is guaranteed to be equal to or longer.

Conclusion

I hope this explanation helps clarify the difference between weak and unowned! Keep going strong in your learning journey, drink water, and always believe in yourself!

Você sabe a diferença entre Weak e Unowned?

Matheus Ferreira da Silva Nascimento — Wed, 07 Aug 2024 12:58:19 +0000

Recentemente, me fizeram essa pergunta em uma entrevista. Fiquei pensando sobre isso e percebi que, apesar de ser um tópico super interessante, muitas vezes a galera que está começando pode acabar deixando isso passar batido no cronograma de estudos. Com base nisso, resolvi escrever esse artigo pra compartilhar conhecimento e também consolidar o meu.

Uma dica: Escreva smart notes em post-it's, para fixar o conhecimento, principalmente sobre tópicos como esse.

Quando estamos falando sobre referencias de memória, é essencial que você tenha conhecimento sobre o ARC (Automatic Reference Counting) e seu funcionamento.

O que é ARC?

Antes de falar sobre weak e unowned, é importante entender o ARC (Automatic Reference Counting). O ARC é um sistema que Swift usa para gerenciar a memória dos objetos automaticamente. Ele rastreia quantas vezes um objeto é referenciado e o desaloca da memória quando não há mais referências a ele.

Referências weak (Fraca)

Imagine que Pikachu e Ash são amigos em uma jornada Pokémon.

Referência Fraca: Pikachu tem uma ligação fraca com Ash. Se Ash decidir ir para longe, Pikachu não tenta impedi-lo nem mantém o espaço ocupado por Ash.

class Pokemon {
    weak var amigo: Pokemon?
}

var pikachu: Pokemon? = Pokemon()
var ash: Pokemon? = Pokemon()
pikachu?.amigo = ash
ash?.amigo = pikachu

pikachu = nil
// ash?.amigo agora é nil porque pikachu foi desalocado

Quando usar weak?

Ciclos de Referência: Usamos weak quando queremos evitar ciclos de referência. Isso acontece quando dois objetos referenciam um ao outro, impedindo que o ARC desaloque algum deles.

Evitar Vazamentos de Memória: Como weak não mantém o objeto na memória, ele é ideal para situações onde o objeto referenciado pode ser desalocado sem problemas.

Reference unowned (Não Própria)

Agora, imagine que um time de futebol tem um técnico.

Referência Não Própria: O técnico do time tem uma ligação com um jogador estrela, acreditando que esse jogador sempre estará lá enquanto o técnico precisar dele. Se o jogador for transferido para outro time, isso pode causar um problema.

class Jogador {
    var tecnico: Tecnico?
    init(tecnico: Tecnico) {
        self.tecnico = tecnico
    }
}

class Tecnico {
    unowned var jogadorEstrela: Jogador
    init(jogadorEstrela: Jogador) {
        self.jogadorEstrela = jogadorEstrela
    }
}

var messi: Jogador? = Jogador(tecnico: Tecnico(jogadorEstrela: messi!))

messi = nil
// Acessar tecnico?.jogadorEstrela agora causará um erro porque messi foi desalocado

Quando usar unowned?

Garantia de Existência: Usamos unowned quando temos certeza de que o objeto referenciado estará na memória enquanto a referência existir.

Relacionamentos Mestre-Detalhe: Ideal para situações onde um objeto principal (mestre) garante a existência do objeto referenciado (detalhe).

Resumo

Weak (Fraco):
Não mantém o objeto na memória.
Referência opcional (Optional), pode se tornar nil.
Usado quando o ciclo de vida do objeto referenciado pode ser mais curto.

Unowned (Não Próprio):
Não mantém o objeto na memória.
Referência não opcional, nunca pode se tornar nil.
Usado quando o ciclo de vida do objeto referenciado é garantido ser igual ou maior.

Conclusão

Espero que esta explicação ajude a esclarecer a diferença entre weak e unowned!

Sucesso na sua trajetória! Beba água e tenha fé em si mesmo, sempre.

Roadmap for iOS Development in 2024.

Matheus Ferreira da Silva Nascimento — Sat, 22 Jun 2024 17:41:42 +0000

In recent years, we have witnessed a rapid evolution in the iOS development ecosystem. With each new version of iOS, new technologies, tools, and recommended practices emerge, transforming the way apps are conceived, developed, and distributed. As we enter 2024, the world of iOS development continues to expand, offering opportunities for those who wish to dive into this realm.

In this article, we will explore a roadmap to become an iOS developer in 2024. From essential fundamentals to advanced technologies. Whether you are an aspiring developer looking to start your journey or an experienced professional seeking to stay updated, this roadmap is designed to guide you towards success in iOS development.

Foundations:

The Swift Programming Language: Swift is the primary language for iOS development. It is essential to have a solid grasp of Swift syntax, data types, optionals, and object-oriented programming concepts.

Understanding Xcode and Interface Builder: Xcode is the official integrated development environment (IDE) for iOS development. Understanding how Xcode works will greatly optimize your time if you are familiar with the environment.

Screen Building:

UIKit Framework: Mastering UIKit is essential for building iOS user interfaces. This includes understanding various available components such as view controllers and navigation controllers, as well as designing responsive and visually appealing layouts.
Auto Layout and Responsive Design: Understanding auto-layout is crucial to ensure that interfaces adapt to different screen sizes and orientations, providing a consistent experience to users.

SwiftUI: While UIKit is still widely used, SwiftUI is emerging as a modern and powerful alternative for building user interfaces. Despite its growing adoption, understanding the basics of SwiftUI can be advantageous to keep up with future iOS development trends.

Storyboard: Both the use of storyboards and programmatic interfaces have their advantages and disadvantages. It is important to be comfortable with both methods to ensure flexibility in interface creation according to project needs.

Architecture and Data Persistence:

iOS App Architecture: MVC, MVVM, VIPER: Choosing the right architecture is crucial to ensure the scalability and maintainability of an iOS application. Developers should be familiar with models such as MVC, MVVM, and VIPER, understanding the advantages and disadvantages of each approach.

Data Persistence with Core Data: To store data locally in iOS applications, knowledge of Core Data is essential. This framework offers an efficient way to persist and retrieve data, allowing applications to provide a consistent experience to users, even offline.

Service Integration:

Networking with URLSession and Alamofire: Integrating web services into iOS applications requires skills in making efficient network requests. Developers should be comfortable with using native URLSession or popular libraries like Alamofire to ensure effective communication with servers.

User Authentication and Authorization: Implementing secure authentication is essential to protect user data. Developers should understand different authentication methods, such as OAuth and Apple Sign-In, ensuring a secure and convenient login experience for users.

Testing: Ensuring Code Quality

Unit Testing and Integration Testing: Unit tests are essential to ensure that each component of the application functions as expected, isolating and testing individual parts of the code. Developers should write comprehensive tests to verify the behavior of classes, methods, and functions. Additionally, integration tests should be conducted to ensure that different components of the application work correctly together.

UI Testing: UI tests ensure that the application’s user interface functions correctly and provides a consistent experience to users. Tools like XCTest and UI Testing Framework help developers automate UI tests, simulating user interactions and verifying interface behavior in different scenarios.

Performance and Stress Testing: In addition to functional tests, developers should also conduct performance and stress tests to ensure that the application is responsive and stable, even under heavy load or adverse conditions. This involves testing the application’s responsiveness, resource consumption, and loading time on different devices and network conditions.

Accessibility Testing: Ensuring that the application is accessible to all users, including those with visual, auditory, or motor impairments, is essential. Developers should conduct accessibility tests to verify that the application meets Apple’s accessibility standards and provides an inclusive experience for all users.

Continuous Testing and Continuous Integration: Continuous integration and automated testing should be incorporated into the development process to ensure that code is regularly tested and integrated into the main repository seamlessly. This helps identify and fix issues proactively, ensuring continuous quality of the application throughout the development cycle.

Monetization and Distribution:

Push Notifications and Background Processing: Implementing push notifications and handling background tasks are essential features to keep users engaged and informed, even when the application is not actively in use.

In-App Purchases and Monetization Strategies: For developers focusing on monetization strategies, understanding in-app purchases and integrating payment systems is crucial. It is important to follow Apple’s guidelines and provide a transparent and secure purchasing experience for users.

App Store Submission and Distribution Best Practices:

Navigating the App Store submission process requires a good understanding of Apple’s guidelines and app review requirements. Developers should follow best practices for app distribution to ensure that their applications are approved and successfully distributed to users.

Using the KingFisher library in iOS development.

Matheus Ferreira da Silva Nascimento — Sat, 22 Jun 2024 17:30:11 +0000

The Kingfisher library is a valuable tool for efficiently loading and displaying images in iOS applications. Since its emergence about 8 years ago, the iOS community has widely adopted it due to its simplicity, performance, and robust features. Kingfisher is an open-source library with over 200 contributors to date and more than 2,500 commits.

Advantages offered by the library:

Efficient Loading: One of Kingfisher’s main advantages is its asynchronous image loading, ensuring that the application remains responsive while images are downloaded. This is essential for providing a smooth user experience, especially in image-heavy apps.

Automatic Cache: Kingfisher automatically manages image caching, eliminating the need for manual intervention. This not only improves the efficiency of the application but also saves bandwidth and speeds up loading times for previously downloaded images.

Simple Integration: The library offers smooth integration with UIImageView, simplifying the process of loading and displaying images. With just a few lines of code, you can implement advanced functionality such as displaying placeholder images during download.

Visual Feature Support: Kingfisher supports placeholders, smooth transitions, and prevention of memory retention issues.

Implementing the Kingfisher Library in iOS Development: A Practical Example

Recently, I integrated the library into my Pokedex project, which is simple but can experience delays in loading images due to the number of Pokémon to be displayed. The use of Kingfisher fits perfectly in this scenario. Here’s a practical implementation example:

import SwiftUI
import Kingfisher
struct PokemonCell: View {

let pokemon: PokemonModel
@State private var image: UIImage?

var body: some View {
    let color = Color.pokemon(type: pokemon.pokemonType)
    ZStack {
        VStack {
            HStack {
                title
                Spacer()
                type
            }
            .padding(.top, 10)
            .padding(.horizontal, 10)

            if let url = URL(string: pokemon.imageUrl) {
                KFImage(url)
                    .placeholder {
                        ProgressView()
                    }
                    .resizable()
                    .scaledToFit()
                    .frame(width: 130, height: 150)
                    .padding(10)
            }
        }
    }
    .frame(maxWidth: .infinity, maxHeight: .infinity)
    .background(color)
    .cornerRadius(12)
    .shadow(color: color.opacity(0.7), radius: 6, x: 0.0, y: 0.0)
}

var title: some View {
    Text(pokemon.name.capitalized)
        .font(.headline).bold()
        .foregroundColor(.white)
}

var type: some View {
    Text(pokemon.pokemonType.rawValue)
        .font(.subheadline).bold()
        .foregroundColor(.white)
        .padding(.horizontal, 10)
        .padding(.vertical, 6)
        .overlay(
            RoundedRectangle(cornerRadius: 20)
                .fill(Color.white.opacity(0.25))
        )
}

As you can see, the implementation is straightforward. Follow the steps in this example:

Import the Kingfisher library: Make sure to add import Kingfisher at the beginning of your Swift file to access the library's resources.

Define your SwiftUI Cell: In the example above, I created the PokemonCell structure to represent the Pokémon cell. The image URL comes from the PokemonModel model (remember that I used the MVVM architecture in this project).

Simple Loading and Caching: Use KFImage(url) to load the image from the URL provided by the template. The .placeholder block displays a progress indicator while loading. Kingfisher automatically takes care of caching, ensuring a fast and efficient user experience.

And with that, you already have everything you need!