Navegação entre páginas

O Recomendado nunca será passar um SQL diretamente na sua aplicação, por padrão o recomendado é você Criar uma Classe "Mapper" para ele converter suas consultas em metodos, e padronizar todo esse processo, dê uma estudada nessa questão que falei e você verá como é simples

Obrigado Samir, vou olhar. Fora a questão do SQL, a abordagem da navegação entre páginas e de um objeto com 100 propriedades está correta?

Sim está corerta, pois se você fizer o acoplamento corretamente não importa a quantidade de propriedades, pode até ser 10 mil, ai dependerá da sua necessidade.

Olá, Rodrigo!

Tem um ditado que diz "a escala muda tudo". E a escala do app que você está sugerindo é bem maior.

Eu gosto da abordagem do gmail: imagine que você está escrevendo um email longo, que você tem que examinar bem antes de enviar. Em algum momento, ao usar um atalho do teclado, você acaba fechando sem querer o navegador. O que acontece? Você perde seu trabalho? Quando você abre de novo o gmail, você fica aliviado porque descobre que o gmail já salvou um rascunho pra você. Então eu penso assim: se a sua aplicação exige que o usuário preencha numa entrevista 100 campos (coitado), então sua aplicação tem que ser amigável o bastante para permitir que os campos que ele digita sejam salvos num armazenamento local (ex.: SQLite) cada vez que ele saia de um campo para entrar em outro, ou então salvos em determinados "checkpoints" cada vez que ele avança de uma página para outra. A aplicação até poderia ser amigável a ponto de permitir que o usuário deixe algumas páginas em branco, para que ele possa preencher outras páginas enquanto não ainda tem as informações necessárias. No final, ele pode ir direto às páginas que ficaram em branco e preencher seus campos. Enfim, tem que pensar muito no usuário antes de projetar uma aplicação assim, porque a satisfação dele é fundamental para o sucesso do seu app.

Marcelo, muito interessante sua sugestão. A ideia está ficando mais clara! rs

Acho que a abordagem onde a cada mudança de tela os dados são salvos no SQLite seria a ideal. Mas esta abordagem levanta uma questão: Na tabela onde eu gravaria os dados no BD, cada linha representa uma entrevista. Desta forma, voltando ao app, quando eu avançar da primeira para a segunda tela, eu gravaria os dados (insert) e isso daria origem a primeira linha no meu BD. Da segunda para a terceira tela, eu não quero inserir uma nova linha, portanto não poderia usar novamente o insert. Teria então que de alguma forma recuperar o id da linha gerada no insert (ou usar algum tipo de GUID) e usa-lo a partir da segunda tela para efetuar updates?

Muito bom, Rodrigo!

Digamos que você tenha uma entidade no seu modelo, chamada Entrevista. O que eu faria? Sempre que o usuário iniciar uma nova entrevista, você cria um novo Entrevista e salva no banco (SQLite), obtendo assim o Id da entrevista. Entrevista tem vários campos, certo? Eu criaria um campo (propriedade) chamada Status, com códigos que indicam se a entrevista está em aberto, editando, finalizada, excluída, etc. Quando o usuário entra na aplicação, o app mostra a entrevista em aberto, ele clica, abre e começa a editar os campos. São 100 campos para preencher, então depois de 20 campos ele se cansa e fecha a aplicação. Horas depois, ele reabre o app para continuar preenchendo. Nesse momento, já sabemos o Id da entrevista (que obtemos do banco SQLite), portanto a aplicação pode continuar salvando aos poucos. Então seu usuário pode fechar e voltar pra aplicação quantas vezes ele quiser, pode até ficar 1, 2 ou 3 dias, ou 1 semana ou mais para preencher os dados, pois os dados estão sempre salvos (a não ser que você coloque uma regra para expirar a entrevista depois de um certo tempo). No final, o usuário confirma o final da entrevista e marcamos o Status como finalizado e, depois disso, desabilitamos a edição.

Obrigado Marcelo Vou implementar!

Abs

Excelente, Rodrigo, depois nos conte como ficou!