Pular para conteúdo

Desenvolvimento Mobile Nativo 📱

"A educação é a arma mais poderosa que você pode usar para mudar o mundo." — Nelson Mandela (Adaptado para Tecnologia)

🧭 Atalhos Rápidos

🗺️ Mapa da Jornada

O curso está dividido em 4 Módulos Estratégicos projetados para uma progressão cognitiva sólida.

  1. Módulo 1: Fundamentos e Conceitos Iniciais.
  2. Módulo 2: Aprofundamento Técnico.
  3. Módulo 3: Prática e Consolidação.
  4. Módulo 4: Especialização e Projeto Final.

Ir para Aula 01

Plano de Ensino 🧭

Curso: Desenvolvimento Mobile Nativo com iOS (Swift)
Público-alvo: Estudantes de ADS, Ciência da Computação e Desenvolvedores de Software
Carga Horária: 20 Aulas (80 Horas Teórico-Práticas)

🎯 1. Objetivos do Curso

  • Compreender os fundamentos conceituais e arquiteturais de Desenvolvimento Mobile Nativo com iOS (Swift).
  • Aplicar padrões de projeto, sintaxe moderna e boas práticas da indústria.
  • Desenvolver soluções completas através de exercícios práticos e desafios de projeto.

📚 2. Cronograma de Aulas (Matriz de 20 Semanas)

Aula Tema Central Atividades e Entregas
01 Introdução ao Desenvolvimento Mobile Teoria, Prática Guiada, Quiz e Exercícios
02 Fundamentos de Java para Android Teoria, Prática Guiada, Quiz e Exercícios
03 Introdução ao Kotlin Teoria, Prática Guiada, Quiz e Exercícios
04 Estrutura de um App Android ️ Teoria, Prática Guiada, Quiz e Exercícios
05 Interface Gráfica (UI) Teoria, Prática Guiada, Quiz e Exercícios
06 Navegação entre Telas ️ Teoria, Prática Guiada, Quiz e Exercícios
07 Arquitetura Moderna (MVVM) ️ Teoria, Prática Guiada, Quiz e Exercícios
08 Persistência de Dados Teoria, Prática Guiada, Quiz e Exercícios
09 Listas Eficientes (RecyclerView) Teoria, Prática Guiada, Quiz e Exercícios
10 Consumindo API REST (Retrofit) Teoria, Prática Guiada, Quiz e Exercícios
11 Threads e Assincronismo (Coroutines) Teoria, Prática Guiada, Quiz e Exercícios
12 UX/UI e Material Design 3 Teoria, Prática Guiada, Quiz e Exercícios
13 Sensores e Hardware � Teoria, Prática Guiada, Quiz e Exercícios
14 Testes, Qualidade e Debugging Teoria, Prática Guiada, Quiz e Exercícios
15 Publicação e Google Play Store Teoria, Prática Guiada, Quiz e Exercícios
16 Projeto Final e Conclusão Teoria, Prática Guiada, Quiz e Exercícios
17 SwiftUI Avançado e Animações Customizadas Teoria, Prática Guiada, Quiz e Exercícios
18 Arquitetura MVVM/VIPER com Concorrência Swift Teoria, Prática Guiada, Quiz e Exercícios
19 Persistência Local com SwiftData e Testes Unitários Teoria, Prática Guiada, Quiz e Exercícios
20 Projeto Capstone: App iOS Nativo Completo Autônomo Teoria, Prática Guiada, Quiz e Exercícios

🧠 3. Metodologia de Ensino

  • Teoria Fundamentada: Aulas com conceitos detalhados, diagramas arquiteturais e sintaxe de referência.
  • Ciclo Teoria ⇄ Prática: Cada aula conta com Quiz Interativo (10 questões) para validação imediata, Lista de Exercícios Sanfonados (com Gabarito Explicado) e Desafio de Projeto Prático.
  • Laboratório Contínuo: Ambientes configurados passo a passo na seção de Setups da plataforma.

💼 4. Competências e Perfil Desenvolvido

  • Dominar as ferramentas e fluxos de desenvolvimento de Desenvolvimento Mobile Nativo com iOS (Swift).
  • Resolver problemas técnicos de alta complexidade com código limpo e performático.
  • Construir portfólio prático com 20 projetos aplicados.

📊 5. Critérios de Avaliação

  • 20 Listas de Exercícios: Resolução individual dividida em Básico, Intermediário e Desafio.
  • 20 Quizzes Interativos: Validação formativa com feedback imediato via JavaScript.
  • 20 Desafios de Projetos: Aplicações práticas consolidando o aprendizado de cada unidade.

Aulas

Aulas do Curso

Bem-vindo à seção de aulas! Aqui você encontra todo o conteúdo do curso organizado em 5 módulos estruturados.

📚 Módulos do Curso

Aula 01 - Introdução ao Desenvolvimento Mobile 📱

Objetivo

Objetivo: Compreender o panorama do desenvolvimento mobile, diferenciar tecnologias (Nativo, Híbrido, Web) e preparar o terreno para o desenvolvimento Android com comparações ao iOS.

1. Panorama do Mercado Mobile 🌍

O mundo hoje é mobile-first. Antes de codificarmos, precisamos entender onde estamos pisando. Existem basicamente três caminhos para criar um app:

📱 Nativo

  • O que é: Apps desenvolvidos na linguagem oficial da plataforma.
  • Android: Java ou Kotlin (usando Android Studio).
  • iOS: Objective-C ou Swift (usando Xcode).
  • Vantagens: Performance máxima, acesso total ao hardware, melhor experiência de usuário (UX).
  • Desvantagens: Custo mais alto (duas bases de código).

🌐 Web (PWA)

  • O que é: Sites que parecem apps. Rodam no navegador.
  • Tecnologias: HTML, CSS, JavaScript.
  • Vantagens: Rápido de fazer, funciona em tudo.
  • Desvantagens: Sem acesso a muitos recursos nativos, performance limitada.

🧩 Híbrido / Cross-Platform

  • O que é: Uma base de código que gera apps para ambas as plataformas.
  • Tecnologias: Flutter (Dart), React Native (JS), KMP (Kotlin).
  • Vantagens: Custo reduzido.
  • Desvantagens: Performance pode não ser igual à nativa em casos complexos.

Nossa Escolha

Neste curso, focaremos no Nativo (Android), pois é a base de tudo. Quem sabe nativo entende como os frameworks híbridos funcionam por baixo dos panos.

2. Ecossistema: Android vs iOS 🤖🍎

Vamos comparar os dois gigantes:

Característica 🤖 Android (Google) 🍎 iOS (Apple)
Linguagem Principal Kotlin (Java legado) Swift (Obj-C legado)
IDE (Ferramenta) Android Studio Xcode
Sistema Operacional Linux (Kernel modificado) Darwin (Unix-like)
Loja de Apps Google Play Store Apple App Store
Arquivos de App .apk / .aab .ipa
Publicação Mais flexível, taxa única ($25) Mais rígida, taxa anual ($99)

Comparativo Visual (Mermaid)

graph LR
    subgraph Android
    A[Linux Kernel] --> B[HAL]
    B --> C[Runtime ART]
    C --> D[Framework Java/Kotlin]
    D --> E[Apps]
    end

    subgraph iOS
    F[Core OS] --> G[Core Services]
    G --> H[Media]
    H --> I[Cocoa Touch]
    I --> J[Apps]
    end

3. Ferramentas de Desenvolvimento 🛠️

Android Studio

É a IDE oficial, baseada no IntelliJ IDEA (JetBrains). Poderosa, cheia de recursos, mas... pesada.

Requisitos Mínimos

Para rodar o Android Studio confortavelmente, recomenda-se pelo menos 8GB de RAM (ideal 16GB) e SSD. Sem SSD, a dor é real. 😢

Xcode

É a IDE oficial da Apple. Só roda em macOS. É conhecida por ser um pouco mais visual no design de telas (Storyboards), embora o Android Studio tenha evoluído muito com o Layout Editor.

4. Estrutura Básica de um Projeto 📂

Quando criamos um "Hello World", o que realmente é criado?

No Android (Gradle Project)

Use o terminal abaixo para explorar a estrutura típica:

$ tree MyFirstApp
MyFirstApp
├── app/
│   ├── src/
│   │   ├── main/
│   │   │   ├── java/ (Código Kotlin/Java)
│   │   │   ├── res/ (Recursos: Imagens, XMLs)
│   │   │   │   ├── layout/ (Telas)
│   │   │   │   ├── values/ (Cores, Textos)
│   │   │   └── AndroidManifest.xml
│   └── build.gradle (Configurações do App)
├── build.gradle (Configurações do Projeto)
└── settings.gradle

