API Cobrança - Enviar Lista de Boletos ou um a um?

[Luciano Rodrigues Pereira]

Com exceção de tpConsulta, todos os demais comandos como tpInclui, tpAltera, tpBaixa e tpConsultaDetalhe usam a lista de boletos.

Digamos que eu tenha que registrar 1.000 boletos. Eu adiciono os 1.000 boletos na lista e depois faço o ACBrBoleto1.enviar Ou envio um a um? Hoje eu faço um a um, ou seja, limpo a lista toda vez que faço a requisição de cada boleto. Isso porque eu não sei quanto tempo leva para fazer a requisição desta lista de uma vez só, porque se demorar o usuário terá a impressão que a aplicação está travada. Por isso faço um a um e uso uma Progressbar para acompanhar.
Então eu pergunto:

1. Dentro do comando ACBrBoleto1.enviar ele faz um loop fazendo a requisição à API boleto à boleto que está na ListaDeBoletos?

2. O processo de enviar é feito em primeiro plano ou em segundo plano (via Threads)? Porque em segundo plano é bom que libera de imediato a interface da aplicação para o usuário. Em contrapartida, se o usuário que não sabe se o processo que está em segundo plano fechar a janela ou fechar o app ele mata o processo. Por isso não gosto de usar Threads, só quando crio um serviço que vai rodar em um servidor dedicado, mas para interface com o usuário não.

3. Vai fazer muita diferença em termos de tempo fazer um ACBrBoleto.enviar com uma lista de boletos populada com 1.000 boletos (usando o Loop interno do ACBr) ou fazer como estou fazendo, limpando a lista a cada boleto que vou fazer a requisição e enviando um a um (usando meu próprio loop) e acompanhando com a Progressbar? 

4. O banco fala que cada requisição leva centésimo de segundo, mas nos testes com o ACBr demora bem mais que isso cada requisição. É por conta dos processos internos do ACBr? 

5. Pela experiência de seus clientes, o tempo para uma requisição de uma lista de 1.000 boletos demora quanto tempo? Porque se levar uns 10 segundos vale a pena enviar a lista sem a ProgressBar, caso contrário é melhor enviar um a um e usar a ProgessBar para acompanhar o envio. Qual a melhor estratégia?

 

 

[Juliomar Marchetti]

coloca algo para mostrar mensagem enquanto envia e continua mandando um a um normal

pois pra ficar alteranando entre thread visuais demanda tempo da principal e vai demorar mais ainda o envio.

 

[Luciano Rodrigues Pereira]

Não entendi.

1. Então existe um loop de envio para a lista de boletos dentro do comando "enviar", óbvio. E esse envio de cada um da lista é feito via Thread, em segundo plano?

2. Se o ACBr faz via Thread, não vai fazer diferença eu enviar um a um ou enviar a lista inteira de uma só vez, pois vai ser tudo via thread. O que muda é só que se eu mandar a lista toda de uma só vez eu vou estar usando o loop do ACBr e se eu mandar um a um vou usar meu próprio loop, mas vai tudo para segundo plano, não?

3. Quando eu uso o ProgressBar eu trago tudo para primeiro plano. Você diz para eu trocar meu ProgressBar por uma mensagem na tela para continuar usando as threads? Mas para uma interface com o usuário tem o problema da thread liberar de imediato a interface enquanto faz o processo em segundo plano e o usuário poder fechar a janela ou o app e matar o processo sem saber, não?

Me explica melhor essa sua estratégia, por favor.

[Juliomar Marchetti]

Não tem.

tu envia um a um

se tu usar pintura de progress tu vai demorar mais ainda , windows fica lento interação entre telas, coloque algo dizendo enviando epronto até o fim