Recently the technical committee had its first presentation on mobile strategy . We walked through the requirements and key considerations and our next step was to collectively discuss, technically, the OpenLMIS Reference Mobile Application. This is the start of that discussion thread and it’ll be made sticky at the top of the dev forum.
After our discussion I took a stab at re-organizing the requirements and bucketing them into deliverables. Doing this is my first pass at an iterative approach at answering two prominent questions that were raised about Requirements:
Q: Are we also delivering a library for use in other mobile applications?
- For instance an OpenLMIS GS1 capable stock management library that can ship along side and/or inside a care delivery app - e.g. stock takes and shots in the arm data combining to reduce the data entry burden and raise the data quality aspect through automation.
Q: What do we mean by "Supports collection of routine LMIS data across multiple programs (i.e. 10-20 data points for 100+ commodities)”?
- Which has been removed, and temporarily replaced with an oppinionated view of Stock Based Requisitions, physical inventory and a requirement for " Work with (interop tbd) Program Data capture application to visualize programmatic data capture requirement as part of regular period requisition”.
The two questions aren’t answered, not directly, and I propose that we expand upon our requirements and our assumptions to iterate and answer those questions.
Next, in the Key Points for Consideration section I’d like to highlight two considerations that impact choice of technologies in the short-term:
- Under Sustainable Maintenance: Community/organizational tech stack knowledge: current OpenLMIS community is focused on Java and
Angular v1, less so on Android and Mobile.
- In a greenfield Mobile Reference app, we have our choice of languages, frameworks, development environments and so on and that’s exciting.
- The community will not only have to maintain the current 23k LOC in the web UI as well as new LOC for a mobile UI, but we’ll also continue to invest in the web UI: if we implement barcoding we’ll have stakeholders that will want it in the web UI as well as the mobile app.
- This quickly leads to the conversation of code-reuse - which in my experience is not without considerable complexity if the runtime contexts are different enough (e.g. the web and mobile code expect different levels of network connectivity, available hardware, etc).
- The Support Re-use section highlights two broad topics:
- The product model (aka Product Master) needed to understand what’s in stock and what you’re supposed to have in stock (as well as related questions) is complex and standards (GS1 primarily) driven. Once we develop it for a mobile app, we really don’t want to have to re-develop it.
- Barcoding should be on our radar - both reading them and printing them. We’ll need to access the device’s camera at the very least, and potentially interface with other hardware to either read the barcode (e.g. RFID of BLE) or print barcodes for shipment labelling. As we choose our technology for the app, we should be cognizant of the technology of different barcode libraries we might leverage:
- Open source barcodes (Java and Android): https://github.com/zxing/zxing
- COTS but claims to work on the web and on Android: https://www.scandit.com/products/barcode-scanner/details/
- Anyone know / recommend libraries for: label printers for barcodes, RFID / BLE?
I think that’s enough to start the larger discussion - lets try to use this thread to bring to light the open questions and point out some of the cross-cutting concerns - an initial list has started to form in mobile strategy. Also there is a Slack channel you may join for quick brainstorming: #mobile