Ferramentas de armazenamento, entidades, DAOs e operações Create, Read, Update e Delete implementadas em Kotlin e Swift no contexto do ensino técnico de Desenvolvimento de Sistemas.
Por que o aluno implementa o CRUD errado na primeira vez?
A sequência é quase previsível: o estudante cria a entidade, escreve o DAO, instancia o banco — e na hora de executar uma consulta, o app fecha com uma exceção de banco de dados. Às vezes a query está mal formada. Às vezes o tipo da coluna não corresponde. Às vezes a anotação @Query aponta para uma tabela com nome diferente do que foi declarado na entidade.
O problema quase nunca é falta de esforço. É ausência de um modelo mental claro sobre como os três componentes do Room — entidade, DAO e banco de dados — se relacionam. Quando o estudante entende a arquitetura antes de escrever a primeira linha de código, os erros diminuem e a depuração se torna sistemática, não tentativa.
Custo concreto de não dominar o tema: um app de lista de tarefas sem CRUD funcional não é um app — é uma tela estática. Sem persistência real, nenhum projeto do curso técnico sobrevive à fase de avaliação. No mercado, qualquer desenvolvedor mobile precisa implementar CRUD com Room ou Core Data como competência de entrada, não diferencial.
O contexto da aula prática no ensino técnico público
Esta é a segunda aula da Unidade 2 — Armazenamento de Dados. Na aula anterior, os conceitos teóricos foram estabelecidos: a diferença entre memória volátil, SharedPreferences, arquivos e banco de dados local. Agora é o momento da implementação: 45 minutos, em grupo, com computador e internet, entrega de texto-síntese no AVA.
O formato em grupo não é casual. Implementar CRUD exige tomadas de decisão constantes — como nomear a tabela, quais operações expor no DAO, como inicializar o banco sem bloquear a thread principal. A discussão entre pares é parte do aprendizado, não apenas a execução do código.
O professor conduz a atividade a partir do roteiro oficial da SEDUC-SP, garantindo que os passos de configuração, definição de entidade, DAO, banco e operações CRUD sejam seguidos sequencialmente antes de qualquer execução.
CRUD é o conjunto de quatro operações fundamentais sobre dados persistidos: Create (inserir), Read (consultar), Update (atualizar) e Delete (remover). No Room, cada operação é declarada em uma interface DAO via anotações e implementada automaticamente pelo framework em tempo de compilação.
Como as ferramentas de armazenamento local se comparam?
| Ferramenta | Plataforma | Modelo de dados | Suporte a CRUD | Indicado para |
|---|---|---|---|---|
| SharedPreferences | Android | Chave-valor | Parcial (sem Update/Delete granular) | Configurações simples |
| UserDefaults | iOS | Chave-valor | Parcial | Preferências do usuário |
| Room | Android | Relacional (SQLite) | Completo (@Insert @Query @Update @Delete) | Listas, registros estruturados |
| Core Data | iOS | Objeto gerenciado | Completo (NSFetchRequest, save, delete) | Objetos com relacionamentos |
| SQLite direto | Android / iOS | Relacional | Completo (SQL bruto) | Controle granular, sem abstração |
A arquitetura do Room em três camadas
Room organiza o acesso ao banco de dados em três componentes independentes com responsabilidades distintas: a entidade define a estrutura da tabela; o DAO declara as operações disponíveis; o banco de dados conecta os dois e fornece o ponto de entrada para a aplicação.
Qual é o passo a passo correto para criar um banco de dados com Room?
- Configurar dependências: adicionar
room-runtimeeroom-compilernobuild.gradledo módulo app. O compilador Room é o responsável por gerar o código concreto do DAO em tempo de build. - Definir a entidade: criar uma
data classanotada com@Entity, declarando todos os campos como propriedades Kotlin. A colunaidrecebe@PrimaryKey(autoGenerate = true). - Criar o DAO: definir uma
interfaceanotada com@Daocontendo métodos anotados para cada operação CRUD. As queries SQL são validadas em tempo de compilação. - Implementar o AppDatabase: criar uma classe abstrata que estende
RoomDatabase, anotada com@Databaselistando as entidades e a versão do esquema. Expor o DAO como método abstrato. - Instanciar e executar: obter a instância do banco via
Room.databaseBuildere chamar as operações do DAO. Operações de escrita devem rodar em thread de background (Coroutine ou Thread separada).
Implementação completa: app de lista de tarefas com CRUD
Template 1 — Dependências (build.gradle · Android)
// No bloco dependencies do build.gradle do módulo app
dependencies {
implementation "androidx.room:room-runtime:2.4.2"
kapt "androidx.room:room-compiler:2.4.2"
// kapt exige o plugin kotlin-kapt no topo do arquivo
}// No topo do build.gradle
plugins {
id 'com.android.application'
id 'kotlin-android'
id 'kotlin-kapt' // obrigatório para o compilador Room
}Template 2 — Entidade, DAO e AppDatabase (Room · Kotlin)
// ── 1. ENTIDADE — mapeia a tabela "tarefas" ──
@Entity(tableName = "tarefas")
data class Tarefa(
@PrimaryKey(autoGenerate = true) val id: Int = 0,
val titulo: String,
val status: String // "pendente" | "completa"
)// ── 2. DAO — interface com todas as operações CRUD ──
@Dao
interface TarefaDao {@Insert // CREATE
fun inserirTarefa(tarefa: Tarefa)@Query("SELECT * FROM tarefas") // READ — todas
fun obterTodasTarefas(): List<Tarefa>@Query("SELECT * FROM tarefas WHERE status = :status") // READ — filtro
fun obterPorStatus(status: String): List<Tarefa>@Update // UPDATE
fun atualizarTarefa(tarefa: Tarefa)@Delete // DELETE
fun removerTarefa(tarefa: Tarefa)
}// ── 3. DATABASE — ponto de entrada ──
@Database(entities = [Tarefa::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
abstract fun tarefaDao(): TarefaDao
}Template 3 — Operações CRUD em uso (Kotlin / Coroutine)
// Instanciar o banco (apenas uma vez — usar Singleton em produção)
val db = Room.databaseBuilder(
applicationContext,
AppDatabase::class.java,
"tarefas-db"
).build()val dao = db.tarefaDao()// Room proíbe operações na main thread — usar Coroutine ou Thread
Thread {
// CREATE — inserir nova tarefa
dao.inserirTarefa(Tarefa(titulo = "Estudar Room", status = "pendente"))// READ — listar todas
val lista = dao.obterTodasTarefas()// UPDATE — marcar como completa
val primeira = lista.first()
dao.atualizarTarefa(primeira.copy(status = "completa"))// DELETE — remover
dao.removerTarefa(primeira)
}.start()Template 4 — Core Data (iOS · Swift): inserção e consulta
import CoreDataclass TarefaRepository {
private let context: NSManagedObjectContextinit(context: NSManagedObjectContext) {
self.context = context
}// CREATE
func inserirTarefa(titulo: String, status: String = "pendente") {
let nova = Tarefa(context: context)
nova.titulo = titulo
nova.status = status
try? context.save()
}// READ
func obterTodasTarefas() -> [Tarefa] {
let req: NSFetchRequest<Tarefa> = Tarefa.fetchRequest()
return (try? context.fetch(req)) ?? []
}// UPDATE
func atualizarStatus(tarefa: Tarefa, novoStatus: String) {
tarefa.status = novoStatus
try? context.save()
}// DELETE
func removerTarefa(tarefa: Tarefa) {
context.delete(tarefa)
try? context.save()
}
}Caso aplicado: app de lista de tarefas no laboratório do curso técnico
Atividade prática desenvolvida em grupo, 45 minutos, no laboratório de informática com acesso à internet. O contexto é um app de lista de tarefas com armazenamento local usando Room (Android). O estudante precisa definir a entidade Tarefa com três campos (id, titulo, status), implementar um DAO com os quatro métodos CRUD e configurar o AppDatabase.
Perguntas que o grupo deve responder ao fim da atividade: qual a vantagem do Room sobre arquivos diretos; como cada operação CRUD é implementada no DAO; como a modelagem do banco impacta a performance do app. O texto-síntese é entregue no AVA ao término da aula.
A atividade é deliberadamente acessível para um primeiro contato com persistência relacional, mas contém complexidade suficiente para exigir decisão técnica real: o grupo precisa escolher os tipos de dados das colunas, decidir se o campo status será String ou Boolean, e garantir que as operações não bloqueiem a thread principal.
Síntese: Room (Android) e Core Data (iOS) são as ferramentas de referência para banco de dados local em apps móveis. Ambas implementam CRUD via camada de abstração sobre SQLite. A arquitetura do Room em três camadas — entidade, DAO e banco de dados — exige configuração sequencial e correta para funcionar. A modelagem da entidade e a qualidade das queries no DAO impactam diretamente a performance e a manutenibilidade do app.
Perguntas frequentes sobre CRUD e ferramentas de armazenamento mobile
O que é CRUD em banco de dados móvel?
CRUD é o conjunto de quatro operações fundamentais sobre dados persistidos: Create (inserir novo registro), Read (consultar registros), Update (atualizar registro existente) e Delete (remover registro). No Room, cada operação é anotada respectivamente com @Insert, @Query, @Update e @Delete dentro de uma interface DAO.
Qual a vantagem de usar Room em vez de manipular arquivos diretamente?
O Room oferece validação de queries em tempo de compilação, mapeamento automático entre objetos Kotlin e tabelas SQLite via anotações, suporte nativo a LiveData e Flow para reatividade, e elimina o código boilerplate de abertura, cursor e fechamento que a API SQLite bruta exige.
O que é uma entidade no Room?
Uma entidade Room é uma data class Kotlin anotada com @Entity que representa uma tabela no banco de dados. Cada campo da classe corresponde a uma coluna da tabela. A anotação @PrimaryKey marca a chave primária, e autoGenerate=true delega ao SQLite a geração automática de identificadores únicos.
O que é um DAO no Room e para que serve?
DAO (Data Access Object) é uma interface no Room responsável por declarar todas as operações de acesso ao banco de dados. Cada método recebe uma anotação Room que o framework implementa automaticamente em tempo de compilação, sem que o desenvolvedor precise escrever SQL manualmente para operações básicas.
Como a estruturação do banco de dados afeta a performance do app móvel?
A modelagem impacta diretamente a velocidade de leitura e escrita. Índices em colunas usadas em filtros aceleram queries. Colunas com tipos corretos reduzem espaço em disco. Evitar dados duplicados diminui o volume de registros processados. Queries que varrem toda a tabela tornam-se gargalos visíveis em dispositivos de entrada.
>_ Sequência completa da Unidade 2 — Armazenamento de Dados
Acompanhe todas as aulas, roteiros de atividade e materiais de apoio no blog do Professor Comia.
acessar professorcomia.com.br →Conclusão: a arquitetura antes do código
Ensinar CRUD no ensino técnico não é ensinar quatro anotações Kotlin. É ensinar que nenhum dado sobrevive ao fechamento de um app sem uma decisão deliberada de persistência, e que essa decisão tem consequências em performance, manutenção e escalabilidade.
O estudante que termina esta aula sabendo distinguir entidade, DAO e banco de dados — e entendendo por que o Room valida queries em tempo de compilação — tem o modelo mental necessário para enfrentar qualquer banco de dados local em qualquer plataforma. A ferramenta muda. O raciocínio permanece.
📘 Gostou do que viu aqui no laboratório? No Professor com IA eu mostro, passo a passo, como você também pode criar ferramentas assim — mesmo sem saber programar.