Closed anonkwe closed 1 year ago
@anonkwe this would be a new feature, currently we only support barcode scanning via the native camera. Is the Zebra camera connected to the device via USB?
@SchrodingersGat those are zebra mc3300x and mc9300x. they don't have native cameras, only scanners.
Oh right, so the app actually runs on the scanner device?
@SchrodingersGat yes, those are zebra android mobile computers..
I see - this is a much different use case to using the internal camera. I do not know anything about what API is offered by the scanner.
If you are able to provide information about the API / SDK available from zebra, that would be helpful. The InvenTree app is written in flutter, so would need to be compatible with that development framework.
@SchrodingersGat https://github.com/zebra-technologies/Scanner-SDK-for-Android would this be helpful?
here is the direct download link from zebra
This looks like an article from zebra that describes how to use the zebra sdk with flutter.
Thanks for the links!
@anonkwe I don't have a way of testing this (unless you want to ship me a scanner) - are you able to build and test code yourself?
@SchrodingersGat I wish I could send you one, those are demos that were sent to me in order to test it prior buying... As for building and testing, I think I'm pretty limited but I have some knowledge.
But if you can tell me what are the actions and intents when scanning with the mobile app, perhaps we can simulate it with the datawedge reader. https://docs.retool.com/docs/retool-mobile-zebra
@SchrodingersGat I'll have a developer working on it with me, is there a way to have access to what's required
Everything you need for a dev setup should be in the repo - is there something you are missing?
Yep @anonkwe if you have a local developer, use them for implementation and testing, and submit a PR back. I'm happy to help out with overall design / implementation suggestions but I have no way of testing locally.
Happy to consult with your developer on the implementation side.
Hey guys, new to this project, but I'm really impressed by InvenTree so far. I can help with this feature, as I'd also like native barcode scanning to work. I can also send someone a gun if they are interested in prototyping with it.
@alaskancode are you also using the zebra scanners?
I have a few different models. I do have a couple spare Zebras around. All run some flavor of Android. I think ideally we would architect this so that it can work with a variety of different types of guns. TBH...most of my previous work has been with Motorola/Zebra MC9200 guns/Windows Mobile, so I'm not as familiar with the barcode scanning SDKs on Android. But we can figure all that out in testing.
The Inventree Android app looks nice to me so far, and I think it shouldn't be too hard to implement this feature. Barcode scanning with a gun is usually pretty similar to just taking keyboard input.
@anonkwe or @alaskancode do either of you want to work on developing this? I'm happy to assist / guide
@SchrodingersGat as we speak, I am checking it with a developper and if needed, I'll stay in touch for sure, Thanks a lot!
@SchrodingersGat @alaskancode I found some good flutter plugin that I tested and worked. it comes with an example app and it is working great. I think I would need help for the rest (create the widget besides the one for qr_code_scanner and make it act like qr_code_scanner once it's scanned. See attached screenshot of the example app:
here is the github repo of the flutter datawedge examble app (it's updated regurlaly and compatible with lots of devices): https://github.com/circus-kitchens/flutter_datawedge
here's a github repo straight from zebra devs: https://github.com/ZebraDevs/DataWedge-Flutter-Demo
I really don't think it would be very long to get this done and I bet lots of users would start to get interested to this solution that i find pretty awesome so far.
for now, I can use the barcode scanner through keystroke output on the app with the search icon but it won't format the qr code properly. how how is it formatting the qrcode output and how is it acting to reach it after scanning on the app?
how does the actual qr_code_scanner work after scanning? is it through intents? maybe i can set it up in zebra datawedge app if you guys could help me!
here is a screenshot of the actual output when i use the barcode scanner
@anonkwe Yes this is the right direction. There are lots of ways to configure scanners to modify input, but most "out of the box" models will just send you the plain text content of the barcode. If you want to post an image of the QR code you are using, I can confirm that the data in the QR code is what is showing up in the Datawedge output or not. It looks like it's just encoding a JSON object in string form, which wouldn't surprise me.
We will have to create a new code path that decides whether to use the built in camera or a native scanner. This should probably be configured somewhere in the app, and if you are using a hardware scanner then the app no longer loads the camera based scanner library, but instead waits for input from the scanner device.
If you are using the scanner in a way that emulates keyboard input, sometimes you will want to configure the scanner with a stop character or string so that the app knows when input has come from the scanner (versus regular keyboard input).
Keep in mind that not all barcode scanners are Zebra scanners. There are advantages to using native libraries (like Zebra EMDK) since you can get tigher integrration and less setup has to be done on the device to make the app work out of the box. However, the trade off is that you may preclude using other types of scanners (Honeywell, Unitech, etc).
For that reason, maybe we can have a three pronged approach: 1) Native camera scanning (current method) 2) Generic Barcode scanning method (may require some config at Android OS level to make scanner play nice with app - i.e. stop characters/digits) - prob want a config option for stop character in Inventree app so it knows when to end scanner input 3) Native SDK integrations - like Zebra EMDK - maybe we start with Zebra, but then have a model flexible enough to allow for new SDKs to be added easily with other Android-based scanning devices from non-Zebra manufacturers
@anonkwe looks like you are getting exactly the right data from the barcode. Native InvenTree barcodes are just stringified JSON objects.
@alaskancode I like your suggestion about levels of support for various scanners. Users would have to specify (via an in-app setting) which approach to use.
For 3) - is the thinking here that this would be via an external device connected to the mobile device via bluetooth or similar?
In terms of integration, most of the barcode stuff is currently handled in barcode.md - here we could write a shim layer which passes and calls to scan off to the selected interface.
@alaskancode Sorry I was out of office for the weekend. here is the labels we are using
I 100% agree with you and am willing to develop the whole thing asap with anyone. However, due to the lack of time in my hand (we have demos mc9300 for a very limited time from our provider), I would like to know if there is any way we can get this to work through datawedge and emdk prior developing it. Perhaps i can provide you my exported datawedges profiles. I don't know if it would be possible to have this done (kind of a native camera emulation or something like that).
Concerning the devleopment of what we wanna accomplish (scanner or camera selection through the app), we plan on purchasing tc52's from Zebra, which do have both native camera and barcode scanner, a good device to do some QA testing for what we wanna do.
But to move forward, I do need to find a way to make it work through datawedge or emdk at first. What would you suggest?
Here is the link to the flutter datawedge profile: https://drive.google.com/file/d/1QL4c1ZvMBa5t7SBM0NPQDzOMMk2MB8e9/view?usp=sharing
Yes that code is just a JSON Object with an id pointer to the record in Inventree that is being referenced. This is best practice if the data on the barcode can be updated, since the pointer allows you to maintain referential integrity without storing data that may change in the future. However, if the intention is to eventually have a mobile app that can function offline as well (i.e. lazy synchronization), then sometimes it makes sense to encode additional information into the barcode also (part number, lot number, etc), so that the user can verify they are working with the correct item without needing network.
With regards to the "generic scanning" option, keep in mind that not every barcode scanner is a mobile computer. Some people may buy a $10 USB barcode scanner connected to a computer or mobile device, that has almost no intermediate configuration capability. With a full mobile computer/barcode scanner, there is almost always an option to modify the input in an intermediate way to provide exactly what the software is looking for, even if it isn't in the format expected by the software. But with the cheapo $10 unit, perhaps the input it sends to the device is indistinguishable from a person typing on a keyboard. In that case, you want some ability for the software to deal with this and handle the input correctly, so that keyboad input is not mistaken for scanner input, or vice versa. So this option would probably come with some configuration inside the app to account for the dumb nature of the scanner. So this is the use case for the "generic scanner" option.
With respect to making it work immediately with a datawedge...in the past I have mostly used datawedge software for testing (seeing immediate output from the scanner). I know that there are fancier use cases...i.e. also as an intermediate piece of software to certain applications, to set scanner symbologies, etc... but I don't have a ton of experience with this. I think datawedge is an alternative way to get input into certain applications without the need for EMDK. With EMDK...you are modifying the software itself to expect data input straight from the Zebra library/API, which leads to a tighter integration into the software.
The fundamental issue you have right now is that whatever option you choose, the current camera-based scanner is getting in your way. Anywhere the app can take input, that doesn't require loading the camera to scan, should basically work out of the box with a barcode scanner. The scanner is going to send the text to the input field the same way as a keyboard would. However, you will have to complete the action using the regular keyboard most likely, unless you program the scanner to take additional actions after scanning (i.e. hit Return key).
However, what makes barcode applications really fly is that ability to wait for input at certain steps in the application, validate that input from the barcode scan, and then take some action based on the scan. This type of functionality is currently tied to the camera scanner, so it is in competition with any hardware scanning solution. So that's the problem this thread is meant to solve. The answer to your question is you could probably do some things with a barcode scanner today, but to really make a killer app with a barcode scanning device we will need to make the changes discussed in this thread.
Implementing every possible solution without a number of known users is probably a waste of time. It makes more sense to just implement what is really requested right now and will have an immediate user base. We can worry about the rest once interested users show up and start contributing the features.
I don't think the idea would be to implement every possible solution right now. But understand that the current architecture is getting in the way of implementing direct barcode scanning from a gun. So it is useful to think about the different code paths that one might take in the future, so that you don't build something today that will have to be rewritten again in the future. The idea is to architect the solution in such a way that different use cases can easily be accommodated in the future without a massive rewrite.
Do you mean by this breaking change the content of the QR code?
@matmair You might quite not know how big of a deal are those devices in manufactures and plenty other industries requiring stock tracking gloablly. You have to work daily in such environments to see how barcode scanning is the most important feature/criteria that factories, manufactures, wholesale, are seeking when it comes the time to implement inventroy management solutions working with companion apps for stock tracking on the field. Those devices, whether they are Zebra, HoneyWell or any other are used by millions in every kind of industry there is out there , so we might not know the exact number of interested users, but it's surely a lot.
To be honest, if I scroll the threads of inventree-app, I'm not sure if I can see what you mean by "what is really requested by direct users". I can also see someone requesting similar stuff on the main inventree GH: https://github.com/inventree/InvenTree/issues/4608
I personnally don't see how making barcode scanners and datawedge profiles work with a companion android/ios app such as this one can be perceived as a waste of time. To be honest, If I scroll down, I do not see so much feature we trying to get to work with the mobile app. The reality is that a camera scanner is limited only for some short ranged stuff and it cuts the app's potential by so much.
This is not "any possible solution" that we try and want to implement, it might be one of the most desired features peope are looking for. This would certainly make the immediate user base number pop up.
Aren't we interested users showing up to contribute to this feature and make an app better?
Not the first feature/idea I personnally am putting on the table over the last 4- 6 months and unfortunately, more often than not, the only feedback coming from you was similar to this undermining, almost condescendent comment you just pulled up with. I don't see the point of it since we are trying to contribute.
I think we are talking about different things here. I do not see many requests for support for 10$ cheap scanners @alaskancode was talking about. Fetching keyboard input with special characters has been attempted on the main project and has proven to be difficult. The issue you linked is for the webapp, not the app. Very different stack.
We have multiple integrated honeywell scanners in production. Integrating them into the app was a thing of not a full workday. That makes sense - some over-generalised solution that enables any kind of scanner ( ie no SDKs) is work to maintain.
I do not see you actually maintaining or contributing anything to the ecosystem but feel free to surprise me.
This is just a discussion to try to figure out the correct path forward.
Do you mean by this breaking change the content of the QR code?
No this has nothing to do with the QR code really. I just was commenting that adding some additional data to the QR code could be desirable for offline use cases. Depending on how the QR code/JSON object has been parsed in code, it may or may not be breaking. However, it would be a good idea to perhaps add a version identifier into the JSON, so that you can support future objects formats while maintaining backwards compatibility.
@anonkwe to clarify where you are up to:
I think the best way forward here is to start a branch with the desired features and we can provide support based on the code.
@SchrodingersGat which screenshot are you refering to? if it is the fluter datawedge plugin, the device is a zebra mc930b on android 11 yes I did compile the app that reads flutter dataweddge, but what's remaining is to copycat qr_code_data to it's listener after that does what it has to do with inventree after that for it to work like a native camera, see attached example plugin: https://pub.dev/packages/zebra_datawedge
here's the 930b build:
As for compiling the app, I'm having a very hard time to do so as we speak, I'm not able to integrate datawedge fluter plugin. In fact, I'm not even able to compile it at all, I encounter many problems with locales and other stuff in the app. I'm very green with android development, I was wondering if you could perhaps provide me with some kind of export of a working environment of android studio or anything else like that, so I can start and give it a shot?
@matmair you mean you fully integrated honeywell handeld android scanners to the mobile app? Let me know what model number of handeld computer and if you could share you data processing settings that would be great.
Integrating zebra datawedge would not be harder than honeywell's. so if you could share you data process, we'll surely have clues.
There are many different ways of contributing to projects, for example coming up with ideas, reporting bugs or malfunctions. Might not be pushing my local code but yes I do see myself contributing to this project in some shape or form. didn't I contribuated a bit with currencies, decimal_places bug, total line values, zebra printer plugin bugs ?
Not here to argue or prove myself tho, no need for that. I'm just an humble sysadmin trying to implement your project to it's work environment and spread it cause it works like a charm. so if you have by any chance 2 mins to provide me those honeywell infos, feel free to suprise me as well, It's surely appreciated..
@anonkwe please see the comments in https://github.com/inventree/inventree-app/issues/356 regarding setup.
Project setup is pretty annoying, I've been mostly doing all the dev myself so we might need to improve the process / documentation
@anonkwe yes. Honeywell has a pretty simple SDK available (and an unofficial flutter wrapper but we did not use that). The used scanners are generally from the EDA5x/EDA7x line, most are old EDA71s.
I don't understand what you mean by data process. You just initialize the SDK with the codes you want to support, wait for the device to be operational and then pass it callbacks for code decodetation or error events.
@anonkwe when you get your branch working please throw the PR up here so I can work alongside you on this
@SchrodingersGat what do you mean by throw the pr up? pull request? sorry for my lack of knowledge again man. my branch should be working now
Yes, pr means pull request in short. This term is maybe also known as merge request (from gitlab). Go to the upstream repo (the repo from InvenTree, where you clicked fork). Then select the pull request tab and there should be a little message that shows your that you have some changes in your local fork. Click create pull request and fill in the details.
@matmair just received an honeywell ct30 & another ct45, those running android 11, could you elaborate on how you guys made it work with the app?
Honeywell should have provided you with access to their dev portal, there is a section with sample code there for the Android SDK. You can add a button or view that activates the scanner and then pass the scanned text to the processing function: https://github.com/inventree/inventree-app/blob/973f1fb0021c2b7345ad6a1d72778199fd948d84/lib/barcode.dart#LL92C25-L92C25
@matmair do you have a screenshot of your working setup like code or something
I am not able to share that code base. If I was it would already be upstreamed
@matmair how much? lol
I appreciate the idea. I have no rights to the code base and I am not able to accept any form of compensation in this area of business. Maybe @SchrodingersGat is interested in developing something.
@SchrodingersGat is there an email or another way to reach out to you, I would like to make you an offer in order to get this done
@anonkwe support@inventree.org
@SchrodingersGat email's sent! Check it out whenver you got 5 mins!
Closing this one out - any further development covered in https://github.com/inventree/inventree-app/issues/364
Hi, We are using Android Zebra MC scanners, which don't have cameras, but only scanners. Inventree mobile app seems to only support barcode scanning with cameras. Is there anything to do in order to make the scanners work (via datawedges and intents) or is it a new feature that is needed?