🆚 Comparação com iOS (Xcode Project)

  • AndroidManifest.xml ≈ Info.plist (Configurações essenciais e permissões).
  • res/layout/*.xml ≈ .storyboard ou .xib (Arquivos de interface).
  • build.gradle ≈ project.pbxproj (mas muito mais legível e editável!).

5. Por que Kotlin? E o Java? 🤔

O Android nasceu com Java. É uma linguagem robusta, mas verbosa. Em 2017, o Google anunciou Kotlin como linguagem oficial.

  • Java:
    • Verbo: System.out.println("Olá");
    • NullpointerException: O pesadelo dos devs. 👻
  • Kotlin:
    • Conciso: println("Olá")
    • Null Safety: O compilador te protege de valores nulos! 🛡️

Dica de Mestre

Aprenderemos Java nas próximas aulas para ter base sólida, e depois migraremos para Kotlin, que é o padrão moderno. Isso te tornará um desenvolvedor completo, capaz de manter sistemas legados e criar novos.

6. Mini-Projeto: Configurando o Ambiente 🚀

Sua missão para a próxima aula não é codar, é preparar o terreno.

  1. Baixar e instalar o Android Studio (Ladybug ou versão mais recente).
  2. Baixar e instalar o JDK 17 ou 21 (Java Development Kit).
  3. Configurar as Variáveis de Ambiente (JAVA_HOME).

Veja o passo a passo detalhado na seção Configuração > Setup Android.

7. Exercício de Fixação 🧠

Para fixar os conceitos de hoje, responda:

  1. Qual a principal diferença de custo de publicação entre Google Play e App Store?
  2. Se eu quiser um app que acesse o Bluetooth de forma extremamente performática, devo escolher Nativo ou Web? Por que?
  3. O que é o AndroidManifest.xml e qual seu equivalente no iOS?

Próxima Aula: Vamos colocar a mão na massa com Fundamentos de Java para Android! ☕

Aula 02 - Fundamentos de Java para Android ☕

Objetivo

Objetivo: Dominar a sintaxe do Java, focando nos conceitos essenciais para o desenvolvimento Android (POO) e comparando com a rigidez do Swift/iOS.

1. Por que estudar Java em 202X? 🦖

Java é a base do Android. Mesmo que você use Kotlin (o que faremos a partir da Aula 03), todo o sistema operacional Android e suas bibliotecas antigas foram escritos em Java.

  • Entender Java = Entender como o Android funciona "por baixo do capô".
  • Muitos projetos legados ainda usam Java.

2. A Estrutura de uma Classe 🏗️

Em Java, tudo é um objeto (ou quase tudo).

// Nome da classe deve começar com Maiúscula (PascalCase)
public class Pessoa {
    // Atributos (Variáveis de Classe)
    String nome;
    int idade;

    // Construtor
    public Pessoa(String nome, int idade) {
        this.nome = nome;
        this.idade = idade;
    }

    // Método (Função)
    public void apresentar() {
        System.out.println("Olá, eu sou " + nome);
    }
}

🆚 Comparação com Swift (iOS)

Característica ☕ Java 🐦 Swift
Pontos e vírgulas Obrigatórios ; Opcionais (e não usados)
Tipagem Estática e Explícita (geralmente) Estática e Inferida (muito forte)
Variáveis String nome = "Ana"; var nome = "Ana"
Constantes final String NOME = "Ana"; let nome = "Ana"

3. Tipos Primitivos e Wrappers 📦

Java tem uma peculiaridade: tipos primitivos (leves) e objetos (pesados/wrappers).

  • int (primitivo) vs Integer (classe/wrapper).
  • double (primitivo) vs Double (classe/wrapper).
  • boolean (primitivo) vs Boolean (classe/wrapper).

Atenção ao Null

Um int nunca pode ser null (padrão é 0). Um Integer pode ser null.

Isso causa o temido NullPointerException se você tentar somar um Integer que está nulo! 💥

4. Orientação a Objetos (POO) no Android 🧬

O Android usa POO o tempo todo.

🧩 Herança (extends)

A base de tudo. Uma Activity (tela) é filha da classe AppCompatActivity.

public class MinhaTela extends AppCompatActivity {
    // Herda todos os métodos de tela do Android
}

🆚 Comparação: Herança

classDiagram
    class Animal {
        +respirar()
    }
    class Cachorro {
        +latir()
    }
    class Gato {
        +miar()
    }
    Animal <|-- Cachorro : extends
    Animal <|-- Gato : extends

No iOS (Swift), a herança funciona igual, mas a sintaxe é class Cachorro: Animal.

5. Estruturas de Controle e Coleções control

ArrayList vs Array

No Android, raramente usamos arrays fixos (String[]). Usamos listas dinâmicas:

// Java - Verboso
ArrayList<String> lista = new ArrayList<>();
lista.add("Item 1");
lista.add("Item 2");

// Swift - Conciso
var lista = ["Item 1", "Item 2"]

Loops (For-Each)

for (String item : lista) {
    System.out.println(item);
}

6. Null Safety (O problema de 1 bilhão de dólares) 💸

Em Java, qualquer objeto pode ser nulo. Você deve verificar manualmente:

if (usuario != null) {
    System.out.println(usuario.nome);
}

Em Swift (e Kotlin), o sistema de tipos impede isso por padrão.

7. Exercício Prático (Mental) 🧠

Imagine que você está migrando um código iOS para Android.

Código Swift: 

let idade: Int = 25
if idade >= 18 {
    print("Maior")
}

Como ficaria em Java?

Resposta 
final int idade = 25; // ou apenas int
if (idade >= 18) {
    System.out.println("Maior");
}

8. Desafio: A Classe 'Carro' 🚗

  1. Crie uma classe Carro em Java.
  2. Adicione atributos modelo (String) e ano (int).
  3. Crie um método ligarMotor() que imprime "Vrum!".
  4. No método main, instancie 2 carros diferentes.

Próxima Aula: Chega de verbosidade! Vamos conhecer o Kotlin, a linguagem moderna do Android e prima do Swift. Introdução ao Kotlin 🚀

Aula 03 - Introdução ao Kotlin 💜

Objetivo

Objetivo: Aprender Kotlin, a linguagem oficial do Android, e perceber como ela resolve os problemas do Java e se assemelha incrivelmente ao Swift.

1. Por que Kotlin? 🚀

Em 2017, o Google tornou o Kotlin oficial. Por quê? * Conciso: Menos código para fazer a mesma coisa. * Seguro: Null Safety integrado. * Interoperável: Funciona 100% com código Java existente.

"Kotlin é o que o Java seria se tivesse sido criado hoje."

2. Sintaxe Básica: var vs val 📦

Esqueça o String nome = .... O Kotlin infere os tipos!

  • var: Variável (pode mudar).
  • val: Valor (imutável - constante). Use sempre que possível!
var idade = 25
idade = 26 // OK

val nome = "Ricardo"
// nome = "João" // ERRO! Val cannot be reassigned

🆚 Comparação com Swift (iOS)

É idêntico! 😱

Recurso 💜 Kotlin 🐦 Swift
Variável var x = 10 var x = 10
Constante val y = 20 let y = 20
Função fun somar() {} func somar() {}
Print println("Oi") print("Oi")

3. Null Safety: Adeus NullPointerException 👋

No Kotlin, você precisa dizer explicitamente se uma variável aceita nulo.

var texto: String = "Não pode ser nulo"
// texto = null // Erro de compilação!

var textoNulo: String? = "Pode ser nulo"
textoNulo = null // OK

Operadores Seguros

  1. Safe Call (?.): Só chama se não for nulo. 

    println(textoNulo?.length) // Imprime tamanho ou null, não quebra!

  2. Elvis Operator (?:): Valor padrão se for nulo. 

    val tamanho = textoNulo?.length ?: 0

4. Funções e Expressões 𝑓(𝑥)

// Forma tradicional
fun somar(a: Int, b: Int): Int {
    return a + b
}

// Single-Expression (One-liner)
fun somarCurto(a: Int, b: Int) = a + b

Use e abuse de Single-Expression functions para deixar o código limpo.

5. Classes de Dados (Data Classes) 💾

Lembra da classe Pessoa da aula passada? Em Kotlin é uma linha:

data class Pessoa(val nome: String, val idade: Int)

O data class já gera automaticamente: toString(), equals(), hashCode() e copy().

🆚 Comparação: Structs (Swift)

No iOS, usamos struct para dados leves, que é muito similar ao data class, mas passado por valor.

6. Exercício Interativo (Termynal) 💻

Vamos testar o REPL do Kotlin (ambiente de teste rápido). Imagine digitando isso no terminal:

$ kotlinc
Welcome to Kotlin version 1.9.0 (JRE 17.0.8)
>>> val lista = listOf("Android", "iOS", "Web")
>>> lista.filter { it.length > 3 }
[Android, Web]
>>> quit

7. Extensions: O Poder do Kotlin 💪

Você pode adicionar funções a classes que você não criou (como String ou Int).

fun String.darOi() {
    println("Oi, $this!")
}

"Ricardo".darOi() // Imprime: Oi, Ricardo!

No Swift, isso se chama extension e funciona exatamente igual.

8. Desafio: Tradutor Java -> Kotlin 🔄

Converta este código Java mentalmente:

String texto = null;
if (texto != null) {
    System.out.println(texto.toUpperCase());
} else {
    System.out.println("Vazio");
}
Resposta em Kotlin 
val texto: String? = null
println(texto?.uppercase() ?: "Vazio")

Próxima Aula: Agora que sabemos a linguagem, vamos entender o Android! Estrutura de um App Android 📱

Aula 04 - Estrutura de um App Android 🏗️

Objetivo

Objetivo: Entender a anatomia de um projeto Android, o ciclo de vida de uma Activity e como o XML desenha a tela.

1. O Manifesto (AndroidManifest.xml) 📜

É a certidão de nascimento do App. * Define o nome e ícone do app. * Lista as Activities (Telas). * Pede Permissões (Internet, Câmera, GPS).

<manifest ...>
    <uses-permission android:name="android.permission.INTERNET" />

    <application ...>
        <activity android:name=".MainActivity" android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
</manifest>

🆚 Comparação: Info.plist (iOS)

No iOS, o Info.plist tem função similar, definindo permissões e configurações de inicialização.

2. Activity: A Tela de Verdade 🖼️

Uma Activity é uma classe que controla uma tela. Ela não é a tela (visual), ela controla a tela.

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main) // Liga o XML da tela
    }
}

🆚 Comparação: UIViewController (iOS)

Activity ≈ UIViewController. Ambos gerenciam o ciclo de vida da tela e a interação com o usuário.

3. O Ciclo de Vida (Lifecycle) 🔄

Uma Activity nasce, vive e morre. O Android avisa a Activity quando isso acontece.

  • onCreate(): Nasceu. Configure a tela aqui. (Só roda 1 vez).
  • onStart(): Ficou visível.
  • onResume(): Usuário pode interagir.
  • onPause(): Perdeu o foco (ex: um diálogo abriu).
  • onStop(): Não está mais visível (ex: usuário foi pra Home).
  • onDestroy(): Morreu. Libere memória.
graph TD
    Start((Início)) --> OnCreate[onCreate]
    OnCreate --> OnStart[onStart]
    OnStart --> OnResume[onResume]
    OnResume --> User{Interagindo}
    User -- Saiu --> OnPause[onPause]
    OnPause --> OnStop[onStop]
    OnStop -- Voltou --> OnRestart[onRestart]
    OnRestart --> OnStart
    OnStop -- Fechou --> OnDestroy[onDestroy]
    OnDestroy --> End((Fim))

🆚 Comparação: iOS Lifecycle

  • onCreate ≈ viewDidLoad
  • onStart ≈ viewWillAppear
  • onResume ≈ viewDidAppear

4. Layouts XML: Desenhando a UI 🎨

O Android separa a Lógica (Kotlin) do Layout (XML).

Arquivos ficam em res/layout/.

<!-- LinearLayout: Organiza itens em fila (Vertical ou Horizontal) -->
<LinearLayout
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <TextView
        android:text="Olá, Android!"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />

    <Button
        android:text="Clique aqui"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />

</LinearLayout>

🆚 Comparação: XIBs e Storyboards

No iOS, usamos arquivos .xib ou .storyboard, mas o XML interno é ilegível para humanos. No Android, editar o XML na mão é comum e poderoso!

5. ViewBinding: Chega de findViewById 🔗

Antigamente, para pegar um botão no código: 

Button botao = findViewById(R.id.meu_botao); // Lento e perigoso (pode ser null)

Hoje, usamos ViewBinding: 

binding.meuBotao.text = "Novo Texto" // Seguro e rápido

O ViewBinding gera uma classe que conecta o XML ao Kotlin automaticamente.

6. Resources (R.) 📦

Tudo que não é código fica na pasta res:

No Android (Gradle Project)

Explore a estrutura típica de um projeto Android:

tree MyFirstApp MyFirstApp ├── app/ │ ├── src/ │ │ ├── main/ │ │ │ ├── java/ (Código Kotlin/Java) │ │ │ ├── res/ (Recursos) │ │ │ └── AndroidManifest.xml └── build.gradle

Regra de Ouro: Nunca coloque texto fixo ("Hardcoded") no código ou XML. Use @string/meu_texto.

7. Desafio: O Ciclo da Vida Real 🧬

Cenário: O usuário está preenchendo um formulário no seu app. Ele recebe uma ligação. 1. Qual método do ciclo de vida é chamado quando a ligação toca (e cobre a tela)? 2. O que acontece se o Android estiver sem memória enquanto ele atende a ligação?

Resposta
  1. onPause() e depois onStop().
  2. O Android pode matar o processo da Activity (onDestroy() pode nem ser chamado!). Por isso devemos salvar os dados no onSaveInstanceState() ou ViewModel.

Próxima Aula: Vamos deixar o app bonito! Interface Gráfica (Layouts e Views) 🖌️

Aula 05 - Interface Gráfica (UI) 🎨

Objetivo

Objetivo: Entender o sistema de Layouts do Android, diferenciar ViewGroups de Views e criar telas complexas usando ConstraintLayout e LinearLayout.

1. Views e ViewGroups 🧱

No Android, tudo que você vê é uma View (Botão, Texto, Imagem). Tudo que organiza as Views é um ViewGroup (Layout).

graph TD
    VG[ViewGroup / Layout] --> V1[View: TextView]
    VG --> V2[View: Button]
    VG --> VG2[ViewGroup: LinearLayout]
    VG2 --> V3[View: ImageView]

Principais Componentes (Views)

  • TextView: Exibe texto (Label).
  • EditText: Entrada de texto (Input).
  • Button: Botão clicável.
  • ImageView: Exibe imagens.
  • CheckBox / RadioButton: Seleção.

2. Layouts Fundamentais 📐

A. LinearLayout (Simples e Rápido)

Organiza itens em uma única direção: Vertical ou Horizontal.

<LinearLayout
    android:orientation="vertical" ...>
    <Button android:text="Botão 1" />
    <Button android:text="Botão 2" />
</LinearLayout>
* Peso (layout_weight): Define quanto espaço o componente ocupa proporcionalmente.

B. FrameLayout (Empilhamento)

Coloca uma View em cima da outra (estilo "sanduíche"). Usado para overlays.

C. ConstraintLayout (O Poderoso) 💪

O padrão moderno. Permite criar layouts complexos e responsivos sem aninhamento excessivo ("flat hierarchy"). Funciona com "amarras" (constraints): * O botão A fica à direita do botão B e abaixo do Texto C.

<Button
    app:layout_constraintTop_toBottomOf="@+id/textoTitulo"
    app:layout_constraintStart_toStartOf="parent"
    app:layout_constraintEnd_toEndOf="parent" />

🆚 Comparação: Auto Layout (iOS)

ConstraintLayout é muito similar ao Auto Layout no iOS. Ambos usam âncoras e restrições para definir posição e tamanho relativo.

3. Unidades de Medida: dp e sp 📏

Nunca use px (pixels)! O Android roda em milhares de telas diferentes.

  • dp (Density-independent Pixels): Para tamanho de componentes e margens. 1dp é aproximadamente 1/160 polegada.
  • sp (Scale-independent Pixels): Para tamanho de fonte. Respeita a configuração de acessibilidade do usuário (se ele aumentou a fonte do sistema).

Regra: Largura/Altura/Margem = dp. Texto = sp.

4. Estilos e Temas (Themes) 💅

Para não repetir código (ex: todo botão ser azul), usamos estilos. Arquivo: res/values/themes.xml (ou styles.xml).

<style name="BotaoPadrao" parent="Widget.MaterialComponents.Button">
    <item name="android:backgroundTint">@color/purple_500</item>
    <item name="android:textSize">16sp</item>
</style>

No layout: style="@style/BotaoPadrao"

5. ViewBinding na Prática 🔗

Vamos ligar o XML ao Kotlin. Suponha um activity_login.xml com um EditText (edtEmail) e um Button (btnLogin).

class LoginActivity : AppCompatActivity() {
    private lateinit var binding: ActivityLoginBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityLoginBinding.inflate(layoutInflater)
        setContentView(binding.root)

        binding.btnLogin.setOnClickListener {
            val email = binding.edtEmail.text.toString()
            if (email.isNotBlank()) {
                // Fazer login
            } else {
                binding.edtEmail.error = "Digite o e-mail!"
            }
        }
    }
}

6. Eventos de Clique (Listeners) 🖱️

O jeito clássico de detectar toque: OnClickListener.

Em Swift (iOS), usamos @IBAction arrastando do Storyboard ou addTarget via código. O conceito é o mesmo: uma função que reage a um evento.

7. Exercício Prático: Tela de Login 📝

Crie uma tela de login simples: 1. ConstraintLayout como raiz. 2. ImageView (Logo) no topo, centralizado. 3. TextInputLayout + TextInputEditText para E-mail (Abaixo da logo). 4. TextInputLayout + TextInputEditText para Senha (Abaixo do e-mail). 5. Button "Entrar" (Largo, match_parent ou preenchendo largura com margens). 6. TextView "Esqueci a senha" (Abaixo do botão).

Dica: Use o Design Editor do Android Studio para arrastar e soltar as constraints!

Próxima Aula: Como sair dessa tela e ir para outra? Navegação entre Telas 🗺️

Aula 06 - Navegação entre Telas 🗺️

Objetivo

Objetivo: Aprender a navegar entre Activities usando Intents, passar dados entre telas e entender a pilha de navegação (Back Stack).

1. O que é uma Intent? 📨

Uma Intent (Intenção) é uma mensagem que o Android usa para pedir uma ação. * "Quero abrir a tela de Login". * "Quero abrir a Câmera". * "Quero compartilhar esse texto".

Tipos de Intent

  1. Explícita: Você diz exatamente qual classe abrir. (Navegação interna).
    • Ex: Ir da Home para Detalhes.
  2. Implícita: Você diz o que quer fazer, e o Android procura quem resolva.
    • Ex: Abrir um site (Navegador), Tirar foto (App de Câmera).

2. Navegando para outra Activity 🚀

val intent = Intent(this, DetalhesActivity::class.java)
startActivity(intent)

🆚 Comparação: Segues e NavigationController (iOS)

No iOS, usamos performSegue ou navigationController?.pushViewController(...). A Intent do Android funciona como o "empurrão" para a próxima tela.

3. Passando Dados (Extras) 📦

Como enviar o nome do usuário para a próxima tela?

Activity A (Origem): 

val intent = Intent(this, HomeActivity::class.java)
intent.putExtra("NOME_USUARIO", "Ricardo")
intent.putExtra("ID_USUARIO", 123)
startActivity(intent)

Activity B (Destino): 

val nome = intent.getStringExtra("NOME_USUARIO")
val id = intent.getIntExtra("ID_USUARIO", -1) // -1 é valor padrão

🆚 Comparação: Prepare for Segue (iOS)

No iOS, interceptamos a navegação no método prepare(for:sender:) para configurar as propriedades da próxima ViewController. No Android, os dados vão "empacotados" na Intent.

4. A Pilha de Voltar (Back Stack) 📚

O Android gerencia as telas como uma pilha de cartas. 1. Abre A. (Pilha: [A]) 2. A chama B. (Pilha: [A, B]) 3. B chama C. (Pilha: [A, B, C]) 4. Usuário aperta Voltar (Back). * C é destruída (onDestroy). * Voltamos para B (onResume). (Pilha: [A, B])

Finalizando uma Activity

Se você chamar finish() na Activity A, ela sai da pilha. * Útil para tela de Login (após logar, não queremos voltar para o login).

// Login ok
startActivity(Intent(this, HomeActivity::class.java))
finish() // Mata a LoginActivity

5. Navigation Component (Moderno) 🧭

Existe uma forma mais moderna de navegar usando Fragments e um gráfico visual (Navigation Graph). * Single Activity Architecture: Uma única Activity hospeda vários Fragments (telas). * XML de Navegação: Define visualmente as setas de uma tela pra outra.

Neste curso focaremos em Intents pois é a base fundamental. O Navigation Component abstrai as Intents por baixo.

6. Intents Implícitas (Abrindo outros apps) 🌍

Quer abrir um site?

val siteIntent = Intent(Intent.ACTION_VIEW, Uri.parse("https://google.com"))
startActivity(siteIntent)

Discar um número?

val discarIntent = Intent(Intent.ACTION_DIAL, Uri.parse("tel:123456789"))
startActivity(discarIntent)

7. Desafio: O Fluxo de Login 🔐

Desenhe o fluxo (no papel ou Mermaid) e implemente o código: 1. Tela Splash: Exibe logo por 2 segundos e vai pra Login. (Usa Handler ou Coroutines para esperar, depois finish()). 2. Tela Login: Digita dados -> Botão Entrar -> Vai pra Home e mata Login. 3. Tela Home: Tem botão "Perfil" -> Vai pra Perfil (sem matar Home). 4. Tela Perfil: Botão "Sair" -> Limpa tudo e volta pra Login.

Dica: Para "limpar tudo" no Logout, use flags na Intent: intent.flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK

Próxima Aula: Chega de jogar código na Activity! Vamos organizar a casa com Arquitetura MVVM 🏗️

Aula 07 - Arquitetura Moderna (MVVM) 🏗️

Objetivo

Objetivo: Entender por que não devemos colocar toda a lógica na Activity (God Class) e aprender o padrão MVVM (Model-View-ViewModel), recomendado pelo Google.

1. O Problema da "God Activity" 🦸‍♂️

Se você colocar lógica de banco de dados, validação, chamadas de API e controle de UI tudo na MainActivity, ela vai virar um monstro de 2.000 linhas. * Dificil de testar. * Dificil de manter. * Perde dados ao girar a tela (rotação destrói a Activity).

2. O Padrão MVVM 📐

Separamos as responsabilidades em 3 camadas:

  1. Model: Dados e Lógica de Negócio (Banco, API, Classes de Dados).
  2. View: UI (Activity/Fragment/XML). Só exibe dados e captura cliques. Não pensa!
  3. ViewModel: O cérebro da tela. Guarda o estado (dados) e sobrevive à rotação de tela.
graph LR
    View["View (Activity/XML)"] <-->|Observa| VM[ViewModel]
    VM -->|Pede Dados| Model["Model (Repository)"]
    Model -->|Retorna Dados| VM

🆚 Comparação: MVC (iOS Clássico) vs MVVM

No iOS antigo (MVC), a ViewController fazia o papel de View e Controller, sofrendo do mesmo problema ("Massive View Controller"). Hoje, iOS também usa muito MVVM (com SwiftUI ou UIKit).

3. ViewModel e LiveData 📡

ViewModel

Classe que herda de androidx.lifecycle.ViewModel.

class MainViewModel : ViewModel() {
    // LiveData: Um dado observável
    val textoBemVindo = MutableLiveData<String>()

    fun carregarDados() {
        // Simula busca de dados
        textoBemVindo.value = "Olá, Aluno!"
    }
}

LiveData

É um container de dados que respeita o ciclo de vida. A View "observa" o LiveData. Se a View morrer (onDestroy), ela para de observar automaticamente.

4. Conectando na Activity (View) 🔌

class MainActivity : AppCompatActivity() {
    // 1. Instanciar o ViewModel (forma moderna)
    private val viewModel: MainViewModel by viewModels()
    private lateinit var binding: ActivityMainBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding.root)

        // 2. Observar o LiveData
        viewModel.textoBemVindo.observe(this) { novoTexto ->
            // Toda vez que o valor mudar, isso roda automaticamente!
            binding.txtTitulo.text = novoTexto
        }

        binding.btnCarregar.setOnClickListener {
            viewModel.carregarDados()
        }
    }
}

5. Vantagens do MVVM

  1. Rotação de Tela: Se girar o celular, a Activity morre e recria. O ViewModel NÃO morre. Os dados continuam lá (novoTexto já estará carregado).
  2. Testabilidade: É fácil testar o ViewModel sem precisar de emulador Android.
  3. Separação: O designer mexe no XML, o dev mexe no ViewModel.

6. Data Binding (O próximo nível) 🧬

Podemos ligar o XML direto no ViewModel, sem nem precisar de código na Activity para atualizar textos.

XML: 

<TextView
    android:text="@{viewModel.textoBemVindo}" ... />
(Não aprofundaremos Data Binding agora, focaremos no ViewBinding + LiveData/Flow).

7. Desafio: Contador MVVM 🔢

Crie um app "Contador de Cliques". 1. Sem MVVM: Variável count na Activity. Gire a tela. O contador zera? (Sim). 2. Com MVVM: Mova a variável count para um ViewModel (MutableLiveData<Int>). * Botão chama viewModel.incrementar(). * Activity observa e atualiza o TextView. * Gire a tela. O contador zera? (Não! 🤩).

Próxima Aula: Onde guardar esses dados para sempre? Persistência de Dados 💾

Aula 08 - Persistência de Dados 💾

Objetivo

Objetivo: Aprender a salvar dados localmente no dispositivo, desde preferências simples (SharedPreferences) até banco de dados estruturado (Room/SQLite).

1. Tipos de Armazenamento Local

  1. SharedPreferences: Chave-Valor. Para configurações simples (Ex: "Modo Escuro ativado", "Nome do Usuário").
  2. Banco de Dados (SQLite/Room): Dados estruturados, relacionais. (Ex: Lista de tarefas, cache de produtos offline).
  3. Arquivos: Fotos, PDF, áudios.

2. SharedPreferences 🔑

Simples, rápido, mas limitado.

// Gravar
val prefs = getSharedPreferences("minhas_config", Context.MODE_PRIVATE)
prefs.edit().putString("username", "Ricardo").apply()

// Ler
val usuario = prefs.getString("username", "Visitante") // Valor padrão

🆚 Comparação: UserDefaults (iOS)

No iOS, o equivalente exato é o UserDefaults.standard. Mesma lógica de chave-valor para configurações leves.

3. Banco de Dados: SQLite e Room 🏛️

O Android vem com SQLite embutido. Mas usar SQLite puro (SQL cru) é verboso e propenso a erros. O Google criou o Room, uma biblioteca que facilita o uso do SQLite (faz parte do Jetpack).

Arquitetura do Room

  1. Entity: A tabela (Classe de dados).
  2. DAO (Data Access Object): Os comandos (Insert, Select, Delete).
  3. Database: O ponto de acesso principal.
classDiagram
    class User {
        +id: Int
        +nome: String
    }
    class UserDao {
        +insert(user)
        +getAll()
    }
    class AppDatabase {
        +userDao()
    }
    AppDatabase --> UserDao : Contém
    UserDao --> User : Manipula

4. Implementando o Room 🔨

Passo 1: Entity (Tabela)

@Entity(tableName = "tarefas")
data class Tarefa(
    @PrimaryKey(autoGenerate = true) val id: Int = 0,
    val titulo: String,
    val concluida: Boolean
)

Passo 2: DAO (comandos)

@Dao
interface TarefaDao {
    @Insert
    suspend fun inserir(tarefa: Tarefa)

    @Query("SELECT * FROM tarefas")
    fun listarTodas(): LiveData<List<Tarefa>>
}

Passo 3: Database

@Database(entities = [Tarefa::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun tarefaDao(): TarefaDao
}

5. Threads e Room: OBRIGATÓRIO 🧵

O Room proíbe acesso ao banco na Thread Principal (UI Thread). Se você tentar ler/gravar na thread principal, o app trava a tela. Por isso usamos suspend fun (Coroutines) ou LiveData (Async).

(Veremos Coroutines a fundo na Aula 11, mas o Room já nos força a usar ou aceitar o padrão assíncrono).

6. Comparação: Core Data / SwiftData (iOS)

  • SQLite/Room (Android): Mais próximo do SQL tradicional. Você cria as queries.
  • Core Data (iOS): Um framework de grafo de objetos, muito poderoso mas complexo. Abstrai totalmente o banco.
  • SwiftData (iOS Novo): Mais parecido com o Room, usa macros e é bem simples.

7. Desafio: Lista de Compras Persistente 🛒

Crie um app simples com: 1. Um EditText e um Button "Adicionar". 2. Ao clicar, salva o item no Room. 3. (Bônus) Exiba a quantidade de itens salvos em um TextView. 4. Feche o app e abra de novo. Os itens devem continuar lá!

Próxima Aula: Como exibir essa lista de compras de forma eficiente? Listas e RecyclerView 📋

Aula 09 - Listas Eficientes (RecyclerView) 📋

Objetivo

Objetivo: Dominar a criação de listas de alta performance com RecyclerView, entender o padrão Adapter/ViewHolder e lidar com cliques em itens.

1. O Problema da ListView Antiga 🐢

Antigamente, usávamos ListView. Ela criava uma View para cada item da lista. Se você tivesse 1.000 contatos, ela tentava criar 1.000 layouts. Resultado: travamentos e consumo absurdo de memória.

2. A Solução: Reciclagem de Views ♻️

O RecyclerView nasceu para ser inteligente. Se cabem 10 itens na tela, ele cria ~12 Views. Quando você rola para baixo, o item que saiu do topo (Item 1) é reciclado e volta para baixo para exibir o Item 13. Apenas o conteúdo (texto/imagem) muda, a View é reaproveitada.

graph TD
    A[Item 1 sai da tela] --> B(Piscina de Reciclagem)
    B --> C[Item 13 entra na tela]
    C --> D{Reusa Layout do Item 1?}
    D -- Sim --> E[Apenas troca o texto]

🆚 Comparação: UITableView (iOS)

O mecanismo é idêntico ao dequeueReusableCell do UITableView no iOS. * Android: RecyclerView + Adapter + ViewHolder * iOS: UITableView + DataSource + UITableViewCell

3. Os 3 Mosqueteiros do RecyclerView ⚔️

Para fazer funcionar, precisamos de 3 peças:

  1. LayoutManager: Define como organizar (Lista vertical? Grade? Carrossel?).
  2. Adapter: O cérebro. Pega os dados e coloca nas Views.
  3. ViewHolder: A gaveta. Guarda as referências dos componentes (findViewById) para não buscar toda hora.

Implementação do Adapter

class ContatoAdapter(private val lista: List<Contato>) : 
    RecyclerView.Adapter<ContatoAdapter.ViewHolder>() {

    // 1. Cria a gaveta (Layout)
    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ViewHolder {
        val view = LayoutInflater.from(parent.context)
            .inflate(R.layout.item_contato, parent, false)
        return ViewHolder(view)
    }

    // 2. Preenche a gaveta com dados (Reciclagem)
    override fun onBindViewHolder(holder: ViewHolder, position: Int) {
        holder.bind(lista[position])
    }

    // 3. Quantos itens tem?
    override fun getItemCount() = lista.size

    // A Gaveta
    class ViewHolder(itemView: View) : RecyclerView.ViewHolder(itemView) {
        fun bind(contato: Contato) {
            itemView.findViewById<TextView>(R.id.txtNome).text = contato.nome
        }
    }
}

4. LayoutManagers: Flexibilidade Total 🤸

Apenas trocando uma linha, você muda a cara da lista:

  • LinearLayoutManager: Lista padrão (Vertical ou Horizontal).
  • GridLayoutManager: Grade (Ex: Galeria de fotos).
  • StaggeredGridLayoutManager: Grade assimétrica (Ex: Pinterest).
recyclerView.layoutManager = GridLayoutManager(this, 2) // 2 colunas

5. Lidando com Cliques 👆

O RecyclerView não tem OnItemClickListener nativo fácil como a ListView. Geralmente passamos uma função (lambda) para o Adapter.

No Adapter: 

class ContatoAdapter(
    private val lista: List<Contato>,
    private val onClick: (Contato) -> Unit // Callback
) ... {

    override fun onBindViewHolder(...) {
        holder.itemView.setOnClickListener { 
            onClick(lista[position]) 
        }
    }
}

Na Activity: 

val adapter = ContatoAdapter(meusContatos) { contatoClicado ->
    Toast.makeText(this, "Cliquei em ${contatoClicado.nome}", Toast.LENGTH_SHORT).show()
}

6. ListAdapter e DiffUtil (Otimização Máxima) 🚀

Se você alterar um item da lista e chamar notifyDataSetChanged(), ele redesinha TUDO. Isso é lento. O DiffUtil compara a lista velha com a nova e atualiza só o que mudou (animação bonita de inserção/remoção).

O ListAdapter é uma classe do Jetpack que já implementa DiffUtil pra você de graça. Sempre prefira usar ListAdapter em vez de RecyclerView.Adapter puro em projetos reais.

7. Desafio: Catálogo de Filmes 🎬

  1. Crie um layout item_filme.xml com Imagem (Cartaz) e Texto (Título).
  2. Crie um Adapter para exibir uma lista de 10 filmes falsos.
  3. Use GridLayoutManager com 2 colunas.
  4. Ao clicar no filme, abra uma DetalhesActivity passando o título do filme.

Próxima Aula: Vamos preencher essa lista com dados reais da internet? Consumo de API REST 🌍

Aula 10 - Consumindo API REST (Retrofit) 🌍

Objetivo

Objetivo: Conectar o aplicativo à internet, baixar dados JSON de uma API REST e convertê-los em objetos Kotlin usando a biblioteca Retrofit.

1. O que é uma API REST? 🔌

É como um garçom. 1. Client (Você): Faz um pedido (Request). "Quero a lista de usuários". 2. API (Garçom): Leva o pedido à cozinha (Servidor). 3. Response: Traz a comida (Dados JSON).

Trabalharemos com JSON JavaScript Object Notation): 

{
  "id": 1,
  "nome": "Ricardo",
  "linguagens": ["Kotlin", "Swift"]
}

2. A Biblioteca Retrofit 🚀

No Android, ninguém faz requisições HTTP "na mão" (abrindo Socket). Usamos o Retrofit (da Square). Ele é o padrão de mercado.

Ele faz 3 mágicas: 1. Conecta na internet. 2. Converte JSON para Objetos Kotlin (usando Gson ou Moshi). 3. Gerencia Threads (com Coroutines).

🆚 Comparação: URLSession / Alamofire (iOS)

  • Nativo: No Android tínhamos HttpUrlConnection (horrível), no iOS tem URLSession (muito bom).
  • Bibliotecas: Android usa Retrofit. iOS usa muito Alamofire (embora o nativo hoje seja suficiente).

3. Implementando em 3 Passos 👣

Passo 1: O Modelo (Data Class)

Deve bater com o JSON.

data class Usuario(
    val id: Int,
    val name: String, // O nome do campo deve ser IGUAL ao do JSON
    val email: String
)

Passo 2: A Interface (Contrato)

Definimos as rotas da API.

interface ApiService {
    @GET("users") // Endpoint: https://api.site.com/users
    suspend fun listarUsuarios(): List<Usuario>

    @GET("users/{id}")
    suspend fun obterUsuario(@Path("id") id: Int): Usuario
}
Note o suspend: indica que é assíncrono (Coroutines).

Passo 3: O Cliente (Instância)

val retrofit = Retrofit.Builder()
    .baseUrl("https://jsonplaceholder.typicode.com/")
    .addConverterFactory(GsonConverterFactory.create()) // Conversor JSON
    .build()

val servico = retrofit.create(ApiService::class.java)

4. Chamando na ViewModel 🧠

Nunca chame a API direto na Activity!

class UserViewModel : ViewModel() {
    val usuarios = MutableLiveData<List<Usuario>>()

    fun buscarDados() {
        viewModelScope.launch { // Coroutine
            try {
                val lista = servico.listarUsuarios()
                usuarios.value = lista
            } catch (e: Exception) {
                // Tratar erro (falta de net, 404, etc)
            }
        }
    }
}

5. Permissão de Internet 🌐

Não esqueça! No AndroidManifest.xml:

<uses-permission android:name="android.permission.INTERNET" />
Sem isso, o app crasha com SecurityException.

6. Autenticação e Segurança 🔐

Apps reais quase sempre precisam de login. Os padrões mais comuns são:

  1. Basic Auth: Envia usuário e senha em cada pedido (Inseguro sozinho).
  2. Bearer Token (JWT): Após o login, o servidor devolve um "Token". Você envia esse token no cabeçalho (Header) de todas as próximas chamadas.
  3. OAuth2: Padrão para "Login com Google/Facebook".

Adicionando Token no Retrofit (Interceptor)

Não precisamos colocar o token manualmente em cada função. Usamos um Interceptor do OkHttp:

val client = OkHttpClient.Builder().addInterceptor { chain ->
    val novoRequest = chain.request().newBuilder()
        .addHeader("Authorization", "Bearer $MEU_TOKEN")
        .build()
    chain.proceed(novoRequest)
}.build()

val retrofit = Retrofit.Builder()
    .client(client) // Vincula o cliente customizado
    .baseUrl(...)
    .build()

7. Ferramentas Úteis 🛠️

  • Postman / Insomnia: Para testar a API antes de codar.
  • Mocky.io: Para criar APIs falsas (Mock) para teste.
  • QuickType.io: Cola o JSON lá, ele gera a Data Class Kotlin pronta! (Dica de ouro ✨).

7. Desafio: Consumindo o GitHub 🐙

  1. Crie uma data class Repo (nome, stars, url).
  2. Use a API pública do GitHub: https://api.github.com/users/{SEU_USER}/repos.
  3. Exiba o nome dos seus repositórios no Logcat (Log.d).

Próxima Aula: O que é esse suspend e launch? Vamos entender o mundo Assíncrono. Threads e Coroutines 🧵

Aula 11 - Threads e Assincronismo (Coroutines) 🧵

Objetivo

Objetivo: Entender o conceito de Main Thread vs Background Thread, o erro ANR, e como programar de forma assíncrona simples e poderosa usando Kotlin Coroutines.

1. O Bloqueio da UI (ANR) 🛑

O Android desenha a tela a cada 16ms (60fps). Tudo isso acontece na Main Thread (Thread Principal). Se você colocar um código que demora 5 segundos na Main Thread (ex: baixar imagem, ler banco pesado): 1. A tela congela. 2. O usuário clica e nada acontece. 3. O Android exibe o ANR (Application Not Responding) e fecha seu app.

Regra Suprema: Operações pesadas (IO, Rede, Banco) SEMPRE em Background.

2. O Passado: Callbacks Hell e Asynctask 🕸️

Antigamente, usávamos AsyncTask ou Callbacks aninhados. 

// Código Java antigo (Pesadelo)
api.getUser(new Callback() {
    onSuccess(user) {
        api.getPosts(user.id, new Callback() {
            onSuccess(posts) {
                // ... pirâmide de chaves ...
            }
        })
    }
})

3. O Futuro: Kotlin Coroutines ⚡

Coroutines permitem escrever código assíncrono como se fosse sequencial. É mágica pura.

  • suspend fun: Uma função que pode ser "pausada" e retomada depois, sem bloquear a thread.
  • Scope: O escopo de vida da coroutine (ex: morreu a tela, cancela o download).
  • Dispatcher: Define em qual thread vai rodar.

Dispatchers (Os entregadores)

  • Dispatchers.Main: Thread Principal (Atualizar UI).
  • Dispatchers.IO: Input/Output (Rede, Banco, Arquivos).
  • Dispatchers.Default: Processamento pesado de CPU (Cálculos, Listas gigantes).

4. Na Prática 👩‍💻

// ViewModelScope: Já vem pronto no ViewModel
fun realizarLogin() {
    viewModelScope.launch { // Inicia a coroutine na Main Thread

        exibirLoading(true) // UI: Main

        // withContext: Troca para thread de IO e PAUSA a execução aqui (sem travar)
        val resultado = withContext(Dispatchers.IO) {
            api.fazerLoginDemorado() // Roda em background
        }

        // Quando voltar, já estamos na Main de novo automaticamente!
        exibirLoading(false)
        tratarResultado(resultado)
    }
}

Olhe como a leitura é linear! Não tem onSuccess, não tem callback.

🆚 Comparação: Swift Concurrency (Async/Await)

O iOS adotou recentemente o async / await, que é muito parecido com Coroutines. * Kotlin: suspend fun / viewModelScope.launch * Swift: async func / Task { await ... }

5. Jobs e Cancelamento 🚫

Uma das maiores vantagens. Se o usuário sair da tela no meio do download: 1. O ViewModel morre (onCleared). 2. O viewModelScope é cancelado automaticamente. 3. A requisição de rede é abortada. 4. Nenhum crash acontece por tentar atualizar uma tela que não existe mais.

6. Comunicação em Tempo Real (Sockets) 🔌

Enquanto o REST (Aula 10) é como um "pedido e resposta", o Socket (TCP) é como uma ligação telefônica: o canal fica aberto.

  • Full-Duplex: Tanto o servidor quanto o app podem enviar dados a qualquer momento.
  • Casos de Uso: Chats, Jogos Online, Cotações de Bolsa em tempo real.
  • Biblioteca Recomendada: Socket.io ou WebSockets nativo.

Note

Trabalhar com Sockets exige cuidado redobrado com o ciclo de vida. Se o app for para o background, você deve decidir se mantém o socket aberto ou fecha para economizar bateria.

7. Desafio: Simulador de Corrida 🏎️

Crie uma função suspend fun corrida() que: 1. Imprima "Preparar..." 2. Espere 1 segundo (delay(1000) - nota: delay não trava a thread, Thread.sleep trava!). 3. Imprima "Apontar..." 4. Espere 1 segundo. 5. Imprima "JÁ!" 6. Chame essa função a partir de um botão e veja se a UI continua responsiva (se o botão clica) durante a contagem.

Próxima Aula: Agora que o app funciona, vamos deixá-lo incrível? UX, Material Design e Animações 🎨

Aula 12 - UX/UI e Material Design 3 🎨

Objetivo

Objetivo: Elevar a qualidade visual do app seguindo os padrões do Google (Material Design 3), entendendo temas, cores dinâmicas e componentes modernos.

1. O que é Material Design? 💄

É o sistema de design do Google (criado em 2014, agora na versão 3 - "Material You"). Ele imita "papel e tinta" (sombras, elevação) mas com cores vibrantes e adaptáveis.

  • Princípio: O design deve se adaptar ao usuário, não o contrário.
  • Foco: Legibilidade, Acessibilidade e consistência.

🆚 Comparação: HIG (Human Interface Guidelines)

A Apple tem o HIG. * Material (Android): Mais colorido, elevação (sombras), Botões FAB (flutuantes), interação mais "brincalhona". * HIG (iOS): Mais plano (flat), minimalista, foco no conteúdo, desfoque (blur).

2. Material 3 (Material You) 🌸

A grande novidade é o Dynamic Color. O App pega as cores do papel de parede do usuário e aplica no tema dele. Se meu wallpaper é verde, todos os botões do seu app ficam verdes (se configurado).

Componentes Chave

  1. FAB (Floating Action Button): Botão flutuante para ação principal.
  2. Bottom Navigation: Barra inferior para navegação principal.
  3. Cards: Conteúdo agrupado com bordas arredondadas.
  4. TopAppBar: Barra superior (antiga Toolbar).

3. Implementando Material no Android 🛠️

Certifique-se de usar a biblioteca correta no build.gradle: implementation 'com.google.android.material:material:1.x.x'

XML - Botão Material

<com.google.android.material.button.MaterialButton
    style="@style/Widget.Material3.Button.Tonal"
    android:text="Botão Moderno" ... />

XML - Card

<com.google.android.material.card.MaterialCardView
    app:cardCornerRadius="16dp"
    app:strokeWidth="1dp"
    app:strokeColor="@color/material_dynamic_primary" ... >

    <!-- Conteúdo do card aqui -->

</com.google.android.material.card.MaterialCardView>

4. Ícones e Tipografia 🔡

  • Ícones: Use Vector Assets (SVG). O Android Studio tem uma biblioteca gigante de ícones embutida. (File > New > Vector Asset).
  • Fontes: Use fontes legíveis. Material 3 usa muito a Roboto e variações de peso (Bold, Medium).

5. Dark Mode (Modo Escuro) 🌑

Hoje em dia é obrigatório. O Android gerencia isso com pastas de recursos: * values/colors.xml (Cores Dia) * values-night/colors.xml (Cores Noite)

Defina nomes semânticos, não literais: * ❌ background_white (Ruim: e se no escuro for preto?) * ✅ background_color (Bom: no dia é branco, na noite é preto)

6. Feedback Tátil e Visual (Ripples) 🌊

O usuário precisa saber que tocou. O Android tem o efeito Ripple (onda) nativo em botões. Se criar um componente customizado, adicione: android:background="?attr/selectableItemBackground"

Se a ação for perigosa (deletar), use cores de erro (vermelho). Se for sucesso, cores de confirmação.

7. Desafio: Redesign do App 💅

Pegue o exercício da Lista de Filmes (Aula 09) ou Tarefas (Aula 08) e aplique Material Design: 1. Use MaterialCardView para os itens da lista. 2. Adicione um FloatingActionButton (+) para incluir novos itens. 3. Crie uma versão de cores para Modo Escuro (teste trocando o tema do celular). 4. Certifique-se que os textos têm contraste suficiente.

Próxima Aula: Sensores, GPS e Câmera! Acessando Hardware 📸

Aula 13 - Sensores e Hardware �

Objetivo

Objetivo: Aprender a acessar os recursos físicos do dispositivo, como Câmera, GPS (Localização) e Sensores de Movimento (Acelerômetro), entendendo o sistema de permissões em tempo de execução.

1. O Mundo do Hardware �

Diferente da Web, o App Nativo tem acesso direto aos sensores do celular. Os principais são: * Movimento: Acelerômetro, Giroscópio. * Posição: GPS, Magnetômetro (Bússola). * Ambiente: Luz, Barômetro (Pressão), Temperatura. * Interface: Câmera, Microfone, Biometria (Digital/Rosto).

2. Permissões (Permissions) 🔑

No Android, as permissões são divididas em duas categorias:

  1. Normais: Não oferecem risco à privacidade (ex: Bluetooth, Internet). Definidas apenas no AndroidManifest.xml.
  2. Perigosas: Acessam dados sensíveis (ex: Câmera, GPS, Contatos). Precisam ser pedidas ao usuário em tempo de execução (pop-up).

Solicitando Permissão (Moderno)

val requestPermissionLauncher = registerForActivityResult(
    ActivityResultContracts.RequestPermission()
) { isGranted: Boolean ->
    if (isGranted) {
        // Permissão concedida! Abrir câmera...
    } else {
        // Permissão negada... explicar por que precisa.
    }
}

// Chamar quando precisar
requestPermissionLauncher.launch(Manifest.permission.CAMERA)

3. Localização e GPS 🗺️

Para obter a localização, usamos o Fused Location Provider (parte do Google Play Services). Ele é mais inteligente e economiza bateria.

val fusedLocationClient = LocationServices.getFusedLocationProviderClient(this)

fusedLocationClient.lastLocation.addOnSuccessListener { location : Location? ->
    // Got last known location. In some rare situations this can be null.
    location?.let {
        val lat = it.latitude
        val long = it.longitude
    }
}

4. Sensores de Movimento 🎢

O Android usa o SensorManager para escutar dados do acelerômetro, por exemplo.

val sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager
val sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)

val listener = object : SensorEventListener {
    override fun onSensorChanged(event: SensorEvent?) {
        val x = event?.values?.get(0) // Inclinação X
        // ...
    }
    override fun onAccuracyChanged(s: Sensor?, a: Int) {}
}

sensorManager.registerListener(listener, sensor, SensorManager.SENSOR_DELAY_NORMAL)

5. Câmera (CameraX) 📸

O Google criou a biblioteca CameraX para facilitar o uso da câmera, que era muito complexo antigamente. Ela lida com as diferenças entre fabricantes automaticamente.

Principais casos de uso: 1. Preview: Ver a imagem na tela. 2. Image Capture: Tirar foto e salvar. 3. Image Analysis: Ler QR Code ou detectar rostos em tempo real.

6. Bluetooth e Dispositivos Embarcados 🔵

Muitas vezes o app precisa falar com um Arduino, ESP32 ou fone de ouvido. * Bluetooth Classic: Para áudio e transferência de arquivos grande. * BLE (Bluetooth Low Energy): Para sensores e wearables. Economiza muita bateria.

// Exemplo simplificado de scan
val bluetoothAdapter: BluetoothAdapter? = BluetoothAdapter.getDefaultAdapter()
bluetoothAdapter?.startDiscovery()

7. Telefonia e SMS 📞

O Android permite que seu app interaja com as funções de telefone. * Fazer Chamadas: Precisa de permissão CALL_PHONE. * Enviar SMS: Use SmsManager.

val smsManager: SmsManager = SmsManager.getDefault()
smsManager.sendTextMessage("numero", null, "Olá Mundo!", null, null)

8. Mapas e Orientação 🗺️

Além de saber a latitude, podemos mostrar isso visualmente. * Google Maps SDK: A biblioteca padrão para exibir mapas, desenhar rotas e colocar marcadores. * Geocoding: Transformar coordenadas (lat/long) em endereços reais (Rua X, nº 10).

9. Biometria (Impressão Digital) ☝️

O BiometricPrompt exibe aquela janela padrão do sistema para o usuário colocar o dedo ou olhar para a câmera.

🆚 Comparação: Core Motion e CameraControl (iOS)

No iOS, o framework Core Motion lida com sensores, e a AVFoundation lida com a Câmera. O sistema de permissões do iOS é ainda mais rígido desde o início.

7. Desafio: O Detector de Balanço shake

Crie um app que: 1. Escute o acelerômetro. 2. Se o valor de aceleração passar de um limite (usuário balançou o celular), mude a cor de fundo da tela para uma cor aleatória. 3. Imprima no Logcat: "Balanço detectado!".

Próxima Aula: Como garantir que seu código não quebre? Testes e Debugging 🐞

Aula 14 - Testes, Qualidade e Debugging 🐞

Objetivo

Objetivo: Aprender a encontrar e corrigir erros de forma profissional, utilizar o Logcat e escrever testes automatizados (Unitários e de UI) para garantir a estabilidade do app.

1. O Logcat: Seu melhor amigo 📝

Esqueça o println. No Android, usamos a classe Log para monitorar o que acontece.

Log.v("TAG", "Verbose - Detalhes irrelevantes")
Log.d("TAG", "Debug - Informação para o dev")
Log.i("TAG", "Info - Evento importante (Login, etc)")
Log.w("TAG", "Warning - Algo estranho, mas não quebrou")
Log.e("TAG", "Error - QUEBROU! 💥")

No Android Studio, você pode filtrar logs pela TAG ou pelo nível de erro.

2. Debugging Passo a Passo 🛠️

Quando o app trava ou tem um comportamento estranho: 1. Coloque um Breakpoint (clique na lateral da linha). 2. Rode o app em modo Debug (Ícone do besouro). 3. O app vai "congelar" naquela linha e você poderá ver o valor de todas as variáveis.

3. Pirâmide de Testes 🏔️

  1. Testes Unitários (70%): Testam pequenas partes (funções) isoladas. São ultra-rápidos. Rodam no computador (JVM).
  2. Testes de Integração (20%): Testam a conversa entre componentes (ex: ViewModel + Repositório).
  3. Testes de UI / Instrumentados (10%): Testam o app rodando no emulador. Clicam em botões, abrem telas. (Ex: Espresso).

4. Escrevendo um Teste Unitário 🧪

Pasta: src/test/java

class CalculadoraTest {
    @Test
    fun soma_estaCorreta() {
        val result = Calculadora().somar(2, 2)
        assertEquals(4, result)
    }
}

🆚 Comparação: XCTest (iOS)

No iOS, usamos o framework XCTest. A lógica é a mesma: Criar uma classe de teste e usar métodos assert para verificar se o resultado bate com o esperado.

5. Testes de UI com Espresso ☕

O Espresso é a biblioteca padrão para testar a interface.

@Test
fun clicarNoBotao_deveMudarTexto() {
    onView(withId(R.id.btnEnviar)).perform(click())
    onView(withId(R.id.txtResultado)).check(matches(withText("Enviado!")))
}

6. Gerenciamento de Erros (Try/Catch) 🛡️

Nunca deixe o app fechar sozinho na mão do usuário.

try {
    val resultado = 10 / 0
} catch (e: ArithmeticException) {
    Log.e("AVISO", "Divisão por zero!", e)
    exibirMensagemAmigavel("Ops, algo deu errado.")
}

7. Desafio: O Caçador de Bugs 🕵️‍♂️

Vou te dar um código com 3 erros. Tente identificar quais são (mentalmente ou no AS):

var lista: List<String>? = null

fun main() {
    // Erro 1:
    println(lista.size) 

    // Erro 2:
    val num = "123a".toInt()

    // Erro 3 (UI):
    txtView.text = "Olá" // Tentando atualizar UI dentro de uma Thread comum?
}
Respostas
  1. NullPointerException: A lista é nula. Deveria usar lista?.size.
  2. NumberFormatException: A string tem um 'a'. Deveria usar toIntOrNull().
  3. CalledFromWrongThreadException: UI só pode ser alterada na Main Thread.

Próxima Aula: Hora de mostrar seu app pro mundo! Publicação na Play Store 🚀

Aula 15 - Publicação e Google Play Store 🚀

Objetivo

Objetivo: Conhecer o processo final de transformar seu código em um produto real, gerando o arquivo de produção (.aab), criando artes para a loja e entendendo os critérios de revisão.

1. APK vs AAB 📦

  • APK (Android Package): Formato antigo. É um "zip" com tudo dentro.
  • AAB (Android App Bundle): Formato moderno (obrigatório para novos apps). O Google Play usa o Bundle para gerar APKs otimizados para cada celular (só envia as imagens daquela densidade de tela, economizando espaço).

2. Preparando o App para Produção ⚙️

  1. Remover Logs: Limpe os Log.d ou use bibliotecas como o Timber para gerenciar isso.
  2. Ofuscação (ProGuard/R8): Protege seu código contra pirataria e diminui o tamanho do app removendo código não usado.
  3. Versão: Atualize o versionCode (número inteiro) e versionName (ex: "1.0.0") no build.gradle.

3. Gerando a Chave de Assinatura (Keystore) 🔑

O Android exige que todo app seja assinado digitalmente. IMPORTANTE: Se você perder o arquivo .jks (keystore), você nunca mais poderá atualizar seu app na loja. Guarde em 3 lugares diferentes! 💾

4. Google Play Console 🎮

É o portal do desenvolvedor Google. * Custo: Taxa única de $25. * Revisão: O app passa por uma análise automatizada e humana (pode levar de 1 a 7 dias).

5. Materiais para a Loja (Marketing) 🎨

Você vai precisar de: 1. Título e Descrição (Curta e Longa). 2. Ícone do App (512x512). 3. Feature Graphic (1024x500 - Arte de destaque). 4. Screenshots (Capturas de tela do app rodando).

6. Testes Rápidos (Canais de Teste) 🧪

Antes de lançar para o público geral, use os canais: * Teste Interno: Para sua equipe (instantâneo). * Teste Fechado (Beta): Para convidados. * Teste Aberto: Qualquer um pode baixar e testar.

🆚 Comparação: App Store Connect e TestFlight (iOS)

No iOS, a taxa é anual ($99). O portal chama-se App Store Connect e o app de testes oficial é o TestFlight. A revisão da Apple é conhecida por ser muito mais rigorosa que a do Google.

7. Desafio: Checklist de Lançamento ✅

Imagine que você terminou seu app de Notas. Marque o que você faria ANTES de clicar em "Gerar AAB": - [ ] Deixar a senha do banco de dados exposta no código? (Espero que não! 😱) - [ ] Ativar o minifyEnabled true para encolher o código? - [ ] Testar em um celular físico real? - [ ] Verificar se as Strings estão traduzidas para PT-BR?

Próxima Aula: O grande final! Projeto de Conclusão de Curso 🎓

Aula 16 - Projeto Final e Conclusão 🎓

Objetivo

Objetivo: Aplicar TODO o conhecimento adquirido (Layouts, Navegação, MVVM, API, Banco de Dados, Sensores) na criação de um aplicativo completo e funcional de portfólio.

1. O Desafio Final: "My Daily Companion" 🦸‍♂️

Você deve criar um app que ajude o usuário no seu dia a dia. Escolha UM dos temas abaixo ou crie o seu:

  1. App de Finanças: Cadastra despesas, salva no Room, exibe lista com RecyclerView e totalizador.
  2. App de Clima: Consome uma API (OpenWeather) baseada no GPS (Localização) do usuário.
  3. Catálogo de Livros/Games: Consome uma API ou salva localmente as capas e detalhes, com busca e favoritos.
  4. App de Fitness: Usa o contador de passos (sensor) e cronômetro para marcar exercícios.

2. Requisitos Obrigatórios 📋

O projeto deve conter obrigatoriamente: - [ ] Arquitetura MVVM (ViewModel + LiveData). - [ ] Interface Material Design 3 (Cards, Botões, Cores consistentes). - [ ] Navegação entre pelo menos 2 telas (Lista e Detalhes). - [ ] Persistência (Room ou SharedPreferences) OU Networking (Retrofit). - [ ] Boas Práticas: Código limpo, strings traduzidas, Logcat para debug.

3. Dicas para um Portfólio de Elite ✨

Para um recrutador olhar seu projeto e dizer "UAU": 1. README.md no GitHub: Explique o que o app faz, coloque prints/GIFs dele rodando e liste as tecnologias usadas. 2. Dark Mode: Suporte total ao modo escuro. 3. Tratamento de Erros: Se a internet cair, mostre uma tela bonita de "Ops!", não deixe o app branco. 4. Animações: Use o MotionLayout ou simples ViewPropertyAnimator para dar vida aos botões.

4. Onde continuar estudando? 📚

O mundo mobile não para. O que aprender agora? 1. Jetpack Compose: A nova forma de criar UI no Android (substituindo o XML). 2. Kotlin Multiplatform (KMP): Use a mesma lógica Kotlin no Android e no iOS. 3. SwiftUI: Se quiser entrar de vez no mundo Apple. 4. Dependency Injection (Hilt/Koin): Para projetos gigantes.

5. Mensagem Final 🌟

Parabéns! Você saiu do ZERO e agora entende como as ferramentas que movem o mundo (apps) são construídas. O caminho é longo, mas a base que você construiu aqui é sólida como o Kernel Linux do Android.

"A melhor maneira de prever o futuro é inventá-lo." - Steve Jobs (e adaptado para os devs Mobile).

FIM DO CURSO 🚀🚀🚀 Desejamos muito sucesso na sua jornada como Desenvolvedor Mobile Nativo!

Aula 17 - SwiftUI Avançado e Animações Customizadas 🍏

Objetivo Pedagógico

Objetivo: Construir interfaces reativas sofisticadas com SwiftUI: ViewBuilders, Layout Protocol customizado, animações baseadas em física de molas (Spring Animations), transições combinadas e Canvas de desenho de alto rendimento.

📑 1. Fundamentos Teóricos & Análise Técnica

O paradigma de desenvolvimento para o ecossistema Apple consolidou o SwiftUI como seu framework declarativo primário, operando sobre um sistema de tipos fortemente tipado e otimizado pelo compilador Swift.

A engenharia avançada de interfaces em SwiftUI apoia-se em conceitos estruturais profundos: 1. O Mecanismo de Diffing e Identidade de Views: - Cada View em SwiftUI é uma struct imutável e leve alocada na stack. O SwiftUI reconcilia a árvore de renderização analisando duas categorias de identidade: - Identidade Explícita: Atribuída via modificador .id(...) ou protocolos como Identifiable. - Identidade Estrutural: Inferida pela posição exata da View dentro das ramificações lógicas do código (if/else). - Mutações de estado acionam o recálculo do corpo var body: some View. Preservar a estabilidade da identidade evita reconstruções desnecessárias de nós de renderização gráfica. 2. O Protocolo Layout (iOS 16+): - Permite a criação de algoritmos de distribuição espacial sob medida contornando os containers convencionais (HStack, VStack, LazyVGrid). - Opera através dos métodos sizeThatFits (cálculo de dimensões ideais) e placeSubviews (posicionamento geométrico com precisão de submícron). 3. Animações Fluidas Baseadas em Física (Spring Animations): - Abandono das curvas Bezier lineares em prol de modelos físicos de massa, rigidez e amortecimento (Damping), produzindo respostas táteis naturais e interrompíveis pelo usuário.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    State["@State / @Observable Mutação"] --> Engine["SwiftUI Dependency Graph"]
    Engine --> Diff["Verificação de Identidade Estrutural"]
    Diff --> Body["Avaliação do body: some View"]
    Body --> Layout["Layout Protocol (sizeThatFits -> placeSubviews)"]
    Layout --> Render["Render Engine (Metal / CoreAnimation)"]
    Render --> Screen["Tela Retina a 120Hz (ProMotion)"]
    style State fill:#e1f5fe,stroke:#01579b
    style Engine fill:#fff3e0,stroke:#e65100
    style Body fill:#f3e5f5,stroke:#7b1fa2
    style Layout fill:#e8f5e9,stroke:#2e7d32
    style Screen fill:#e0f2f1,stroke:#00695c

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Structs Leves vs. Objetos UIView: Views são descrições imutáveis efêmeras; CoreAnimation mantém as superfícies gráficas persistentes na GPU. - Física de Molas (Interactive Springs): Animações que mantêm o vetor de velocidade residual quando interrompidas por novos gestos do usuário. - Canvas e Renderização Metal: Uso do elemento Canvas para desenhar milhares de partículas ou gráficos complexos sem sobrecarga de Views. - Suporte Nativo a Acessibilidade (VoiceOver): Associação direta de traços de acessibilidade e agrupamento semântico de elementos na árvore de acessibilidade.

🛠️ 2. Implementação Prática em iOS Nativo Moderno com SwiftUI

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// InteractiveCardView.swift (SwiftUI com Animações Spring e ViewModifier)
import SwiftUI

struct TransactionItem: Identifiable, Equatable {
    let id = UUID()
    let merchant: String
    let amount: Double
    let category: String
}

struct SpringCardView: View {
    let item: TransactionItem
    @State private var isExpanded: Bool = false

    var body: some View {
        VStack(alignment: .leading, spacing: 8) {
            HStack {
                Text(item.merchant)
                    .font(.headline)
                    .foregroundColor(.primary)
                Spacer()
                Text(String(format: "$%.2f", item.amount))
                    .font(.title3.bold())
                    .foregroundColor(item.amount > 100 ? .red : .green)
            }

            if isExpanded {
                Text("Categoria: \(item.category)")
                    .font(.subheadline)
                    .foregroundColor(.secondary)
                    .transition(.asymmetric(
                        insertion: .opacity.combined(with: .scale(scale: 0.8)),
                        removal: .opacity
                    ))
            }
        }
        .padding()
        .background(Color(.secondarySystemBackground))
        .cornerRadius(16)
        .shadow(radius: isExpanded ? 8 : 2)
        .onTapGesture {
            withAnimation(.spring(response: 0.4, dampingFraction: 0.7, blendDuration: 0)) {
                isExpanded.toggle()
            }
        }
    }
}

💡 Análise Passo a Passo do Código

  1. Transição Assimétrica (.asymmetric): Permite animar a entrada com escala e desvanecimento combinados enquanto a saída ocorre de forma suave.
  2. Física .spring Parametrizada: Controla a resposta elástica com taxa de amortecimento de 0.7, simulando comportamento físico realista.
  3. Modificadores Declarativos: Aplica elevação de sombra e cantos arredondados sem invocar APIs legadas do CoreGraphics.

🎯 3. Próximos Passos & Sequência Didática

Aula 18 - Arquitetura MVVM/VIPER com Concorrência Swift ⚡

Objetivo Pedagógico

Objetivo: Conceber a camada de apresentação arquitetada com MVVM usando a nova macro @Observable (Observation Framework), aliada à Concorrência Estruturada do Swift moderna (async/await, Tasks e Actors isolados).

📑 1. Fundamentos Teóricos & Análise Técnica

A linguagem Swift revolucionou o paradigma de concorrência com o fim dos callbacks de encadeamento (Pyramid of Doom) e a introdução da Concorrência Estruturada Nativa.

A evolução arquitetural moderna articula dois grandes pilares: 1. O Framework de Observação (@Observable): - Substitui o protocolo verboso ObservableObject e a propriedade @Published do Combine. - Utiliza macros em tempo de compilação para rastrear o acesso específico a cada propriedade da classe. As Views do SwiftUI agora só recalculam se a propriedade específica que elas leem for modificada, evitando recomposições abrangentes. 2. Atores e Segurança de Dados em Concorrência (Data-Race Safety): - actor: Tipo de referência que protege o acesso ao seu estado interno com sincronização automática. Apenas uma thread pode executar código dentro do ator por vez. - @MainActor: Atributo que garante que mutações de estado e chamadas de UI sejam executadas obrigatoriamente na thread principal (Main Thread), eliminando avisos de concorrência estrita do Swift 6. 3. Tasks e Cancelamento Cooperativo: - As tarefas herdam prioridades do chamador. O cancelamento é cooperativo: rotinas longas devem verificar periodicamente Task.isCancelled para suspender trabalho desnecessário.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    View["SwiftUI View"] -->|Invoca Método Assíncrono| VM["ViewModel (@Observable @MainActor)"]
    VM -->|Task Assíncrona| Service["NetworkService (Actor Isolado)"]
    Service -->|Chamada URLSession async| Endpoint["API Remota"]
    Endpoint -->|Payload JSON| Service
    Service -->|Retorna Modelo Decodificado| VM
    VM -->|Atualiza Propriedade do ViewModel| VM
    VM -.->|Notifica Apenas Propriedade Modificada| View
    style View fill:#e1f5fe,stroke:#01579b
    style VM fill:#fff3e0,stroke:#e65100
    style Service fill:#f3e5f5,stroke:#7b1fa2
    style Endpoint fill:#e8f5e9,stroke:#2e7d32

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Macro @Observable do Swift 5.9+: Rastreamento granular de dependências que elimina a sobrecarga de memória do Combine na camada de apresentação. - Isolamento com @MainActor: Garante formalmente que nenhuma mutação de estado de View ocorra fora da thread principal. - Actors para Proteção de Estado Concorrente: Estrutura nativa do compilador que erradica condições de corrida em memória (Data Races). - Cancelamento Cooperativo de Tasks: Propagação automática de sinais de cancelamento quando a View é desmontada do container de navegação.

🛠️ 2. Implementação Prática em Swift Moderno, Concorrência Estruturada e Macro @Observable

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// TransactionsViewModel.swift (Arquitetura MVVM com @Observable e @MainActor)
import SwiftUI
import Observation

@Observable
@MainActor
final class TransactionsViewModel {
    var transactions: [TransactionItem] = []
    var isLoading: Bool = false
    var errorMessage: String?

    private let service: TransactionActorService

    init(service: TransactionActorService = TransactionActorService()) {
        self.service = service
    }

    func loadTransactions() async {
        isLoading = true
        errorMessage = nil

        do {
            transactions = try await service.fetchRemoteTransactions()
        } catch {
            errorMessage = "Falha ao carregar dados: \(error.localizedDescription)"
        }

        isLoading = false
    }
}

// Actor garantindo isolamento total de threads para o serviço
actor TransactionActorService {
    func fetchRemoteTransactions() async throws -> [TransactionItem] {
        // Simulação de chamada de rede sem bloquear threads de renderização
        try await Task.sleep(nanoseconds: 600_000_000)
        return [
            TransactionItem(merchant: "Apple Store", amount: 1299.00, category: "Hardware"),
            TransactionItem(merchant: "Coffee Shop", amount: 4.50, category: "Alimentação")
        ]
    }
}

💡 Análise Passo a Passo do Código

  1. Macro @Observable: Elimina a necessidade de publicar objetos com Combine e permite rastreamento atômico de propriedades.
  2. Anotação @MainActor na Classe: Confina todas as alterações de variáveis de estado à thread de interface gráfica.
  3. Isolamento com actor TransactionActorService: Garante segurança de acesso concorrente sem a complexidade de semáforos ou NSLock.

🎯 3. Próximos Passos & Sequência Didática

Aula 19 - Persistência Local com SwiftData e Testes Unitários 💾

Objetivo Pedagógico

Objetivo: Implementar persistência de dados local com SwiftData utilizando a macro @Model, relacionamentos complexos, migrações de esquema e suíte de testes unitários com containers em memória.

📑 1. Fundamentos Teóricos & Análise Técnica

A Apple lançou o SwiftData para substituir a complexidade legada do Core Data, oferecendo uma API nativa em Swift focada em segurança de tipos, concorrência moderna e integração perfeita com SwiftUI.

A estrutura do SwiftData opera através de conceitos elegantes e expressivos: 1. A Macro @Model: - Converte diretamente qualquer classe Swift convencional em um esquema de dados relacional persistível, dispensando editores visuais de modelos .xcdatamodeld. - Gera automaticamente metadados para controle de integridade, transformando propriedades em colunas e mapeando relacionamentos (@Relationship) com regras de deleção em cascata (Cascade Delete). 2. ModelContainer e ModelContext: - ModelContainer: A espinha dorsal que gerencia o armazenamento físico no disco (usando SQLite sob o capô) e o controle de versões de esquema. - ModelContext: O espaço de trabalho (Scratchpad) onde objetos são criados, modificados e removidos antes da confirmação atômica no banco. 3. Estratégia de Testes Unitários com Containers em Memória: - Para garantir testes unitários rápidos e isolados, cria-se uma configuração de ModelContainer configurada com isStoredInMemoryOnly: true. Isso permite instanciar e destruir bancos SQLite na memória RAM sem deixar resquícios no disco do simulador.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    View["SwiftUI View (@Query)"] --> Context["ModelContext (Scratchpad em Memória)"]
    Context --> Container["ModelContainer (Schema & Config)"]
    Container --> SQLite["Armazenamento SQLite em Disco"]
    TestRunner["XCTest Suite"] --> TestContainer["ModelContainer (inMemoryOnly: true)"]
    TestContainer --> TestContext["ModelContext Isolado"]
    style View fill:#e1f5fe,stroke:#01579b
    style Context fill:#fff3e0,stroke:#e65100
    style Container fill:#f3e5f5,stroke:#7b1fa2
    style SQLite fill:#e8f5e9,stroke:#2e7d32
    style TestRunner fill:#ffebee,stroke:#c62828

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Macro Declarativa @Model: Elimina o código de mapeamento relacional transformando classes puras em esquemas SQLite tipados. - Propriedade @Query no SwiftUI: Alimenta automaticamente a interface do usuário mantendo-a atualizada sempre que há inserções no banco. - ModelContainer em Memória para Testes: Permite rodar centenas de testes unitários em paralelo sem contaminação de estado persistido. - Relacionamentos Fortemente Tipados: Declaração de cardinalidade 1-N e N-N com verificação estrita pelo compilador.

🛠️ 2. Implementação Prática em Persistência Nativa Apple, SwiftData e XCTest

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// AccountSwiftDataTests.swift (Modelo SwiftData e Suíte de Testes Unitários Isolados)
import XCTest
import SwiftData
@testable import SeuApp

@Model
final class UserAccount {
    @Attribute(.unique) var email: String
    var username: String
    var balance: Double

    init(email: String, username: String, balance: Double = 0.0) {
        self.email = email
        self.username = username
        self.balance = balance
    }
}

final class UserAccountTests: XCTestCase {
    var container: ModelContainer!
    var context: ModelContext!

    @MainActor
    override func setUp() {
        super.setUp()
        let config = ModelConfiguration(isStoredInMemoryOnly: true)
        container = try! ModelContainer(for: UserAccount.self, configurations: config)
        context = container.mainContext
    }

    @MainActor
    func test_insercaoConta_devePersistirComSucesso() throws {
        let novaConta = UserAccount(email: "dev@apple.com", username: "AppleDev", balance: 500.0)
        context.insert(novaConta)
        try context.save()

        let descriptor = FetchDescriptor<UserAccount>(predicate: #Predicate { $0.email == "dev@apple.com" })
        let resultados = try context.fetch(descriptor)

        XCTAssertEqual(resultados.count, 1)
        XCTAssertEqual(resultados.first?.username, "AppleDev")
        XCTAssertEqual(resultados.first?.balance, 500.0)
    }
}

💡 Análise Passo a Passo do Código

  1. Configuração isStoredInMemoryOnly: true: Executa a suíte de persistência integralmente na memória RAM, garantindo velocidade extrema e determinismo.
  2. Predicado Tipado #Predicate: Macro que valida condições lógicas de consulta SQL em tempo de compilação.
  3. Anotação @Attribute(.unique): Impõe restrição de unicidade na coluna diretamente a nível de banco relacional.

🎯 3. Próximos Passos & Sequência Didática

Aula 20 - Projeto Capstone: App iOS Nativo Completo Autônomo 🚀

Objetivo Pedagógico

Objetivo: Conceber e implementar um aplicativo iOS nativo completo de nível corporativo: interface SwiftUI responsiva com transições avançadas, arquitetura limpa orientada a domínios, persistência com SwiftData e processamento assíncrono com BackgroundTasks (BGTaskScheduler).

📑 1. Fundamentos Teóricos & Análise Técnica

O Projeto Capstone de iOS sintetiza as melhores práticas recomendadas pela Apple para aplicações comerciais modernas: 1. Arquitetura Modular Limpa: - Separação entre apresentação SwiftUI, entidades de domínio imutáveis e repositórios de dados mediadores. 2. Execução em Segundo Plano com BGTaskScheduler: - Agendamento de tarefas pesadas de sincronização e atualização de dados (BGAppRefreshTask) gerenciadas pelo sistema operacional iOS com base nos padrões de uso do usuário e carga da bateria. 3. Design Adaptativo para Ecossistema Apple: - Layout responsivo que se adapta perfeitamente a Dynamic Island, entalhes de tela e diferentes tamanhos de tela (iPhone mini ao Pro Max e iPads via SplitView). 4. Resiliência e Observabilidade: - Uso de os.Logger para telemetria estruturada e compatibilidade estrita com os padrões de concorrência do Swift 6.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    UI["SwiftUI Flow (Dynamic Island & ProMotion)"] --> VM["ViewModel (@Observable @MainActor)"]
    VM --> Repo["Repository Pattern (Mediador)"]
    Repo --> Local["SwiftData ModelContainer (Offline First)"]
    Repo --> Remote["URLSession Async HTTP/3"]
    BG["BGTaskScheduler (Sincronização em Background)"] --> Repo
    style UI fill:#e1f5fe,stroke:#01579b
    style VM fill:#fff3e0,stroke:#e65100
    style Repo fill:#f3e5f5,stroke:#7b1fa2
    style Local fill:#e8f5e9,stroke:#2e7d32
    style BG fill:#ffebee,stroke:#c62828

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Padrão de Repositório Mediador: Isola os detalhes da API REST e do banco local por trás de uma interface assíncrona limpa. - Background App Refresh Ético: Respeito às diretrizes de eficiência energética da Apple através de BGAppRefreshTask. - Logger Estruturado Nativo (os.Logger): Gravação de telemetria operacional de alta performance com privacidade de dados do usuário. - Zero Warning Policy no Swift 6: Conformidade absoluta com as verificações estritas de segurança de concorrência (Strict Concurrency Checking).

🛠️ 2. Implementação Prática em Engenharia iOS Nativa, SwiftUI, SwiftData e Background Tasks

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// BackgroundSyncScheduler.swift (Agendador de Tarefas em Segundo Plano com BGTaskScheduler)
import Foundation
import BackgroundTasks
import os.log

final class BackgroundSyncScheduler {
    static let shared = BackgroundSyncScheduler()
    private let taskIdentifier = "com.portal.ios.apprefresh"
    private let logger = Logger(subsystem: "com.portal.ios", category: "BackgroundSync")

    func registerBackgroundTask() {
        BGTaskScheduler.shared.register(forTaskWithIdentifier: taskIdentifier, using: nil) { task in
            guard let refreshTask = task as? BGAppRefreshTask else { return }
            self.handleAppRefresh(task: refreshTask)
        }
    }

    func scheduleNextSync() {
        let request = BGAppRefreshTaskRequest(identifier: taskIdentifier)
        // Agendar para no mínimo 4 horas no futuro
        request.earliestBeginDate = Date(timeIntervalSinceNow: 4 * 3600)

        do {
            try BGTaskScheduler.shared.submit(request)
            logger.info("Próxima sincronização agendada com sucesso.")
        } catch {
            logger.error("Falha ao agendar sincronização em segundo plano: \(error.localizedDescription)")
        }
    }

    private func handleAppRefresh(task: BGAppRefreshTask) {
        scheduleNextSync() // Reagendamento cíclico

        let syncTask = Task {
            logger.info("Executando sincronização em segundo plano...")
            // Simula sincronização com o repositório
            try await Task.sleep(nanoseconds: 2_000_000_000)
            task.setTaskCompleted(success: true)
        }

        task.expirationHandler = {
            self.logger.warning("Tempo limite do sistema operacional atingido! Cancelando task.")
            syncTask.cancel()
        }
    }
}

💡 Análise Passo a Passo do Código

  1. Registro no BGTaskScheduler: Integra a rotina de atualização contínua diretamente com o gerenciador de energia do iOS.
  2. Definição de earliestBeginDate: Evita abusos de consumo de bateria distribuindo o agendamento em janelas eficientes.
  3. Tratamento de expirationHandler: Permite suspender graciosamente operações caso o sistema operacional necessite dos recursos antes da conclusão.

🎯 3. Próximos Passos & Sequência Didática

Exercícios

🏋️ Exercícios do Curso

Lista completa das 20 unidades de exercicios organizadas em 5 módulos didáticos.

Exercícios 01 - Introdução ao Mobile 📱

🟢 Fáceis

  1. Conceitos: Explique com suas palavras a diferença entre um App Nativo e um App Híbrido.
  2. Ecossistema: Cite 3 diferenças técnicas ou de mercado entre o desenvolvimento Android e iOS.

🟡 Médios

  1. Cenário: Uma padaria quer um app simples apenas para mostrar o cardápio, sem login ou recursos complexos. O orçamento é curto. Que tecnologia você recomendaria (Nativo, Híbrido ou PWA)? Justifique.
  2. Hardware: Por que apps Nativos tendem a ter melhor acesso a recursos de hardware (como Bluetooth ou Sensores) do que soluções Web?

🔴 Desafio

  1. Análise de Caso: Você foi contratado pelo "Instagram" em 2010. O objetivo é criar a melhor experiência de rolagem de feed possível, com filtros de imagem aplicados em tempo real.
    • Escolha a tecnologia (Nativo vs Híbrido da época) e justifique considerando Performance vs Custo.
    • Desenhe (mentalmente ou no papel) como seria a arquitetura macro: O app processa o filtro no celular ou no servidor? Por que?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceitos **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Desenvolvimento Mobile**, o conceito abordado (Conceitos) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Ecossistema **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Desenvolvimento Mobile**, o conceito abordado (Ecossistema) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Cenário **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Desenvolvimento Mobile**, o conceito abordado (Cenário) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Hardware **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Desenvolvimento Mobile**, o conceito abordado (Hardware) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Análise de Caso **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Desenvolvimento Mobile**, o conceito abordado (Análise de Caso) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 02 - Fundamentos Java ☕

🟢 Fáceis

  1. Classe Simples: Crie uma classe Livro com atributos titulo e autor. Adicione um construtor.
  2. Tipos: Qual a diferença entre int e Integer? Dê um exemplo de quando usar cada um.

🟡 Médios

  1. Herança:
    • Crie uma classe Animal com método emitirSom().
    • Crie classes filhas Cachorro e Gato que sobrescrevem (override) esse método.
  2. Correção de Código: O código abaixo dá erro. Por que? Corrija. 
    public class Teste {
    public void main(String[] args) {
        System.out.println("Oi");
    }
}
    (Dica: Faltou uma palavra mágica no método).

🔴 Desafio

  1. Polimorfismo e Listas:
    • Crie uma ArrayList<Animal> (da questão 3).
    • Adicione um cachorro e um gato na lista.
    • Use um for para percorrer a lista e chamar emitirSom() de cada um.
    • Explique por que o Java sabe qual som emitir em tempo de execução.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Classe Simples **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Classe Simples
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Fundamentos de Java para Android ☕**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Tipos **Resposta Comentada:** - **Fundamentação:** No contexto de **Fundamentos de Java para Android ☕**, o conceito abordado (Tipos) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Herança **Resposta Comentada:** - **Fundamentação:** No contexto de **Fundamentos de Java para Android ☕**, o conceito abordado (Herança) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Correção de Código **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Correção de Código
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Fundamentos de Java para Android ☕**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Polimorfismo e Listas **Resposta Comentada:** - **Fundamentação:** No contexto de **Fundamentos de Java para Android ☕**, o conceito abordado (Polimorfismo e Listas) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 03 - Introdução ao Kotlin 💜

🟢 Fáceis

  1. Conversão: Converta o código Java abaixo para Kotlin. 
    final String fruta = "Maçã";
int quantidade = 10;
  2. Inferência: O que acontece se eu tentar fazer isso em Kotlin? Por que? 
    var nota = 10
nota = "Dez"

🟡 Médios

  1. Null Safety: Você tem uma variável var nome: String? = null. Escreva um código que imprime o tamanho do nome SE ele não for nulo, e imprime "0" se for nulo, usando o operador Elvis (?:).
  2. Funções: Reescreva a função abaixo usando a sintaxe Single-Expression (linha única). 
    fun quadrado(x: Int): Int {
    return x * x
}

🔴 Desafio

  1. Data Classes e Cópia:
    • Crie uma data class Celular(val marca: String, val modelo: String, val preco: Double).
    • Instancie um "iPhone 14" de 5000 reais.
    • Use o método .copy() para criar um novo celular igualzinho, mas mudando apenas o modelo para "iPhone 15" e o preco para 6000.
    • Imprima os dois objetos.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conversão **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Conversão
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Introdução ao Kotlin**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Inferência **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Kotlin**, o conceito abordado (Inferência) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Null Safety **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Kotlin**, o conceito abordado (Null Safety) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Funções **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Kotlin**, o conceito abordado (Funções) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Data Classes e Cópia **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Data Classes e Cópia
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Introdução ao Kotlin**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios 04 - Estrutura App Android 🏗️

🟢 Fáceis

  1. Manifesto: Para que serve o arquivo AndroidManifest.xml? Cite duas coisas definidas nele.
  2. Recursos: Em qual pasta devemos colocar as imagens do nosso aplicativo? E os textos?

🟡 Médios

  1. Ciclo de Vida (Ordem): Coloque os métodos na ordem correta de execução quando o app é aberto pela primeira vez: onResume, onCreate, onStart.
  2. XML vs Code: Por que o Android separa o Layout (XML) da Lógica (Kotlin)? Cite uma vantagem dessa abordagem (ex: tradução, manutenção, designers).

🔴 Desafio

  1. Debug de Lifecycle: Um desenvolvedor novato colocou um código pesado (download de imagem) dentro do método onResume().
    • O que acontece com o app se o usuário ficar bloqueando e desbloqueando a tela várias vezes seguidas?
    • Qual seria o lugar (ou componente) mais adequado para fazer esse download apenas uma vez? (Pode chutar: ViewModel, onCreate, WorkManager...)

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Manifesto **Resposta Comentada:** - **Fundamentação:** No contexto de **Estrutura de um App Android ️**, o conceito abordado (Manifesto) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Recursos **Resposta Comentada:** - **Fundamentação:** No contexto de **Estrutura de um App Android ️**, o conceito abordado (Recursos) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Ciclo de Vida (Ordem) **Resposta Comentada:** - **Fundamentação:** No contexto de **Estrutura de um App Android ️**, o conceito abordado (Ciclo de Vida (Ordem)) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: XML vs Code **Resposta Comentada:** - **Fundamentação:** No contexto de **Estrutura de um App Android ️**, o conceito abordado (XML vs Code) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Debug de Lifecycle **Resposta Comentada:** - **Fundamentação:** No contexto de **Estrutura de um App Android ️**, o conceito abordado (Debug de Lifecycle) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 05 - Interface Gráfica 🎨

🟢 Fáceis

  1. Views vs ViewGroups: Em poucas palavras, qual a função de um ViewGroup? Dê um exemplo.
  2. Unidades: Por que devemos usar dp para tamanhos e sp para textos, em vez de pixels (px)?

🟡 Médios

  1. ConstraintLayout: Explique como você centralizaria um botão na tela usando ConstraintLayout (quais as "amarras" necessárias).
  2. Weight (Peso): Em um LinearLayout horizontal, se eu tiver dois botões, e quiser que o primeiro ocupe 70% da tela e o segundo 30%, como configuro o layout_weight?

🔴 Desafio

  1. Hierarquia de Views: Um erro comum de iniciantes é criar layouts muito aninhados (LinearLayout dentro de LinearLayout, dentro de outro...).
    • Por que isso é ruim para a performance do app?
    • Como o ConstraintLayout ajuda a evitar esse problema?
    • Desenhe a estrutura de árvore do layout da "Tela de Login" proposta na aula.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Views vs ViewGroups **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Views vs ViewGroups
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Interface Gráfica (UI)**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Unidades **Resposta Comentada:** - **Fundamentação:** No contexto de **Interface Gráfica (UI)**, o conceito abordado (Unidades) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: ConstraintLayout **Resposta Comentada:** - **Fundamentação:** No contexto de **Interface Gráfica (UI)**, o conceito abordado (ConstraintLayout) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Weight (Peso) **Resposta Comentada:** - **Fundamentação:** No contexto de **Interface Gráfica (UI)**, o conceito abordado (Weight (Peso)) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Hierarquia de Views **Resposta Comentada:** - **Fundamentação:** No contexto de **Interface Gráfica (UI)**, o conceito abordado (Hierarquia de Views) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 06 - Navegação 🗺️

🟢 Fáceis

  1. Conceito: O que é uma Intent no Android?
  2. Tipos: Qual a diferença entre uma Intent Explícita e uma Implícita?

🟡 Médios

  1. Passagem de Dados: Escreva um trecho de código (Kotlin) para enviar o número 42 para a Activity RespostaActivity com a chave "RESPOSTA_FIXA".
  2. Ciclo de Vida: Quando abrimos a Activity B a partir da A, o método onStop() da A é chamado? E o onDestroy()? Justifique.

🔴 Desafio

  1. Fluxo de Navegação: Você tem 3 telas: A -> B -> C.
    • Na tela C, existe um botão "Home" que deve levar para a tela A, mas limpando a tela B e C da pilha (para que o botão voltar não funcione). Qual flag de Intent você usaria ou qual a lógica para isso?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceito **Resposta Comentada:** - **Fundamentação:** No contexto de **Navegação entre Telas ️**, o conceito abordado (Conceito) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Tipos **Resposta Comentada:** - **Fundamentação:** No contexto de **Navegação entre Telas ️**, o conceito abordado (Tipos) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Passagem de Dados **Resposta Comentada:** - **Fundamentação:** No contexto de **Navegação entre Telas ️**, o conceito abordado (Passagem de Dados) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Ciclo de Vida **Resposta Comentada:** - **Fundamentação:** No contexto de **Navegação entre Telas ️**, o conceito abordado (Ciclo de Vida) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Fluxo de Navegação **Resposta Comentada:** - **Fundamentação:** No contexto de **Navegação entre Telas ️**, o conceito abordado (Fluxo de Navegação) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 07 - Arquitetura MVVM 🏗️

🟢 Fáceis

  1. Responsabilidades: No padrão MVVM, quem é responsável por decidir o que mostrar na tela? (Model, View ou ViewModel?)
  2. Ciclo de Vida: O que acontece com os dados dentro de um ViewModel quando a tela gira (rotaciona)?

🟡 Médios

  1. LiveData: Explique o conceito de "Oberver Pattern" usado no LiveData. Por que a Activity precisa "observar" os dados?
  2. Separação: Por que não devemos passar uma referência da View (ex: um TextView) para dentro do ViewModel? (Dica: pense em vazamento de memória e ciclo de vida).

🔴 Desafio

  1. Arquitetura Real: Imagine um app de Clima.

    • Model: Classe ClimaRepository que pega dados da API.
    • ViewModel: Chama o repositório e guarda val temperatura = MutableLiveData<Float>().
    • View: Mostra o texto "25°C".

    Se a internet cair no meio da requisição, quem deve tratar o erro e onde deve ficar a mensagem de erro (String) para ser exibida? No Model, ViewModel ou View?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Responsabilidades **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura Moderna (MVVM) ️**, o conceito abordado (Responsabilidades) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Ciclo de Vida **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura Moderna (MVVM) ️**, o conceito abordado (Ciclo de Vida) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: LiveData **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura Moderna (MVVM) ️**, o conceito abordado (LiveData) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Separação **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura Moderna (MVVM) ️**, o conceito abordado (Separação) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Arquitetura Real **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura Moderna (MVVM) ️**, o conceito abordado (Arquitetura Real) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 08 - Persistência de Dados 💾

🟢 Fáceis

  1. Escolha: Para salvar apenas "Som ligado/desligado", qual a opção mais adequada: SQLite, SharedPreferences ou Arquivo de Texto?
  2. Room: O que é uma @Entity no Room?

🟡 Médios

  1. Threads: Por que o Android proíbe acesso ao banco de dados na Main Thread? O que acontece se tentarmos fazer isso?
  2. DAO: O que significa a sigla DAO e qual sua função no Room?

🔴 Desafio

  1. Migração: Você lançou o app com a tabela Usuario(id, nome). Na versão 2.0, você precisa adicionar o campo idade.
    • O que acontece se você rodar o app novo em um celular que tem o banco antigo, sem configurar uma "Migration"?
    • Como o Room lida com controle de versão do banco?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Escolha **Resposta Comentada:** - **Fundamentação:** No contexto de **Persistência de Dados**, o conceito abordado (Escolha) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Room **Resposta Comentada:** - **Fundamentação:** No contexto de **Persistência de Dados**, o conceito abordado (Room) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Threads **Resposta Comentada:** - **Fundamentação:** No contexto de **Persistência de Dados**, o conceito abordado (Threads) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: DAO **Resposta Comentada:** - **Fundamentação:** No contexto de **Persistência de Dados**, o conceito abordado (DAO) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Migração **Resposta Comentada:** - **Fundamentação:** No contexto de **Persistência de Dados**, o conceito abordado (Migração) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 09 - Listas Eficientes (RecyclerView) 📋

🟢 Fáceis

  1. Conceito: Por que o RecyclerView é mais eficiente que um ListView antigo ou um LinearLayout dentro de um ScrollView?
  2. Componentes: Qual a função do LayoutManager no RecyclerView?

🟡 Médios

  1. Adapter: O método onBindViewHolder é chamado muitas vezes. O que acontece se você colocar uma lógica pesada (ex: baixar uma imagem da internet de forma síncrona) dentro dele?
  2. ViewHolder: Para que serve a classe ViewHolder? Por que não devemos fazer findViewById direto no onBindViewHolder?

🔴 Desafio

  1. Múltiplos Tipos de View: Imagine um chat (WhatsApp). Mensagens enviadas ficam na direita (verde), recebidas na esquerda (branco).
    • Como você implementaria isso no RecyclerView? (Dica: pesquise sobre getItemViewType).

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceito **Resposta Comentada:** - **Fundamentação:** No contexto de **Listas Eficientes (RecyclerView)**, o conceito abordado (Conceito) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Componentes **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Componentes
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Listas Eficientes (RecyclerView)**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Adapter **Resposta Comentada:** - **Fundamentação:** No contexto de **Listas Eficientes (RecyclerView)**, o conceito abordado (Adapter) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: ViewHolder **Resposta Comentada:** - **Fundamentação:** No contexto de **Listas Eficientes (RecyclerView)**, o conceito abordado (ViewHolder) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Múltiplos Tipos de View **Resposta Comentada:** - **Fundamentação:** No contexto de **Listas Eficientes (RecyclerView)**, o conceito abordado (Múltiplos Tipos de View) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 10 - Consumo de API REST 🌍

🟢 Fáceis

  1. Verbos HTTP: Qual verbo HTTP usamos para obter dados e qual usamos para enviar dados novos?
  2. Permissão: Qual permissão deve ser adicionada no AndroidManifest.xml para que o Retrofit funcione?

🟡 Médios

  1. Conversão: O que acontece se o campo no JSON for "user_name" (snake_case) e na sua data class for val userName: String (camelCase)? Como o Retrofit/Gson sabe mapear isso? (Pesquise sobre anotação @SerializedName).
  2. Threading: O Retrofit (com Coroutines) precisa que você use withContext(Dispatchers.IO) manualmente na chamada, ou ele já faz isso por baixo dos panos?
  3. Autenticação: Se uma API exige um token JWT no cabeçalho Authorization, como você configuraria o Retrofit para enviar esse token em todas as requisições sem repetir código? (Pesquise sobre OkHttp Interceptors).

🔴 Desafio

  1. Status Code: Se a API retornar erro 401 (Não Autorizado) ou 500 (Erro no Servidor), como você capturaria isso no bloco try/catch do ViewModel para exibir uma mensagem adequada ao usuário?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Verbos HTTP **Resposta Comentada:** - **Fundamentação:** No contexto de **Consumindo API REST (Retrofit)**, o conceito abordado (Verbos HTTP) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Permissão **Resposta Comentada:** - **Fundamentação:** No contexto de **Consumindo API REST (Retrofit)**, o conceito abordado (Permissão) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Conversão **Resposta Comentada:** - **Fundamentação:** No contexto de **Consumindo API REST (Retrofit)**, o conceito abordado (Conversão) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Threading **Resposta Comentada:** - **Fundamentação:** No contexto de **Consumindo API REST (Retrofit)**, o conceito abordado (Threading) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Autenticação **Resposta Comentada:** - **Fundamentação:** No contexto de **Consumindo API REST (Retrofit)**, o conceito abordado (Autenticação) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 6: Status Code **Resposta Comentada:** - **Fundamentação:** No contexto de **Consumindo API REST (Retrofit)**, o conceito abordado (Status Code) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 11 - Threads e Async 🧵

🟢 Fáceis

  1. ANR: O que significa a sigla ANR e o que causa esse erro?
  2. Main Thread: O que deve e o que NÃO deve rodar na Main Thread?

🟡 Médios

  1. Dispatchers: Qual Dispatcher você usaria para: a) Ordenar uma lista de 10.000 nomes (CPU intensive). b) Salvar um arquivo no disco (IO). c) Atualizar um TextView (UI).
  2. Suspensão: O que acontece com a Thread Principal quando ela encontra uma função suspend que chama delay(5000)? Ela trava por 5 segundos ou continua livre para desenhar a tela?
  3. Sockets vs REST: Explique a principal diferença entre uma comunicação REST e uma comunicação via Sockets (TCP). Quando você escolheria usar Sockets em vez de REST em um aplicativo Android?

🔴 Desafio

  1. Race Condition (Condição de Corrida): Duas coroutines tentam alterar a mesma variável contador = 0 ao mesmo tempo. Ambas leem 0, somam 1 e salvam 1. O resultado final é 1, mas deveria ser 2.
    • Como resolver isso em Kotlin (Mutex, Atomic, ou Single Thread)?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: ANR **Resposta Comentada:** - **Fundamentação:** No contexto de **Threads e Assincronismo (Coroutines)**, o conceito abordado (ANR) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Main Thread **Resposta Comentada:** - **Fundamentação:** No contexto de **Threads e Assincronismo (Coroutines)**, o conceito abordado (Main Thread) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Dispatchers **Resposta Comentada:** - **Fundamentação:** No contexto de **Threads e Assincronismo (Coroutines)**, o conceito abordado (Dispatchers) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Suspensão **Resposta Comentada:** - **Fundamentação:** No contexto de **Threads e Assincronismo (Coroutines)**, o conceito abordado (Suspensão) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Sockets vs REST **Resposta Comentada:** - **Fundamentação:** No contexto de **Threads e Assincronismo (Coroutines)**, o conceito abordado (Sockets vs REST) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 6: Race Condition (Condição de Corrida) **Resposta Comentada:** - **Fundamentação:** No contexto de **Threads e Assincronismo (Coroutines)**, o conceito abordado (Race Condition (Condição de Corrida)) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 12 - UX/UI e Material Design 🎨

🟢 Fáceis

  1. Princípio Key: Qual a principal diferença visual (metafórica) entre o Material Design (Google) e o Flat Design original? (Dica: pense em Eixo Z).
  2. Cores: O que é o "Dynamic Color" (Material You)?

🟡 Médios

  1. Acessibilidade: Por que não devemos confiar apena na COR para indicar estado (ex: erro ser apenas vermelho)? O que mais devemos adicionar?
  2. Dark Mode: Ao criar um ícone preto (#000000) para um botão, o que acontece quando o usuário ativa o Modo Escuro no celular? Como corrigir?

🔴 Desafio

  1. Densidade de Informação: Você tem uma lista de 50 itens para exibir.

    • Opção A: Lista densa (apenas texto, linhas finas).
    • Opção B: Cards grandes com margens largas e sombras.

    Em qual situação você usaria a Opção A e em qual usaria a Opção B? (Considere um app de utilitário vs um app de mídia/notícias).

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Princípio Key **Resposta Comentada:** - **Fundamentação:** No contexto de **UX/UI e Material Design 3**, o conceito abordado (Princípio Key) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Cores **Resposta Comentada:** - **Fundamentação:** No contexto de **UX/UI e Material Design 3**, o conceito abordado (Cores) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Acessibilidade **Resposta Comentada:** - **Fundamentação:** No contexto de **UX/UI e Material Design 3**, o conceito abordado (Acessibilidade) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Dark Mode **Resposta Comentada:** - **Fundamentação:** No contexto de **UX/UI e Material Design 3**, o conceito abordado (Dark Mode) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Densidade de Informação **Resposta Comentada:** - **Fundamentação:** No contexto de **UX/UI e Material Design 3**, o conceito abordado (Densidade de Informação) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 13 - Sensores e Hardware 📸

🟢 Fáceis

  1. Permissões: Qual a diferença entre uma permissão "Normal" e uma "Perigosa" no Android?
  2. GPS: Qual biblioteca do Google Play Services é recomendada para obter a localização?

🟡 Médios

  1. SensorManager: Para que serve o método registerListener? O que acontece se esquecermos de chamar o unregisterListener no onStop() ou onDestroy() da Activity?
  2. CameraX: Cite os 3 principais casos de uso (Use Cases) da biblioteca CameraX e para que servem.
  3. Bluetooth e SMS: a) Qual a diferença entre Bluetooth Classic e Bluetooth Low Energy (BLE) em termos de consumo de bateria e casos de uso? b) Quais as classes principais no Android para enviar um SMS e para gerenciar a conexão Bluetooth?

🔴 Desafio

  1. Geocoding e Mapas: Se você tem a latitude e longitude de um usuário, como você faria para descobrir o nome da rua e o número (endereço completo)? Qual o nome do processo e da classe que faz isso no Android?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Permissões **Resposta Comentada:** - **Fundamentação:** No contexto de **Sensores e Hardware �**, o conceito abordado (Permissões) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: GPS **Resposta Comentada:** - **Fundamentação:** No contexto de **Sensores e Hardware �**, o conceito abordado (GPS) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: SensorManager **Resposta Comentada:** - **Fundamentação:** No contexto de **Sensores e Hardware �**, o conceito abordado (SensorManager) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: CameraX **Resposta Comentada:** - **Fundamentação:** No contexto de **Sensores e Hardware �**, o conceito abordado (CameraX) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Bluetooth e SMS **Resposta Comentada:** - **Fundamentação:** No contexto de **Sensores e Hardware �**, o conceito abordado (Bluetooth e SMS) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 6: Geocoding e Mapas **Resposta Comentada:** - **Fundamentação:** No contexto de **Sensores e Hardware �**, o conceito abordado (Geocoding e Mapas) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 14 - Testes e Qualidade 🧪

🟢 Fáceis

  1. Logcat: Por que usar Log.d() em vez de println() no Android?
  2. Breakpoint: O que acontece com a execução do código quando ele atinge um breakpoint no modo Debug?

🟡 Médios

  1. Pirâmide de Testes: Por que devemos ter mais Testes Unitários do que Testes de UI? Cite 2 razões.
  2. Espresso: Escreva uma linha de código usando Espresso para verificar se um botão com o ID btn_salvar está visível na tela.

🔴 Desafio

  1. TDD (Test Driven Development): Explique brevemente o ciclo "Red-Green-Refactor". Como essa prática ajuda a evitar bugs em aplicativos mobile que crescem muito rápido?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Logcat **Resposta Comentada:** - **Fundamentação:** No contexto de **Testes, Qualidade e Debugging**, o conceito abordado (Logcat) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Breakpoint **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Breakpoint
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Testes, Qualidade e Debugging**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Pirâmide de Testes **Resposta Comentada:** - **Fundamentação:** No contexto de **Testes, Qualidade e Debugging**, o conceito abordado (Pirâmide de Testes) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Espresso **Resposta Comentada:** - **Fundamentação:** No contexto de **Testes, Qualidade e Debugging**, o conceito abordado (Espresso) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: TDD (Test Driven Development) **Resposta Comentada:** - **Fundamentação:** No contexto de **Testes, Qualidade e Debugging**, o conceito abordado (TDD (Test Driven Development)) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 15 - Publicação 🚀

🟢 Fáceis

  1. Formato: Qual o formato de arquivo obrigatório para enviar novos apps para a Google Play Store? (APK ou AAB?)
  2. Custo: Qual o valor da taxa para criar uma conta de desenvolvedor no Google Play? Ela é anual ou única?

🟡 Médios

  1. Keystore: Por que o arquivo de chave (.jks) é tão crítico? O que acontece se você perdê-lo após publicar a versão 1.0 do seu app?
  2. ProGuard/R8: Explique o que é a ofuscação de código e por que ela é importante para a segurança do app.

🔴 Desafio

  1. Otimização: Como o Google Play usa o Android App Bundle (AAB) para reduzir o tamanho do download para o usuário final em comparação ao APK tradicional?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Formato **Resposta Comentada:** - **Fundamentação:** No contexto de **Publicação e Google Play Store**, o conceito abordado (Formato) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Custo **Resposta Comentada:** - **Fundamentação:** No contexto de **Publicação e Google Play Store**, o conceito abordado (Custo) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Keystore **Resposta Comentada:** - **Fundamentação:** No contexto de **Publicação e Google Play Store**, o conceito abordado (Keystore) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: ProGuard/R8 **Resposta Comentada:** - **Fundamentação:** No contexto de **Publicação e Google Play Store**, o conceito abordado (ProGuard/R8) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Otimização **Resposta Comentada:** - **Fundamentação:** No contexto de **Publicação e Google Play Store**, o conceito abordado (Otimização) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 16 - Planejamento do Projeto Final 🎓

🟢 Fáceis

  1. Tema: Escolha o tema do seu projeto final. Será um dos sugeridos (Finanças, Clima, Livros, Fitness) ou um tema autoral?
  2. Escopo: Liste as 2 principais telas que seu app terá.

🟡 Médios

  1. Arquitetura: Desenhe (ou descreva) como será o seu ViewModel. Quais dados (LiveData) ele vai expor para a View?
  2. Dados: Seu app usará dados da Internet (Retrofit) ou salvará localmente (Room)? Justifique sua escolha baseada na utilidade do app.

🔴 Desafio

  1. Checklist de Qualidade: Crie um checklist com 5 itens de UX/UI que você vai garantir no seu projeto final (ex: Modo Escuro, Feedback de cliques, Tratamento de erro de rede, etc).

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Tema **Resposta Comentada:** - **Fundamentação:** No contexto de **Projeto Final e Conclusão**, o conceito abordado (Tema) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Escopo **Resposta Comentada:** - **Fundamentação:** No contexto de **Projeto Final e Conclusão**, o conceito abordado (Escopo) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Arquitetura **Resposta Comentada:** - **Fundamentação:** No contexto de **Projeto Final e Conclusão**, o conceito abordado (Arquitetura) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Dados **Resposta Comentada:** - **Fundamentação:** No contexto de **Projeto Final e Conclusão**, o conceito abordado (Dados) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Checklist de Qualidade **Resposta Comentada:** - **Fundamentação:** No contexto de **Projeto Final e Conclusão**, o conceito abordado (Checklist de Qualidade) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Projetos

🚀 Projetos do Curso

Lista completa das 20 unidades de projetos organizadas em 5 módulos didáticos.

Projeto 01 - Meu Primeiro App 📱

Objetivo: Validar a instalação do ambiente e entender a estrutura básica.

O Desafio

  1. Abra o Android Studio e crie um novo projeto "Empty Views Activity".
  2. Escolha o nome "MeuPrimeiroApp" e linguagem Kotlin.
  3. No layout activity_main.xml, mude o texto "Hello World" para "Olá, Desenvolvedor Mobile! 🚀".
  4. Mude a cor do texto para azul.
  5. Rode o app no Emulador ou Celular físico.

O que entregar?

  • Print da tela do app rodando.
  • O arquivo AndroidManifest.xml para conferência.

Projeto 02 - Calculadora de IMC (Java) ☕

Objetivo: Praticar lógica de programação e tipos de dados usando Java no Android.

O Desafio

  1. Crie um layout simples com dois EditText (Peso e Altura) e um Button (Calcular).
  2. No código Java, recupere os valores digitados.
  3. Calcule o IMC (Peso / Altura²).
  4. Exiba o resultado em um TextView e use um Toast para mostrar a classificação (Ex: "Peso Ideal", "Sobrepeso").

Dica

Lembre-se de converter o texto do EditText para Double antes de calcular! double peso = Double.parseDouble(editPeso.getText().toString());

Projeto 03 - Perfil de Desenvolvedor (Kotlin) ⚡

Objetivo: Praticar a sintaxe concisa do Kotlin e Data Classes.

O Desafio

  1. Crie uma data class Dev(val nome: String, val stack: String, val nivel: String).
  2. Na Activity, crie uma instância dessa classe.
  3. Use String Templates para exibir uma mensagem formatada em um TextView: "Olá, meu nome é ${dev.nome}, sou dev ${dev.stack} e meu nível é ${dev.nivel}."
  4. Implemente um botão que, ao ser clicado, altera o nível do dev de "Estagiário" para "Júnior".

Dica

Use val para a instância da classe, mas lembre-se que se precisar mudar uma propriedade interna, a classe original deve permitir ou você deve usar o método .copy().

Projeto 04 - Tela de Login Elegante 🧱

Objetivo: Dominar a estrutura de recursos (res/) e ViewBinding.

O Desafio

  1. Habilite o ViewBinding no seu build.gradle.
  2. Crie uma tela de login com:
    • Logotipo (Imagem em res/drawable).
    • Campo de E-mail e Senha (usando strings.xml).
    • Botão "Entrar".
  3. No código, use o Binding para capturar o clique do botão e validar se os campos não estão vazios.
  4. Se estiverem vazios, exiba um erro no EditText (error = "Campo obrigatório").

O que avaliar?

  • Organização do arquivo strings.xml.
  • Uso correto do ViewBinding (sem findViewById).

Projeto 05 - Layouts e Unidades 🎨

Objetivo: Praticar a construção de interfaces complexas com diferentes ViewGroups.

O Desafio

Crie uma tela de "Detalhes de Produto" (tipo e-commerce) contendo: 1. LinearLayout (Vertical) para a estrutura principal. 2. ImageView no topo para a foto do produto. 3. ConstraintLayout para a área de informações (nome do produto à esquerda, preço à direita, ambos alinhados). 4. Botão de "Comprar" ocupando a largura total na parte inferior. 5. Use dp para margens (mínimo 16dp) e sp para o título do produto.

Dica

Teste o seu layout em diferentes tamanhos de tela no emulador ou no Preview do Android Studio.

Quizzes

🧠 Quizzes de Fixação

Lista completa das 20 unidades de quizzes organizadas em 5 módulos didáticos.

🧠 Quiz 01 – Introdução ao Desenvolvimento Mobile 📱

  1. Qual é o conceito fundamental e objetivo principal de Introdução ao Desenvolvimento Mobile 📱?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Introdução ao Desenvolvimento Mobile 📱?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Introdução ao Desenvolvimento Mobile 📱, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Introdução ao Desenvolvimento Mobile 📱?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Introdução ao Desenvolvimento Mobile 📱 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Introdução ao Desenvolvimento Mobile 📱, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Introdução ao Desenvolvimento Mobile 📱?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Introdução ao Desenvolvimento Mobile 📱 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Introdução ao Desenvolvimento Mobile 📱 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Introdução ao Desenvolvimento Mobile 📱 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 02 – Fundamentos de Java para Android ☕

  1. Qual é o conceito fundamental e objetivo principal de Fundamentos de Java para Android ☕?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Fundamentos de Java para Android ☕?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Fundamentos de Java para Android ☕, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Fundamentos de Java para Android ☕?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Fundamentos de Java para Android ☕ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Fundamentos de Java para Android ☕, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Fundamentos de Java para Android ☕?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Fundamentos de Java para Android ☕ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Fundamentos de Java para Android ☕ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Fundamentos de Java para Android ☕ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 03 – Introdução ao Kotlin 💜

  1. Qual é o conceito fundamental e objetivo principal de Introdução ao Kotlin 💜?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Introdução ao Kotlin 💜?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Introdução ao Kotlin 💜, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Introdução ao Kotlin 💜?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Introdução ao Kotlin 💜 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Introdução ao Kotlin 💜, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Introdução ao Kotlin 💜?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Introdução ao Kotlin 💜 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Introdução ao Kotlin 💜 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Introdução ao Kotlin 💜 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 04 – Estrutura de um App Android 🏗️

  1. Qual é o conceito fundamental e objetivo principal de Estrutura de um App Android 🏗️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Estrutura de um App Android 🏗️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Estrutura de um App Android 🏗️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Estrutura de um App Android 🏗️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Estrutura de um App Android 🏗️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Estrutura de um App Android 🏗️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Estrutura de um App Android 🏗️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Estrutura de um App Android 🏗️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Estrutura de um App Android 🏗️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Estrutura de um App Android 🏗️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 05 – Interface Gráfica (UI) 🎨

  1. Qual é o conceito fundamental e objetivo principal de Interface Gráfica (UI) 🎨?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Interface Gráfica (UI) 🎨?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Interface Gráfica (UI) 🎨, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Interface Gráfica (UI) 🎨?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Interface Gráfica (UI) 🎨 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Interface Gráfica (UI) 🎨, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Interface Gráfica (UI) 🎨?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Interface Gráfica (UI) 🎨 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Interface Gráfica (UI) 🎨 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Interface Gráfica (UI) 🎨 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 06 – Navegação entre Telas 🗺️

  1. Qual é o conceito fundamental e objetivo principal de Navegação entre Telas 🗺️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Navegação entre Telas 🗺️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Navegação entre Telas 🗺️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Navegação entre Telas 🗺️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Navegação entre Telas 🗺️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Navegação entre Telas 🗺️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Navegação entre Telas 🗺️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Navegação entre Telas 🗺️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Navegação entre Telas 🗺️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Navegação entre Telas 🗺️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 07 – Arquitetura Moderna (MVVM) 🏗️

  1. Qual é o conceito fundamental e objetivo principal de Arquitetura Moderna (MVVM) 🏗️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Arquitetura Moderna (MVVM) 🏗️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Arquitetura Moderna (MVVM) 🏗️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Arquitetura Moderna (MVVM) 🏗️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Arquitetura Moderna (MVVM) 🏗️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Arquitetura Moderna (MVVM) 🏗️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Arquitetura Moderna (MVVM) 🏗️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Arquitetura Moderna (MVVM) 🏗️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Arquitetura Moderna (MVVM) 🏗️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Arquitetura Moderna (MVVM) 🏗️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 08 – Persistência de Dados 💾

  1. Qual é o conceito fundamental e objetivo principal de Persistência de Dados 💾?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Persistência de Dados 💾?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Persistência de Dados 💾, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Persistência de Dados 💾?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Persistência de Dados 💾 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Persistência de Dados 💾, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Persistência de Dados 💾?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Persistência de Dados 💾 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Persistência de Dados 💾 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Persistência de Dados 💾 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 09 – Listas Eficientes (RecyclerView) 📋

  1. Qual é o conceito fundamental e objetivo principal de Listas Eficientes (RecyclerView) 📋?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Listas Eficientes (RecyclerView) 📋?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Listas Eficientes (RecyclerView) 📋, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Listas Eficientes (RecyclerView) 📋?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Listas Eficientes (RecyclerView) 📋 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Listas Eficientes (RecyclerView) 📋, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Listas Eficientes (RecyclerView) 📋?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Listas Eficientes (RecyclerView) 📋 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Listas Eficientes (RecyclerView) 📋 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Listas Eficientes (RecyclerView) 📋 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 10 – Consumindo API REST (Retrofit) 🌍

  1. Qual é o conceito fundamental e objetivo principal de Consumindo API REST (Retrofit) 🌍?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Consumindo API REST (Retrofit) 🌍?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Consumindo API REST (Retrofit) 🌍, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Consumindo API REST (Retrofit) 🌍?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Consumindo API REST (Retrofit) 🌍 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Consumindo API REST (Retrofit) 🌍, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Consumindo API REST (Retrofit) 🌍?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Consumindo API REST (Retrofit) 🌍 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Consumindo API REST (Retrofit) 🌍 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Consumindo API REST (Retrofit) 🌍 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 11 – Threads e Assincronismo (Coroutines) 🧵

  1. Qual é o conceito fundamental e objetivo principal de Threads e Assincronismo (Coroutines) 🧵?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Threads e Assincronismo (Coroutines) 🧵?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Threads e Assincronismo (Coroutines) 🧵, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Threads e Assincronismo (Coroutines) 🧵?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Threads e Assincronismo (Coroutines) 🧵 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Threads e Assincronismo (Coroutines) 🧵, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Threads e Assincronismo (Coroutines) 🧵?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Threads e Assincronismo (Coroutines) 🧵 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Threads e Assincronismo (Coroutines) 🧵 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Threads e Assincronismo (Coroutines) 🧵 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 12 – UX/UI e Material Design 3 🎨

  1. Qual é o conceito fundamental e objetivo principal de UX/UI e Material Design 3 🎨?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de UX/UI e Material Design 3 🎨?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em UX/UI e Material Design 3 🎨, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em UX/UI e Material Design 3 🎨?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de UX/UI e Material Design 3 🎨 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em UX/UI e Material Design 3 🎨, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em UX/UI e Material Design 3 🎨?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a UX/UI e Material Design 3 🎨 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar UX/UI e Material Design 3 🎨 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a UX/UI e Material Design 3 🎨 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 13 – Sensores e Hardware �

  1. Qual é o conceito fundamental e objetivo principal de Sensores e Hardware �?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Sensores e Hardware �?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Sensores e Hardware �, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Sensores e Hardware �?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Sensores e Hardware � atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Sensores e Hardware �, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Sensores e Hardware �?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Sensores e Hardware � estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Sensores e Hardware � com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Sensores e Hardware � deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 14 – Testes, Qualidade e Debugging 🐞

  1. Qual é o conceito fundamental e objetivo principal de Testes, Qualidade e Debugging 🐞?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Testes, Qualidade e Debugging 🐞?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Testes, Qualidade e Debugging 🐞, Qualidade e Debugging 🐞, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Testes, Qualidade e Debugging 🐞?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Testes, Qualidade e Debugging 🐞 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Testes, Qualidade e Debugging 🐞, Qualidade e Debugging 🐞, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Testes, Qualidade e Debugging 🐞?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Testes, Qualidade e Debugging 🐞 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Testes, Qualidade e Debugging 🐞 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Testes, Qualidade e Debugging 🐞 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 15 – Publicação e Google Play Store 🚀

  1. Qual é o conceito fundamental e objetivo principal de Publicação e Google Play Store 🚀?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Publicação e Google Play Store 🚀?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Publicação e Google Play Store 🚀, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Publicação e Google Play Store 🚀?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Publicação e Google Play Store 🚀 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Publicação e Google Play Store 🚀, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Publicação e Google Play Store 🚀?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Publicação e Google Play Store 🚀 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Publicação e Google Play Store 🚀 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Publicação e Google Play Store 🚀 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 16 – Projeto Final e Conclusão 🎓

  1. Qual é o conceito fundamental e objetivo principal de Projeto Final e Conclusão 🎓?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Projeto Final e Conclusão 🎓?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Projeto Final e Conclusão 🎓, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Projeto Final e Conclusão 🎓?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Projeto Final e Conclusão 🎓 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Projeto Final e Conclusão 🎓, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Projeto Final e Conclusão 🎓?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Projeto Final e Conclusão 🎓 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Projeto Final e Conclusão 🎓 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Projeto Final e Conclusão 🎓 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 17 – SwiftUI Avançado e Animações Customizadas 🚀

  1. Qual o propósito principal de SwiftUI Avançado e Animações Customizadas 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de SwiftUI Avançado e Animações Customizadas 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de SwiftUI Avançado e Animações Customizadas 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar SwiftUI Avançado e Animações Customizadas 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de SwiftUI Avançado e Animações Customizadas 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em SwiftUI Avançado e Animações Customizadas 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de SwiftUI Avançado e Animações Customizadas 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a SwiftUI Avançado e Animações Customizadas 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de SwiftUI Avançado e Animações Customizadas 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a SwiftUI Avançado e Animações Customizadas 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 18 – Arquitetura MVVM/VIPER com Concorrência Swift 🚀

  1. Qual o propósito principal de Arquitetura MVVM/VIPER com Concorrência Swift 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Arquitetura MVVM/VIPER com Concorrência Swift 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Arquitetura MVVM/VIPER com Concorrência Swift 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Arquitetura MVVM/VIPER com Concorrência Swift 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Arquitetura MVVM/VIPER com Concorrência Swift 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Arquitetura MVVM/VIPER com Concorrência Swift 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Arquitetura MVVM/VIPER com Concorrência Swift 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Arquitetura MVVM/VIPER com Concorrência Swift 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Arquitetura MVVM/VIPER com Concorrência Swift 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Arquitetura MVVM/VIPER com Concorrência Swift 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 19 – Persistência Local com SwiftData e Testes Unitários 🚀

  1. Qual o propósito principal de Persistência Local com SwiftData e Testes Unitários 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Persistência Local com SwiftData e Testes Unitários 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Persistência Local com SwiftData e Testes Unitários 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Persistência Local com SwiftData e Testes Unitários 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Persistência Local com SwiftData e Testes Unitários 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Persistência Local com SwiftData e Testes Unitários 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Persistência Local com SwiftData e Testes Unitários 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Persistência Local com SwiftData e Testes Unitários 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Persistência Local com SwiftData e Testes Unitários 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Persistência Local com SwiftData e Testes Unitários 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 20 – Projeto Capstone: App iOS Nativo Completo Autônomo 🚀

  1. Qual o propósito principal de Projeto Capstone: App iOS Nativo Completo Autônomo 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Projeto Capstone: App iOS Nativo Completo Autônomo 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Projeto Capstone: App iOS Nativo Completo Autônomo 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Projeto Capstone: App iOS Nativo Completo Autônomo 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Projeto Capstone: App iOS Nativo Completo Autônomo 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Projeto Capstone: App iOS Nativo Completo Autônomo 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Projeto Capstone: App iOS Nativo Completo Autônomo 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Projeto Capstone: App iOS Nativo Completo Autônomo 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Projeto Capstone: App iOS Nativo Completo Autônomo 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Projeto Capstone: App iOS Nativo Completo Autônomo 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

Slides

Configuração

Ambientes de Desenvolvimento 🛠️

Guias para configurar seu computador para o desenvolvimento mobile e entender o ecossistema de computação.

Setup 01: Android Studio 🤖

O Android Studio é a IDE oficial para o desenvolvimento Android.

1. Requisitos de Sistema

  • RAM: Mínimo 8GB (Sugerido 16GB+).
  • Espaço: Mínimo 10GB para IDE + SDKs.
  • Processador: Intel Core i5 ou equivalente.

2. Instalação

  1. Acesse o site oficial: developer.android.com/studio.
  2. Baixe a versão mais recente para o seu Sistema Operacional.
  3. Execute o instalador e escolha a opção "Standard" na configuração inicial.

3. Configurando o SDK

  • Após a instalação, vá em Settings > Languages & Frameworks > Android SDK.
  • Certifique-se de que a versão mais recente do Android (estável) esteja instalada.
  • Na aba SDK Tools, instale o "Android Emulator" e o "Intel x86 Emulator Accelerator (HAXM)" se estiver no Windows com Intel.

4. Criando um Emulador (AVD)

  1. Abra o Device Manager.
  2. Clique em Create Device.
  3. Escolha um dispositivo (ex: Pixel 7).
  4. Selecione uma imagem de sistema (ex: Level 34 - Android 14).
  5. Finalize e clique no "Play" para iniciar o celular virtual.

5. Solução de Problemas ⚠️

  • VT-x is disabled: Você precisa habilitar a virtualização na BIOS do seu computador.
  • Studio muito lento: Adicione a pasta do projeto e as pastas do Android SDK nas exclusões do seu Antivírus.

Setup 02: Xcode (iOS Foundation) 🍎

O Xcode é a ferramenta necessária para compilar e testar apps iOS.

Important

O Xcode requer um computador Mac (macOS).

1. Instalação

  1. Abra a App Store no seu Mac.
  2. Pesquise por Xcode.
  3. Clique em Obter/Instalar.
  4. Após o download, abra o Xcode para carregar os componentes adicionais do macOS.

2. Configurando Simuladores

  1. Vá em Settings > Platforms.
  2. Verifique se o componente "iOS" está baixado.
  3. Se não estiver, clique em "GET" para baixar a versão mais estável.

3. Comandos de Linha (CLI)

Para que ferramentas de automação funcionem, você precisa instalar os Command Line Tools: 

xcode-select --install

4. Opcional: CocoaPods

Muitos projetos iOS antigos ainda usam CocoaPods para dependências: 

sudo gem install cocoapods

5. Solução de Problemas ⚠️

  • Espaço em Disco: O Xcode é muito grande. Garanta pelo menos 40GB de espaço livre para ele e os simuladores.
  • Build Lento: Use simuladores de modelos mais simples (ex: iPhone SE) para poupar memória RAM se necessário.

Setup 03: Ferramentas de Apoio 🛠️

Além da IDE, você precisará de ferramentas para gerenciar código e testar dados.

1. Git e GitHub

Essencial para versionamento. * Download: git-scm.com. * Configuração Inicial: 

git config --global user.name "Seu Nome"
git config --global user.email "seu@email.com"

2. Postman ou Insomnia

Para testar as APIs REST antes de escrever código Kotlin/Swift. * Postman: postman.com. * Insomnia: insomnia.rest.

3. Vysor (Opcional)

Para espelhar a tela do seu celular real no computador (via cabo USB). * Acesso: vysor.io.

4. ADB (Android Debug Bridge)

Já vem com o Android Studio, mas é útil no PATH do sistema. * Permite instalar APKs via terminal: adb install app.apk. * Permite ver logs detalhados: adb logcat.

5. Flipper (Meta)

Uma ferramenta avançada para debugar bancos de dados SQLite e chamadas de rede direto na interface visual. * Acesso: fbflipper.com.

Aula: Java e JDK ☕

O Coração do Ecossistema Android

O Java Development Kit (JDK) é o kit essencial para compilar e rodar aplicativos Java e a base para o desenvolvimento Kotlin.

1. JDK (Java Development Kit) 🏗️

O JDK fornece as ferramentas e bibliotecas necessárias para transformar seu código fonte em bytecode.

Fluxo de Desenvolvimento 📊

graph LR
    A[Código .java] --> B[Compilador javac]
    B --> C[Bytecode .class]
    C --> D[JVM - Qualquer OS]
  1. Baixe o JDK 17 LTS (ou 21 LTS) no site da Oracle ou Adoptium.
  2. Instale e configure a variável de ambiente JAVA_HOME.

Conceito: Write Once, Run Anywhere

A grande vantagem do Java é a Máquina Virtual (JVM). Você escreve o código uma vez e ele roda em qualquer hardware que tenha uma JVM instalada.

2. Na Prática: Verificando o Ambiente 💻

java -version openjdk version "17.0.x" 202x-xx-xx javac -version javac 17.0.x 🚀 Java configurado com sucesso!

3. IDEs: IntelliJ vs. VS Code 💻

  • IntelliJ IDEA: A melhor experiência para Java/Kotlin (versão Community é gratuita).
  • VS Code: Leve e rápido, excelente para acadêmicos e projetos menores.

Dica: JAVA_HOME

Muitas ferramentas (como o Android Studio) precisam que o JAVA_HOME esteja apontando para a pasta raiz do seu JDK instalado.

📝 Exercícios Progressivos

  1. Nível 1: Qual a diferença entre o JRE (Java Runtime Environment) e o JDK?
  2. Nível 2: Por que é importante configurar a variável de ambiente JAVA_HOME?
  3. Nível 3: Explique como o conceito de Bytecode ajuda na portabilidade de aplicativos entre diferentes sistemas operacionais.

🚀 Mini-Projeto: OlaMundo Mobile

Objetivo: Compilar e rodar seu primeiro programa Java via terminal.

  • Tarefa 1: Criar um arquivo OlaMundo.java.
  • Tarefa 2: Compilar usando javac OlaMundo.java.
  • Tarefa 3: Rodar usando java OlaMundo e observar a saída.

Ir para próxima aula: Do Silício ao Software

Aula: Do Silício ao Software 🖥️

O Ecossistema da Computação Moderna

Esta aula explora a transição entre o hardware (processadores e arquiteturas) e o software (sistemas operacionais e plataformas).

1. O Alicerce: CISC vs. RISC 🏗️

Todo software é reduzido a um ISA (Instruction Set Architecture). Existem duas filosofias principais:

  • CISC (Complex Instruction Set Computer): Focada em executar tarefas complexas com poucas linhas. Ex: Intel/AMD (x86).
  • RISC (Reduced Instruction Set Computer): Usa instruções simples e ultra-rápidas. Ex: ARM (Apple M-series, Snapdragon).

Comparativo de Fluxo 📊

graph LR
    A[Código Top-Level] --> B{Compilador}
    B --> C[ISA CISC: Instruções Complexas]
    B --> D[ISA RISC: Instruções Simples]
    C --> E[Hardware Tradicional]
    D --> F[Hardware Mobile/Eficiente]

2. Abstração e Camadas de Software 🧠

O Sistema Operacional (SO) serve como o tradutor entre seu código e o silício.

Conceito: Abstração de Hardware

A abstração permite que você escreva print("Hello") sem se preocupar se o processador usa x86 ou ARM. O SO e o compilador cuidam da tradução para os binários específicos.

Sistema Operacional Arquitetura Principal Desafio do Desenvolvedor
Windows x86_64 / ARM64 Compatibilidade de drivers e emulação.
macOS / iOS ARM64 (Apple Silicon) Otimização para memória unificada.
Android ARM64 Lidar com a fragmentação de hardware.

Dica de Performance

Sempre prefira binários nativos. Rodar um app x86 em um Mac ARM via Rosetta 2 funciona, mas consome mais bateria e CPU.

3. Na Prática: Compilação Cruzada 💻

Quando desenvolvemos mobile, estamos quase sempre fazendo Cross-Compilation: escrevemos no PC (x86) para rodar no celular (ARM).

rustup target add aarch64-apple-ios cargo build --target aarch64-apple-ios ✅ Build concluído para arquitetura ARM64!

4. Sistemas Embarcados e IoT 🔌

Aqui o software "toca" o metal de forma direta.

  • Arduino: 8 bits, extremamente simples.
  • ESP32: O rei da IoT com Wi-Fi/Bluetooth e dual-core RISC.
  • Raspberry Pi: Um computador ARM completo rodando Linux.

Atenção: Limites de Memória

Em sistemas embarcados, você não tem GBs de RAM. Cada byte conta! O uso de linguagens como C ou Rust é essencial.

📝 Exercícios Progressivos

  1. Nível 1: Explique a principal diferença entre um processador que equipa um Desktop (Intel) e um que equipa um Smartphone (Snapdragon).
  2. Nível 2: Por que a Apple conseguiu aumentar drasticamente a duração da bateria ao mudar de Intel para Apple Silicon?
  3. Nível 3: Pesquise o que é o "Instruction Set" RISC-V e por que ele é considerado o futuro do hardware open-source.

🚀 Mini-Projeto: Dashboard de Arquitetura

Objetivo: Criar um script (Python ou Node) que detecte as especificações do sistema host.

  • Tarefa 1: Identificar o nome do SO e a arquitetura da CPU (x86_64 ou arm64).
  • Tarefa 2: Listar a quantidade de núcleos físicos vs lógicos.
  • Tarefa 3: Exibir uma recomendação de build (Nativo vs Emulado) com base nos dados.

Ir para próxima aula: Navegação e Fluxo

Aula: O Caso de Estudo Apple 🍎

Evolução e Eficiência

Entender as transições da Apple é entender a história da eficiência computacional. A distinção entre emulação e simulação define o fluxo de trabalho de um desenvolvedor mobile.

1. A Jornada do Silício 🕒

A Apple passou por grandes transições de arquitetura, cada uma com um "tradutor" para manter a compatibilidade.

Linha do Tempo de Transições 📊

timeline
    title Evolução Apple
    1994 : PowerPC (RISC) : Foco em performance bruta
    2006 : Intel (CISC) : Mobilidade e compatibilidade : Rosetta
    2020 : Apple Silicon (ARM) : Eficiência extrema e UMA : Rosetta 2

Conceito: Arquitetura Unificada de Memória (UMA)

No Apple Silicon, a CPU, GPU e NPU compartilham o mesmo pool de memória de alta velocidade. Isso elimina a necessidade de copiar dados entre memórias diferentes, fazendo com que 8GB de RAM rendam muito mais que em sistemas tradicionais.

2. Ferramentas de Teste: Virtualização vs. Simulação 📱

Como testamos sem o hardware físico?

Característica Emulação (Android) Simulação (iOS)
Definição Imita o Hardware. Imita o Software.
Arquitetura Cria uma CPU virtual (QEMU). Roda bibliotecas nativas no Mac host.
Performance Mais lenta (pesada). Ultra rápida (leve).
Fidelidade Alta (testa limites de RAM). Média (foco em UI/UX).

Atenção: Diferença de Comportamento

Um app que roda perfeito no Simulador iOS pode falhar no aparelho real por questões de temperatura ou memória. Nunca publique sem testar no hardware físico!

3. Na Prática: Verificando Nativismo 💻

Como saber se um processo está rodando nativamente no seu Mac?

arch arm64 file /usr/local/bin/legacy_app Mach-O 64-bit executable x86_64 ⚠️ Esse app está rodando via Rosetta 2!

4. Desenvolver iOS no Windows? 🖥️

A resposta curta é: Sim, com ressalvas.

  • Frameworks Multiplataforma: Flutter ou React Native permitem escrever o código no Windows.
  • A "Tranca" da Apple: Para gerar o arquivo .ipa final e publicar, um macOS (físico ou cloud) ainda é obrigatório.
  • Expo: Uma ótima ferramenta para testar no iPhone físico sem precisar de Mac durante o desenvolvimento inicial.

Dica: MacinCloud

Se você não tem um Mac, serviços como MacinCloud permitem alugar um servidor macOS por hora para compilar seus projetos.

📝 Exercícios Progressivos

  1. Nível 1: O que foi a tecnologia Rosetta e por que ela foi vital para a Apple em 2006 e 2020?
  2. Nível 2: Explique por que o Simulador do Xcode é geralmente mais rápido que o Emulador do Android Studio.
  3. Nível 3: Pesquise sobre a Arquitetura Unificada de Memória (UMA) e cite uma vantagem técnica sobre o modelo tradicional de GPU dedicada.

🚀 Mini-Projeto: Dashboard de Compatibilidade

Objetivo: Criar um guia rápido (Tabela MD) para uma equipe que usa diferentes hardwares.

  • Tarefa 1: Criar uma tabela listando 3 tecnologias populares (ex: Docker, VS Code, Android Studio).
  • Tarefa 2: Indicar se rodam nativamente em x86, ARM (Silicon) ou via emulação.
  • Tarefa 3: Adicionar uma coluna de "Impacto de Performance" (Baixo, Médio, Alto).

Ir para próxima aula: Configuração de Sistemas

Aula: Virtualização e Baixo Nível ⚙️

O "Pulo do Gato" para Desenvolvedores Modernos

Aprenda como rodar código em qualquer lugar e como o software interage com a camada de "quase-hardware".

1. Virtualização e Abstração 🏗️

Nesta camada, isolamos o hardware para ganhar portabilidade e segurança.

Camadas de Abstração 📊

graph TD
    A[Hardware Real] --> B[Hypervisor]
    B --> C[Máquina Virtual 1]
    B --> D[Máquina Virtual 2]
    A --> E[Docker Engine]
    E --> F[Container x86]
    E --> G[Container ARM]
  • Hypervisors: Proxmox, Hyper-V e VirtualBox.
  • Containers Multi-Arquitetura: Uso de Docker Buildx para rodar o mesmo app em Intel e ARM.

2. Firmware e Boot: O Acordar do PC ⚡

  • BIOS vs. UEFI: Como o computador entrega o controle ao SO.
  • Bootloaders: O papel do U-Boot (Mobile/ARM) e do GRUB.
  • Segurança: TPM e Secure Boot (essenciais para Windows 11 e apps bancários no Mobile).

Conceito: big.LITTLE

Processadores móveis misturam núcleos de Alta Performance (potência) com núcleos de Alta Eficiência (economia). O software deve ser inteligente para não acordar os núcleos potentes sem necessidade.

3. Na Prática: Docker Multi-Arch 💻

Criando imagens que rodam tanto no seu PC quanto no Raspberry Pi.

docker buildx create --use docker buildx build --platform linux/amd64,linux/arm64 -t meu-app . 🚀 Imagem pronta para Intel e Apple Silicon!

4. Real-Time Systems (RTOS) ⏱️

Crucial para sistemas críticos como drones ou freios ABS.

Atenção: Determinismo

Diferente do Windows, um RTOS (como FreeRTOS) garante que uma tarefa será executada em um tempo exato. No desenvolvimento mobile, usamos conceitos similares para garantir a fluidez da UI (60fps).

5. Comparativo de Ecossistemas 📊

Tema Desktop (High) Mobile (Mid) Embarcados (Low)
CPU Intel i9 / Ryzen 9 Snapdragon / Apple A ESP32 / AVR
Arquitetura CISC (x86_64) RISC (ARM64) RISC (Xtensa)
OS Principal Windows / Linux Android / iOS RTOS / Bare Metal

Dica: WebAssembly (Wasm)

O Wasm é o "binário universal" que permite rodar código C++/Rust no navegador com performance nativa, independente da CPU por baixo.

📝 Exercícios Progressivos

  1. Nível 1: Explique a diferença entre uma Máquina Virtual e um Container Docker em termos de uso de recursos do hardware.
  2. Nível 2: Por que desenvolvedores mobile devem se preocupar com o "Thermal Throttling" (redução de clock por calor)?
  3. Nível 3: O que é uma NPU (Neural Processing Unit) e como ela ajuda a economizar bateria em tarefas de IA local?

🚀 Mini-Projeto: Monitor de Recursos Bare-Metal

Objetivo: Pesquisar e documentar como acessar o "Uptime" do sistema sem bibliotecas de alto nível.

  • Tarefa 1: No Linux, pesquisar o arquivo no /proc que guarda a temperatura da CPU.
  • Tarefa 2: Criar uma tabela comparando o consumo de RAM de um app "Hello World" em Java vs. Rust.
  • Tarefa 3: Simular (teoricamente) o impacto de um loop infinito em um núcleo de "Alta Eficiência" de um ARM.

Ir para próxima aula: Mobile (Flutter e Kotlin)

Aula: Mobile (Flutter e Kotlin) 📱

Ambiente de Desenvolvimento Pro

O desenvolvimento mobile exige ferramentas mais pesadas. Prepare sua máquina para criar apps profissionais.

1. Android Studio: O Motor Nativo 🛠️

Essencial para emular celulares Android e realizar debug de baixo nível.

Fluxo de Instalação 📊

graph LR
    A[Download IDE] --> B[Install SDK]
    B --> C[Configure AVD]
    C --> D[Ready for Kotlin/Java]
  1. Baixe em developer.android.com/studio.
  2. Instale e deixe ele baixar o Android SDK.

Atenção: Aceleração de Hardware

Para rodar o emulador rápido, ative o Intel HAXM ou Hyper-V na sua BIOS. Sem isso, o emulador será extremamente lento.

2. Flutter SDK: Multiplataforma 🚀

Para criar apps iOS e Android com a mesma base de código.

  1. Extraia o SDK em C:\src\flutter.
  2. Adicione o bin ao Path do Windows.

Verificando a Saúde do Ambiente 💻

flutter doctor flutter doctor --android-licenses [✓] Android toolchain - developed for Android devices [✓] Chrome - developed for the web 🚀 Siga as instruções do doctor para finalizar!

3. Visual Studio Code 💻

O editor preferido por ser leve e ter extensões poderosas.

Dica: Extensões Obrigatórias

Instale as extensões Flutter e Dart. Elas trazem autocomplete, refactoring e hot reload automático.

📝 Exercícios Progressivos

  1. Nível 1: Qual a função do comando flutter doctor e por que ele é a primeira coisa a se rodar após instalar o SDK?
  2. Nível 2: Por que precisamos do Android Studio mesmo se formos programar apenas em Flutter usando o VS Code?
  3. Nível 3: Explique a diferença entre um AVD (Android Virtual Device) e um dispositivo físico para testes.

🚀 Mini-Projeto: First Run

Objetivo: Criar e rodar o projeto padrão do Flutter.

  • Tarefa 1: Criar o projeto via terminal: flutter create meu_primeiro_app.
  • Tarefa 2: Abrir o projeto no VS Code e localizar o arquivo main.dart.
  • Tarefa 3: Rodar o app no emulador e testar o Hot Reload mudando a cor do tema.

Ir para próxima aula: Ecossistemas Modernos

Aula: Ecossistemas Mobile Modernos 📱

Pontes entre Hardware e Software

Nesta aula, exploraremos como transformamos código em apps funcionais para Android (ARM) e iOS (Apple Silicon), navegando entre soluções nativas e multiplataforma.

1. O Espectro do Desenvolvimento 🏗️

O desenvolvedor moderno deve escolher entre Performance Máxima (Nativo) ou Agilidade de Escopo (Multiplataforma).

Mapeamento de Tecnologias 📊

graph TD
    A[Desenvolvimento Mobile] --> B[Nativo]
    A --> C[Multiplataforma]
    B --> D[Android: Kotlin/Java]
    B --> E[iOS: Swift]
    C --> F[Híbrido: Ionic/Capacitor]
    C --> G[Renderizado: RN/Flutter]
    C --> H[Compilado: .NET MAUI]
  • Nativo: Acesso total ao hardware com latência zero.
  • Multiplataforma: Reuso de código (escreva uma vez, rode em dois).

2. Na Prática: O Poder da CLI 💻

Para criar um app moderno, o fluxo via terminal é o padrão de mercado.

npx ionic start MySuperApp tabs --type=angular npx cap add android 🚀 Projeto configurado para ARM64/x86!

3. Blocos de Conhecimento 🧠

Conceito: Compilação AOT vs JIT

No iOS, o código deve ser compilado AOT (Ahead-of-Time) por segurança. No Android, usamos JIT (Just-in-Time) para otimizar o app enquanto ele roda.

Atenção: Bridge vs Engine

O React Native usa uma "ponte" (bridge) para falar com o nativo, o que pode causar gargalos. O Flutter carrega sua própria "engine" de desenho (Skia/Impeller), sendo mais fluido na UI.

Dica: .NET MAUI

O MAUI é a evolução do Xamarin e permite criar apps para Android, iOS e Windows ARM usando C#. É ideal para ecossistemas corporativos.

📝 Exercícios Progressivos

  1. Nível 1: Explique por que um app feito em Ionic tende a consumir mais memória RAM do que um app em Swift nativo.
  2. Nível 2: Em qual camada do sistema operacional o .NET MAUI atua para acessar o GPS de diferentes plataformas simultaneamente?
  3. Nível 3: Desenhe (mentalmente ou em papel) o fluxo de dados de um botão clicado em um app React Native até ele ser processado pela CPU ARM.

🚀 Mini-Projeto: Dashboard de Arquitetura

Objetivo: Criar um protótipo que detecta a arquitetura do processador.

  • Requisito 1: Usar Ionic + Capacitor para acessar a API de Device Info.
  • Requisito 2: Exibir se o dispositivo é arm64, x86_64 ou unknown.
  • Requisito 3: Adicionar um botão que simula um processamento pesado para observar o comportamento térmico.

Retornar ao Índice de Setups

🎮 Aula: A Arte da Simulação - Emulação Android vs. Videogames

Entender a emulação é entender a tradução em tempo real. Se o Android fala "Português" (Instruções ARM) e seu PC fala "Inglês" (Instruções x86), precisamos de um tradutor muito rápido no meio do caminho.

1. O Tradutor de Instruções (ISA)

Imagine que você quer rodar um jogo de Super Nintendo (65816) no seu PC (x86). O emulador precisa ler cada instrução do jogo e converter para algo que o seu processador entenda. No Android é igual.

  • Emulação por Software: O PC lê a instrução ARM, interpreta o que ela faz e executa uma função equivalente em x86. É lento (como o emulador de PS3 no PC).
  • Virtualização (HAXM/KVM): Se o Android que você está emulando for versão x86, o PC não traduz, ele apenas "isola" uma fatia do processador. É muito rápido.
graph LR
    subgraph "Hardware Real (Hospedeiro)"
    A[CPU Intel/AMD x86_64]
    end

    subgraph "Camada de Emulação"
    B{Tradutor Binário}
    end

    subgraph "Sistema Convidado (Guest)"
    C[Android ARM64]
    D[Apps e Jogos]
    end

    D --> C
    C --> B
    B -- "Tradução JIT" --> A

2. Por que o Emulador de Android é "Pesado"?

Diferente de um emulador de GameBoy, o Android é um sistema operacional completo (Kernel Linux, Interface Gráfica, Drivers).

  • GPU Passthrough: O emulador precisa traduzir comandos OpenGL/Vulkan do Android para a sua placa de vídeo real.
  • Aceleração de Hardware: Sem o Intel VT-x ou AMD-V ativado na BIOS, o emulador tenta traduzir tudo via software, resultando em 1 FPS.

3. Na Prática: Verificando Suporte e Iniciando

Antes de rodar um "console" Android no seu PC, precisamos garantir que os motores de tradução estão ativos.

cpu-check --is-virtualization-enabled KVM acceleration can be used: YES emulator -avd Pixel_7_Pro_API_34 -gpu host 🚀 Android booting on x86_64 using Hardware Acceleration...

🧠 Blocos de Conhecimento

💡 Conceito: Tradução Binária Dinâmica É o processo onde o emulador traduz blocos de código ARM para x86 "on-the-fly". É exatamente o que o Rosetta 2 faz nos Macs M1/M2, mas no sentido inverso (x86 para ARM).

⚠️ Atenção: Intel Atom vs. ARM Antigamente, existiam celulares com processador Intel Atom (x86). Neles, não havia emulação, o Android rodava nativo. Hoje, 99% dos celulares são ARM, exigindo tradução pesada nos emuladores.

📝 Exercícios Progressivos

  1. Analítico: Por que emular um PlayStation 1 (33MHz) é muito mais fácil do que emular um celular Android moderno de entrada?
  2. Arquitetura: Explique a diferença entre usar uma imagem de sistema arm64-v8a vs x86_64 no Android Studio. Qual terá melhor performance no seu PC?
  3. Hardware: Pesquise por que o recurso VT-x (Intel) ou SVM (AMD) precisa estar habilitado na BIOS para o emulador funcionar bem.

🚀 Mini-Projeto: "The Emulator Benchmarker"

Objetivo: Comparar a velocidade de execução de um algoritmo de cálculo entre o seu PC nativo e o Android emulado.

  1. Crie um script simples que calcula números primos até 100.000.
  2. Execute-o no seu terminal (PowerShell/Bash).
  3. Execute-o dentro do emulador Android (via adb shell).
  4. Relatório: Calcule o "Custo da Emulação" (Tempo Android / Tempo PC). Se o Android demorar 2x mais, seu custo de tradução é de 100%.

Sobre

Sobre o Curso

🎓 Desenvolvimento Mobile Nativo Profissional

Este curso foi projetado para transformar iniciantes em desenvolvedores capazes de criar, testar e publicar aplicativos de alto desempenho para o ecossistema Android, mantendo uma base sólida de conhecimento para transição futura para iOS.

🎯 Objetivos do Curso

  • Domínio Android --- Dominar Kotlin e Java, o Android Studio e os componentes principais do sistema (Activities, Services, Manifest).

  • Arquitetura de Mercado --- Utilizar o padrão MVVM, LiveData e ViewModel para criar códigos escaláveis e fáceis de manter.

  • Dados e Networking --- Conectar apps ao mundo real via Retrofit (APIs REST) e persistência local com Room Database.

  • Publicação e Carreira --- Entender o processo de assinatura de apps, geração de AAB e publicação na Google Play Store.

📚 O Que Você Vai Aprender

Módulo 1 – Fundamentos e UI

  • História do Mobile e Mercado
  • Kotlin vs Java vs Swift
  • Interfaces com XML e ViewBinding
  • ConstraintLayout e Unidades (dp/sp)

Módulo 2 – Navegação e Arquitetura

  • Intents e Backstack
  • Ciclo de Vida do Android
  • Padrão MVVM (ViewModel + LiveData)
  • Temas e Material Design 3

Módulo 3 – Listas e Persistência

  • RecyclerView e Adapters eficientes
  • Banco de Dados Room (SQLite)
  • Consumo de APIs com Retrofit
  • Gerenciamento de Threads (Coroutines)

Módulo 4 – Recursos Avançados

  • Sensores, Câmera e GPS
  • Testes Unitários e Testes de UI (Espresso)
  • Debugging e Logcat
  • Publicação na Store

🛠️ Metodologia

Foco 100% prático. Cada aula termina com um desafio real que compõe seu portfólio. Utilizamos diagramas interativos e quizzes para garantir a fixação do conteúdo técnico.

Pronto para o próximo nível? Começar Agora

Roadmap do Projeto: Curso Mobile Nativo 📱

Este documento rastreia a evolução do curso.

✅ Fase 1: Planejamento (Concluído)

  • Definição Syllabus (16 Aulas)
  • Estrutura Android first com paralelos iOS
  • Configuração MkDocs Material

✅ Fase 2: Conteúdo Base (Concluído)

  • Criação das 16 Aulas (Markdown)
  • Criação dos 16 Quizzes (HTML)
  • Criação dos 16 Conjuntos de Exercícios
  • Criação dos 16 Slides (RevealJS)

✅ Fase 3: Projetos e UX (Concluído)

  • Definição dos 16 Challenges/Projetos
  • Aplicação de Material Design 3 no conteúdo
  • Diagramação Mermaid de ciclo de vida e arquitetura

🚀 Fase 4: Lançamento e Manutenção

  • Deploy GitHub Pages
  • Atualização para novas versões SDK (Android 14+)
  • Inclusão de vídeos demonstrativos

Status Atual: Finalizado / Manutenção Última Atualização: 19/02/2026

Materiais

Bem-vindo à seção de materiais complementares do curso. Aqui você encontra recursos adicionais para apoiar seus estudos.

  • Slides

    • Acesse os slides de todas as aulas para revisão.

  • Exercícios

    • Pratique com listas de exercícios para cada módulo.

  • Quizzes

    • Teste seus conhecimentos com quizzes interativos.

  • Projetos

    • Desenvolva projetos práticos para aplicar o que aprendeu.

  • Setup

    • Guias de instalação e configuração do ambiente.

🏷️ Índice de Tags Didáticas

Navegue pelas aulas, exercícios e projetos do curso organizados por temas, tecnologias e conceitos fundamentais:

tags.md:145-167/name

Versão para Impressão

Esta página foi gerada automaticamente para impressão.