- La elección del método de intercambio. Descripción de la API.
- Implementación de API en el lado 1C.
- BroadcastReceiver Recibimos un código de barras en el ejemplo de ATOL Smart.Lite.
- OnKeyUp. Obtenga un código de barras de un escáner con emulación de teclado
- Menú, objeto complementario
- Realizamos el intercambio y almacenamiento de datos. Utilizamos Retrofit 2, Room, Coroutines.
- Interfaz de usuario LiveData, PagedList.
Para quien
Los primeros dos capítulos son un intento de estructurar la experiencia de integrar 1C con otras aplicaciones y servicios web. Creo que el ciclo en sí será interesante para los programadores de 1C que intentan ir más allá de la plataforma y probar algo nuevo. Los desarrolladores de aplicaciones de Android no aprenderán nada nuevo por sí mismos, pero tal vez estén interesados en cómo se ve en el lado 1C. A partir de la cuarta parte, se intentará combinar varios artículos dispersos de Internet sobre el uso de bibliotecas, así como actualizar datos sobre ellos. El ciclo fue concebido como un libro de texto, que describe la experiencia en el desarrollo de una aplicación real. Yo mismo no soy un desarrollador de Android. Pero para el final de la serie espero convertirme en uno.
2. La elección del método de intercambio. Descripción de la API
En su forma actual, 1C puede ser contactado de mil y una maneras. Considere varias opciones y por qué no las usé.
- Componente nativo : en su mayor parte, es bueno usarlo para compartir sin conexión. Para Online, está mal adaptado. Empeoró aún más cuando 1C comenzó a implementar sus estándares para el intercambio con equipos comerciales. Y también este componente se llama en el lado 1C. No me queda bien.
- Servicios WEB : más diseñados para el intercambio entre aplicaciones que desarrollan diferentes equipos. Peso pesado, use XML. Personalmente, es muy difícil para mí desarrollarme. Y aún más difícil de integrar en JavaScript, Golang, etc. No es adecuado
- Servicios HTTP : casi lo mismo que los servicios WEB, pero nosotros mismos describimos la lógica del trabajo y los protocolos de intercambio. Aquí no estamos limitados a la invención de nuestra propia bicicleta. Por esta razón, se eligió este mecanismo de intercambio particular.
Las tareas que resuelve nuestra aplicación. "Todo lo que se puede hacer en el TSD debe hacerse en el TSD". Bueno, como un conjunto estándar: aceptación, inventario, etiquetas, etiquetas de precios.
Lista completa de tareas- Trabajar con productos: imprimir etiquetas y etiquetas de precio, asignar un código de barras (código de barras), verificar el código de barras, eliminar el código de barras, ver precios y cantidades en almacenes.
- Inventario - Realización de inventarios.
- Recibo - Aceptación de bienes en la factura, impresión de discrepancias, impresión de documentos internos, estados de factura.
- Recolección de bienes, realización (venta minorista) : la idea es que los vendedores no se encuentren en la caja registradora, sino que vayan con el comprador o recojan los bienes a pedido, etc. Solo hay una persona en el mostrador, se transmite un cheque listo desde el TSD. El comprador solo paga por los bienes.
- Recolección de bienes, Realización (venta al por mayor) : recolectamos bienes en la cuenta. Verificamos lo que está disponible. Formamos un envío (con un paquete de los documentos necesarios). No se olvide de verificar la posibilidad de envío a la contraparte.
- Recolección de productos, preparación para el envío : recolectamos productos a pedido, los ponemos en una paleta, imprimimos documentos: lista de empaque, etc.
- Mudanza - Recolectamos productos para mudanza, entregamos en entrega.
- Colección de productos, una lista arbitraria : necesaria para reevaluaciones, actualización de etiquetas de precio, etiquetas y otras operaciones similares.
De vuelta a la estructura API. El intercambio entre TSD y 1C estará en formato JSON. En la respuesta solo tendremos dos objetos
{resultado, carga útil}, respectivamente: el
resultado y la
carga útil . Como resultado, devolveremos dos campos
{code, msg} . Y siempre responderemos con el código HTTP 200. Por lo tanto, será más fácil para nosotros del lado del cliente analizar la estructura de respuesta. Todas las demás respuestas vendrán como una cadena. 1C no nos permite personalizar las respuestas fuera de la plataforma.
Por qué es más fácil dar 200La mayoría de las bibliotecas para trabajar con datos (incluida Retrofit), cuando reciben un código diferente a 200, no analizan el resultado. Y tenemos que "analizarlo" con bolígrafos.
Ahora obtenemos el siguiente diagrama. Si la respuesta es 200, nuestros procedimientos en 1C funcionaron bien. Si una respuesta diferente, entonces tenemos un problema a continuación. Aquí no podemos profundizar, lo que salió mal, sino mostrarle inmediatamente al usuario qué error y su descripción. Alguien puede decir que los errores deben procesarse sin la intervención del usuario, pero podemos tener dos situaciones: 1: el servidor devolvió un error. 2 - cursi sin conexión. En el primer caso, es posible que ni siquiera sepamos que algo está roto (por ejemplo, error 404: la aplicación solicitó un método no existente. 500: La plataforma se bloqueó con una excepción). En el segundo, no podemos transferir el resultado para el análisis al servidor. Por lo tanto, mostramos un error y esperamos acciones adicionales del usuario.
La carga útil contendrá diferentes objetos. Esto puede ser una lista de productos, una lista de documentos, una lista de acciones se transmitirá allí. En el lado de la aplicación, los describiremos con modelos y los doblaremos cuidadosamente en la base de datos. Lanzaremos la lista de acciones para la ejecución y agregaremos cuidadosamente los resultados a la base de datos.
El ciclo de intercambio con el TSD será el siguiente:
- La aplicación en comando envía una solicitud a 1C.
- 1C forma una respuesta y devuelve una estructura con el resultado y los datos. En 1C, los registros de información acumulan datos modificados en el contexto de TSD (servicio web).
- A solicitud de la aplicación, se envía una lista de métodos a llamar.
Se eligió dicho esquema porque el TSD se puede apagar, desconectar de la red, etc. Pero nada nos impide finalizar 1C para que, al cambiar los datos, notifiquemos a otra aplicación (servicio web) al respecto. Con este intercambio, informamos que hay nuevos datos. La aplicación pregunta qué datos hay y el ciclo se repite. Un ejemplo de un intercambio se presenta en el diagrama.
Eso es todo Si tiene preguntas, comentarios, sugerencias, por favor escriba en los comentarios.