- Le choix de la méthode d'échange. Description de l'API.
- Implémentation de l'API du côté 1C.
- BroadcastReceiver Nous recevons un code-barres sur l'exemple d'ATOL Smart.Lite.
- OnKeyUp. Obtenez un code-barres à partir d'un scanner avec émulation de clavier
- Menu, objet compagnon
- Nous réalisons l'échange et le stockage de données. Nous utilisons Retrofit 2, Room, Coroutines.
- Interface utilisateur LiveData, PagedList.
Pour qui
Les deux premiers chapitres sont une tentative de structurer l'expérience d'intégration de 1C avec d'autres applications et services Web. Le cycle lui-même, je pense, sera intéressant pour les programmeurs 1C qui essaient d'aller au-delà de la plate-forme et d'essayer quelque chose de nouveau. Les développeurs d'applications Android n'apprendront rien de nouveau pour eux-mêmes, mais ils seront peut-être intéressés par l'apparence du côté 1C. À partir de la quatrième partie, il y aura une tentative de combiner plusieurs articles éparpillés sur Internet sur l'utilisation des bibliothèques, ainsi que de mettre à jour les données à leur sujet. Le cycle a été conçu comme un manuel, qui décrit l'expérience de développement d'une application réelle. Je ne suis pas moi-même développeur Android. Mais à la fin de la série, j'espère en devenir un.
2. Le choix de la méthode d'échange. Description de l'API
Dans sa forme actuelle, 1C peut être contacté de mille et une façons. Considérez plusieurs options et pourquoi je ne les ai pas utilisées.
- Composant natif - Pour la plupart, il est bon de l'utiliser pour le partage hors ligne. Pour Online, il est mal adapté. La situation s'est encore aggravée lorsque 1C a commencé à appliquer ses normes d'échange avec des équipements commerciaux. Et aussi ce composant est appelé du côté 1C. Ça ne me convient pas.
- Services WEB - Plus conçus pour l'échange entre des applications qui développent différentes équipes. Heavyweight, utilisez XML. Personnellement, c'est très difficile pour moi de me développer. Et encore plus difficile à intégrer dans JavaScript, Golang, etc. Ne convient pas.
- Services HTTP - Presque les mêmes que les services WEB, mais nous décrivons nous-mêmes la logique du travail et les protocoles d'échange. Ici, nous ne sommes pas limités à l'invention de notre propre vélo. Pour cette raison, ce mécanisme d'échange particulier a été choisi.
Les tâches que notre application résout. "Tout ce qui peut être fait sur le TSD doit être fait sur le TSD." Eh bien, comme un ensemble standard: acceptation, inventaire, étiquettes, étiquettes de prix.
Liste complète des tâches- Travailler avec des marchandises: imprimer des étiquettes et des étiquettes de prix, attribuer un code-barres (code-barres), vérifier le code-barres, supprimer le code-barres, afficher les prix et les quantités dans les entrepôts.
- Inventaire - Effectue actuellement des inventaires.
- Réception - Acceptation des marchandises sur la facture, impression des écarts, impression des documents internes, état de la facture.
- Collecte des marchandises, réalisation (vente au détail) - L'idée est que les vendeurs ne sont pas à la caisse enregistreuse, mais vont avec l'acheteur ou récupèrent les marchandises sur demande, etc. Il n'y a qu'une seule personne à la caisse, un chèque prêt est transmis par le TSD. L'acheteur ne paie que les marchandises.
- Collecte des marchandises, réalisation (gros) - Nous collectons les marchandises sur le compte. Nous vérifions ce qui est disponible. Nous formons un envoi (avec un paquet des documents nécessaires). N'oubliez pas de vérifier la possibilité d'expédition à la contrepartie.
- Collecte des marchandises, préparation de l'expédition - Nous collectons les marchandises sur demande, les mettons sur une palette, imprimons les documents: liste de colisage, etc.
- Déménagement - Nous collectons des marchandises pour le déménagement, nous livrons en livraison.
- Collecte des marchandises, une liste arbitraire - Nécessaire pour les réévaluations, la mise à jour des étiquettes de prix, des étiquettes et d'autres opérations similaires.
Retour à la structure de l'API. L'échange entre TSD et 1C sera au format JSON. Dans la réponse, nous n'aurons que deux objets
{result, payload}, respectivement: le
résultat et la
charge utile . En conséquence, nous retournerons deux champs
{code, msg} . Et nous répondrons toujours avec le code HTTP 200. Il sera donc plus facile pour nous côté client d'analyser la structure de réponse. Toutes les autres réponses viendront sous forme de chaîne. 1C ne nous permet pas de personnaliser les réponses en dehors de la plateforme.
Pourquoi il est plus facile de donner 200La plupart des bibliothèques pour travailler avec des données (y compris Retrofit), lors de la réception de code autre que 200, n'analysent pas le résultat. Et nous devons «l'analyser» avec des stylos.
Nous obtenons maintenant le diagramme suivant. Si la réponse est 200, alors nos procédures en 1C ont bien fonctionné. Si une réponse différente, nous avons un problème ci-dessous. Ici, nous ne pouvons pas aller en profondeur, ce qui a mal tourné, mais montrer immédiatement à l'utilisateur quelle erreur et sa description. Quelqu'un peut dire que les erreurs doivent être traitées sans intervention de l'utilisateur, mais nous pouvons avoir deux situations: 1 - le serveur a renvoyé une erreur. 2 - ringard pas de connexion. Dans le premier cas, nous ne savons peut-être même pas que quelque chose est cassé (Par exemple, erreur 404: l'application a demandé une méthode inexistante. 500: La plate-forme s'est bloquée avec une exception). Dans le second, nous ne pouvons pas transférer le résultat pour analyse au serveur. Par conséquent, nous affichons une erreur et attendons avec impatience d'autres actions de l'utilisateur.
La charge utile contiendra différents objets. Cela peut être une liste de biens, une liste de documents, une liste d'actions y sera transmise. Côté application, nous allons les décrire avec des modèles et les replier soigneusement dans la base de données. Nous lancerons la liste des actions à exécuter et ajouterons soigneusement les résultats à la base de données.
Le cycle d'échange avec le TSD sera le suivant:
- L'application sur commande envoie une requête à 1C.
- 1C forme une réponse et renvoie une structure avec le résultat et les données. En 1C, les registres d'informations accumulent les données modifiées dans le cadre du TSD (service web).
- A la demande de l'application, une liste des méthodes à appeler est envoyée.
Un tel schéma a été choisi car le TSD peut être éteint, déconnecté du réseau, etc. Mais rien ne nous empêche de finaliser 1C de sorte que lors de la modification des données, avisez-en une autre application (service Web). Avec cet échange, nous informons qu'il y a de nouvelles données. L'application demande quelles données sont présentes et la boucle se répète. Un exemple d'échange est présenté dans le schéma.
C’est tout. Si vous avez des questions, commentaires, suggestions, veuillez écrire dans les commentaires.