- A escolha do método de troca. Descrição da API.
- Implementação de API no lado 1C.
- BroadcastReceiver Recebemos um código de barras no exemplo do ATOL Smart.Lite.
- OnKeyUp. Obtenha um código de barras em um scanner com emulação de teclado
- Menu, objeto complementar
- Realizamos troca e armazenamento de dados. Usamos Retrofit 2, Room, Coroutines.
- Interface do usuário LiveData, PagedList.
Para quem
Os dois primeiros capítulos são uma tentativa de estruturar a experiência de integrar o 1C com outros aplicativos e serviços da web. O próprio ciclo, acho, será interessante para os programadores da 1C que estão tentando ir além da plataforma e tentar algo novo. Os desenvolvedores de aplicativos Android não aprenderão nada de novo por si mesmos, mas talvez eles estejam interessados na aparência do lado 1C. Começando com a quarta parte, haverá uma tentativa de combinar vários artigos dispersos da Internet sobre o uso de bibliotecas, bem como atualizar dados sobre eles. O ciclo foi concebido como um livro didático, que descreve a experiência no desenvolvimento de uma aplicação real. Eu mesmo não sou desenvolvedor de Android. Mas até o final da série, espero me tornar um.
2. A escolha do método de troca. Descrição da API
Em sua forma atual, o 1C pode ser contatado de mil e uma maneiras. Considere várias opções e por que não as usei.
- Componente nativo - Na maioria das vezes, é bom usá-lo para compartilhamento offline. Para o Online, ele está mal adaptado. Tornou-se ainda pior quando a 1C começou a implementar seus padrões de troca com equipamentos comerciais. E também esse componente é chamado no lado 1C. Não combina comigo.
- Serviços WEB - Mais projetados para o intercâmbio entre aplicativos que desenvolvem equipes diferentes. Pesado, use XML. Pessoalmente, é muito difícil para mim desenvolver. E ainda mais difícil de integrar em JavaScript, Golang, etc. Não é adequado.
- Serviços HTTP - Quase o mesmo que os serviços WEB, mas descrevemos a lógica do trabalho e trocamos os protocolos completamente. Aqui não estamos limitados à invenção de nossa própria bicicleta. Por esse motivo, esse mecanismo de troca específico foi escolhido.
As tarefas que nosso aplicativo resolve. "Tudo o que pode ser feito no TSD deve ser feito no TSD." Bem, como um conjunto padrão: aceitação, inventário, rótulos, etiquetas de preço.
Lista completa de tarefas- Trabalhar com mercadorias: impressão de etiquetas e etiquetas de preços, atribuição de um código de barras (código de barras), verificação do código de barras, remoção do código de barras, visualização de preços e quantidades em armazéns.
- Inventário - Realmente conduzindo inventários.
- Recebimento - Aceitação de mercadorias na fatura, impressão de discrepâncias, impressão de documentos internos, status da fatura.
- Coleta de mercadorias, Realização (varejo) - A idéia é que os vendedores não estejam na caixa registradora, mas vão com o comprador ou colecionam mercadorias mediante solicitação, etc. Há apenas uma pessoa no balcão de checkout, uma verificação pronta é transmitida pelo TSD. O comprador paga apenas pelos bens.
- Coleta de mercadorias, Realização (Atacado) - Coletamos mercadorias na conta. Verificamos o que está disponível. Formamos uma remessa (com um pacote dos documentos necessários). Não se esqueça de verificar a possibilidade de envio para a contraparte.
- Coleta de mercadorias, preparação para embarque - Coletamos mercadorias a pedido, colocamos em um palete, imprimimos documentos: lista de embalagem, etc.
- Movimentação - Coletamos mercadorias para movimentação, damos na entrega.
- Coleta de mercadorias, uma lista arbitrária - Necessária para reavaliações, atualização de preços, etiquetas e outras operações similares.
Voltar para a estrutura da API. O intercâmbio entre TSD e 1C será no formato JSON. Na resposta, teremos apenas dois objetos
{resultado, carga}, respectivamente: o
resultado e a
carga . Como resultado, retornaremos dois campos
{code, msg} . E sempre responderemos com o código HTTP 200. Portanto, será mais fácil para nós, do lado do cliente, analisar a estrutura de resposta. Todas as outras respostas virão como uma string. 1C não nos permite personalizar respostas fora da plataforma.
Por que é mais fácil dar 200A maioria das bibliotecas para trabalhar com dados (incluindo Retrofit), ao receber código diferente de 200, não analisa o resultado. E temos que "analisá-lo" com canetas.
Agora temos o seguinte diagrama. Se a resposta for 200, nossos procedimentos em 1C funcionaram bem. Se uma resposta diferente, temos um problema abaixo. Aqui não podemos ir fundo, o que deu errado, mas imediatamente mostrar ao usuário qual erro e sua descrição. Alguém pode dizer que os erros precisam ser processados sem a intervenção do usuário, mas podemos ter duas situações: 1 - o servidor retornou um erro. 2 - brega sem conexão. No primeiro caso, talvez nem saibamos que algo está quebrado (por exemplo, erro 404: o aplicativo solicitou um método inexistente. 500: A plataforma travou com uma exceção). No segundo, não podemos transferir o resultado para análise para o servidor. Portanto, mostramos um erro e esperamos mais ações do usuário.
A carga útil conterá objetos diferentes. Pode ser uma lista de mercadorias, uma lista de documentos, uma lista de ações será transmitida para lá. No lado da aplicação, iremos descrevê-los com modelos e dobrá-los cuidadosamente no banco de dados. Vamos lançar a lista de ações para execução e adicionar cuidadosamente os resultados ao banco de dados.
O ciclo de intercâmbio com o TSD será o seguinte:
- O aplicativo de comando envia uma solicitação para 1C.
- 1C forma uma resposta e retorna uma estrutura com o resultado e os dados. Em 1C, os registros de informações acumulam dados alterados no contexto do TSD (serviço da web).
- Mediante solicitação do aplicativo, uma lista de métodos a serem chamados é enviada.
Esse esquema foi escolhido porque o TSD pode ser desligado, desligado da rede, etc. Mas nada nos impede de finalizar o 1C para que, ao alterar dados, notifique outro aplicativo (serviço da web) sobre ele. Com essa troca, informamos que há novos dados. O aplicativo pergunta quais dados existem e o loop se repete. Um exemplo de troca é apresentado no diagrama.
Isso é tudo. Se você tiver perguntas, comentários, sugestões, escreva nos comentários.