filipegarrett / salarium Goto Github PK

Em testes, observei que as últimas modificações nas checagens do FirebaseAuth tornaram o processo um pouco mais demorado. Acredito que seja inevitável o delay - são checagens de autenticação referentes ao e-mail do usuário ser ou não verificado, por exemplo - e imagino que seja necessário estudar como incluir algum tipo de animação de carregamento para que o usuário não tenha a sensação de que o app parou de responder

Texto de ajuda do Simulador de investimentos está com problemas de formatação. Pode ser preciso criar um layout para corrigir o problema.

Para poder persistir dados localmente na ausência de conexão, precisamos migrar todas as instâncias de banco de DatabaseReference para FirebaseReference que permite usar o método setPersistenceEnabled(true).

Isso significa que:

public static DatabaseReference getFirebaseDatabase(){
        if(firebase == null){
            firebase = FirebaseDatabase.getInstance().getReference();

        }
        return firebase;

Não funciona. A implementação correta seria:

public static FirebaseDatabase getFirebaseDatabase(){
        if(firebase == null){
            firebase = FirebaseDatabase.getInstance().setPersistence(true);

        }
        return firebase;

Aí dentro das classes, ao criar um objeto FirebaseDatabase, passamos o .getReference().

Eu fiz uns testes superficiais e encontrei vários problemas: para começar, o getReference() que usamos para apontar para o primeiro nó do banco não pode ser chamado diretamente por um FirebaseDatabase. Encontrei outros problemas também que provocam crash no app referentes à necessidade de se chamar setPersistenceEnabled(true).

Marquei nós dois nessa issue porque a coisa parece que vai ser mais complicada - não porque seja um processo complexo, mas sim porque criamos todo o projeto de um jeito e teremos que retrabalhá-lo - e porque temos várias classes para ajustar. Sugiro fazer testes aí também para ver se você encontra uma forma de migrar o projeto sem tanto estresse.

É preciso investigar a possibilidade de uso do menu com a manutenção do SmartTabLayout. Uma possibilidade poderia ser usar os métodos padrão das Activities para tentar chamar a Main a partir dos Fragments

Problema de conversão de valores. Precisa aplicar a mesma solução usada na calculadora de Poupança para evitar que números em milhar - 1.000,00 - provoquem travamento do app.

Precisa implementar a leitura dos atributos do usuário a partir do FirebaseAuth para alimentar essas caixas de texto. Correção simples, deve ser integrada com a implementação final (oremos) do RecyclerView.

Após realizar testes de criação de categorias através de fragments diferentes na aplicação, observei que estava criando categorias somente para gastos mesmo na fragment de recebimentos.

Se você cadastrar, ou não cadastrar algo, e sair dessas telas, fazer qualquer coisa no app, e voltar depois, os dados preenchidos permanecem nos campos.

A minha ideia seria implementar um refresh (provavelmente chamado por sobrescrita dos métodos onResume) dos fragments para limpar esses campos. É bem fácil de cadastrar algo duas vezes sem querer, daí a importância dessa correção.

Outra ideia é aplicar o "esconderTeclado" usado em outras fragments e activities. Isso esconde o teclado assim que o usuário clica em "cadastrar", algo que deixa o uso do app mais fluído.

Se sobrar um tempo criar uma Alert dialog com uma confirmação antes de sair diretamente da aplicação.

A inclusão de entradas de datas passadas gera childs fora de ordem no Firebase e isso acaba gerando uma série de problemas nas telas de Relatórios e Gráficos.

Uma forma temporária de corrigir isso seria impedir que os datePickers permitam escolha de datas passadas. A mesma solução já foi aplicada em Contas à Vencer, basta copiar.

Uma ideia seria mudar as categorias dos gastos para "Gastei" e "Recebi". Fica mais padronizado do que "Recebimento" e "Gasto", o que deixa o layout melhor.

Com a aplicação da persistência local do Firebase, é possível que no primeiro uso o cidadão tente preencher alguma entrada sem nenhuma categoria (seja porque o app não teve condições de baixar do Firebase, seja porque nenhuma foi criada a tempo).

Nos meus testes, ao tentar cadastrar uma despesa sem categoria selecionada enquanto offline, provoquei um NullPointerException por conta da falta de categorias dentro do spinner:

E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.filipewilliam.salarium, PID: 6678
    java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String java.lang.Object.toString()' on a null object reference
        at com.filipewilliam.salarium.fragments.GasteiFragment.criarGasto(GasteiFragment.java:139)
        at com.filipewilliam.salarium.fragments.GasteiFragment$4.onClick(GasteiFragment.java:120)
        at android.view.View.performClick(View.java:7333)
        at android.widget.TextView.performClick(TextView.java:14160)
        at android.view.View.performClickInternal(View.java:7299)
        at android.view.View.access$3200(View.java:846)
        at android.view.View$PerformClick.run(View.java:27773)
        at android.os.Handler.handleCallback(Handler.java:873)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loop(Looper.java:214)
        at android.app.ActivityThread.main(ActivityThread.java:6990)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:494)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1445)

Imagino que isso possa ser contornado usando um tratamento de exceção que não chame o método de cadastro caso spinnerCategoriaGasto.getSelectedItem().toString().isEmpty() retorne true.

Atualmente, caso o usuário decida que quer receber notificações avisando sobre o vencimento de alguma despesa, não há agendamento: a notificação é criada e emitida com sucesso, só que imediatamente no instante do cadastro da despesa.