- The choice of exchange method. API Description.
- API implementation on the 1C side.
- BroadcastReceiver We receive a barcode on the example of ATOL Smart.Lite.
- OnKeyUp. Get a barcode from a scanner with keyboard emulation
- Menu, companion object
- We realize data exchange and storage. We use Retrofit 2, Room, Coroutines.
- User interface. LiveData, PagedList.
For whom
The first two chapters are an attempt to structure the experience of integrating 1C with other applications and web services. The cycle itself, I think, will be interesting to 1C programmers who are trying to go beyond the platform and try something new. Android application developers will not learn anything new for themselves, but maybe they will be interested in how it looks on the 1C side. Starting with the fourth part, there will be an attempt to combine several disparate articles from the Internet on the use of libraries, as well as update data on them. The cycle was conceived as a textbook, which describes the experience in developing a real application. I myself am not an Android developer. But by the end of the series I hope to become one.
2. The choice of exchange method. API Description
In its current form, 1C can be contacted in a thousand and one way. Consider several options, and why I did not use them.
- Native component - For the most part, it's good to use it for offline sharing. For Online, it is poorly adapted. It became even worse when 1C began to implement its standards for exchange with commercial equipment. And also this component is called on the 1C side. It does not suit me.
- WEB Services - More designed for the exchange between applications that develop different teams. Heavyweight, use XML. Personally, it’s very hard for me to develop. And even harder to integrate into JavaScript, Golang, etc. Not suitable.
- HTTP Services - Almost the same as WEB services, but we describe the logic of work and exchange protocols completely ourselves. Here we are not limited to the invention of our own bicycle. For this reason, this particular exchange mechanism was chosen.
The tasks that our application solves. “Everything that can be done on the TSD must be done on the TSD.” Well, as a standard set: acceptance, inventory, labels, price tags.
Complete list of tasks
- Work with goods: Printing labels and price tags, assigning a barcode (barcode), checking the barcode, removing the barcode, viewing prices and quantities in warehouses.
- Inventory - Actually conducting inventories.
- Receipt - Acceptance of goods on the invoice, printing of discrepancies, printing of internal documents, status of the invoice.
- Collection of goods, Realization (Retail) - The idea is that sellers are not at the cash register, but go with the buyer or collect goods upon request, etc. At the checkout there is only one person, with the TSD a ready check is transmitted. The buyer only pays for the goods.
- Collection of goods, Realization (Wholesale) - We collect goods on the account. We check what is available. We form a shipment (with a package of the necessary documents). Do not forget about checking for the possibility of shipment to the counterparty.
- Collection of goods, preparation for shipment - We collect goods on request, put them on a pallet, print documents: packing list, etc.
- Moving - We collect goods for moving, we give in delivery.
- Collection of goods, an arbitrary list - Needed for re-evaluations, updating price tags, labels, and other similar operations.
Back to the API structure. Exchange between TSD and 1C will be in JSON format. In the answer we will have only two objects {result, payload}, respectively: the result and the payload . As a result, we will return two fields {code, msg} . And we will always respond with HTTP code 200. So it will be easier for us on the client side to parse the response structure. All other answers will come as a string. 1C does not allow us to customize answers outside the platform.
Why is it easier to give 200
Most libraries for working with data (including Retrofit), when receiving code other than 200, do not parse the result. And we have to “parse” it with pens.
Now we get the following diagram. If the answer is 200, then our procedures in 1C worked fine. If a different answer, then we have a problem below. Here we can not go deeply, what went wrong, but immediately show the user what error, and its description. Someone may say that errors need to be processed without user intervention, but we can have two situations: 1 - the server returned an error. 2 - corny no connection. In the first case, we may not even know that something has broken (For example, error 404: the application requested a non-existent method. 500: The platform crashed with an exception). In the second, we cannot transfer the result for analysis to the server. Therefore, we show an error, and look forward to further user action.
The payload will contain different objects. This can be a list of goods, a list of documents, a list of actions will be transmitted there. On the application side, we will describe them with models and carefully fold them into the database. We will launch the list of actions for execution, and carefully add the results to the database.
The exchange cycle with the TSD will be as follows:
- The application sends a request to 1C on command.
- 1C forms a response and returns a structure with the result and data. In 1C, information registers accumulate changed data in the context of TSD (web service).
- Upon request from the application, a list of methods to be called is sent.
Such a scheme was chosen because the TSD can be turned off, off the network, etc. But nothing prevents us from finalizing 1C so that when changing data, notify another application (web service) about it. With this exchange, we inform that there is new data. The application asks what data is there, and the loop repeats. An example of an exchange is presented in the diagram.
That's all. If you have questions, comments, suggestions, please write in the comments.