So, hello everyone.
My name is Antoine Gonzales.
I am a French developer at Enoca Outculture and today I'm going to talk to you about bar
code scanners and bar codes in general and why they are important in the open source.
So, a bit of context.
Bar codes, why does it matter?
If you probably have noticed that everything in your daily life has bar codes attached
to them, whether it's grocery shopping, parcels that you order online, even menus in restaurants
these days have bar codes attached to them.
The idea behind this is basically bar codes end up being one of the most efficient way
to attach digital data, usually an idea, but sometimes more than this, to physical objects.
It has many different types, one dimensional and two dimensional ones.
The one you're most likely familiar with is EAN 13, which is pretty much on every package
ever and QR codes, which is mostly used to share links and stuff like that.
So, as I said, they're used everywhere, but depending on workflows you may have more or
less requirements with them.
Usually, for example, if you deal with large scale packaging or inventory keeping, maybe
you need to scan lots of them very quickly.
So, some workflows have specific requirements and require dedicated devices, which is what
bar code scanners are.
And bar code scanners, so the less wonderful side of it, there's a wide variety of them,
some small, some big, some that look like phone and that mostly are phones, some that
look like rings that fit on top of your finger and you can use to scan products.
There's a wide variety of them and a wide variety of manufacturers for them, and that
comes with this problem.
For example, each manufacturer tends to have their own APIs, SDKs, their own licenses that
are very usually not open source friendly.
Documentation that can be more or less complete depending on who makes them.
And obviously, most of the time, it's not proprietary, otherwise it would not be here.
It's proprietary.
So what it means is usually when you pick a manufacturer for your backup scanners, you
end up sticking to it because changing or just adding more variety to your fleet means
having to rewrite your entire application.
And for a lot of companies, it's just a lot of time to invest and not profitable in the
end.
So what is EnoCastCan then?
It's an Android library with the goal of exposing a single common API to interact with different
scanners.
So how it does it?
So the goal behind it is that it allows you to pick the manufacturers and the scanners
that you need for your needs.
That may mean combining different manufacturers because you have multiple needs in your company
or just changing when the current contract does not fit your needs anymore without having
to rewrite everything.
And how does it enable this?
So obviously, there's no magic.
If every manufacturer and every device requires a specific way to communicate with them, a
specific code needs to exist at some point.
That's in the library.
The idea is every device exposes their own API and we implement a communication way,
a way of communicating with that device in the library, either through official documentation
when possible or if we don't have access to it through reverse engineering, the protocols
used by the scanner.
Once we have that communication set up, what we can do is provide an abstraction layer
that the end user can use to, for example, send very high-level commands to the scanner,
for example, start reading barcode, turn on illumination, something like this.
In the library, we'll find the connected scanners and try to translate to the appropriate protocols
behind.
What's interesting about this approach is it makes it very expandable.
This means, for example, if we don't support any given device but we want to add support
later, it's pretty simple to do.
It's about implementing one interface or another.
We describe what the device can do, how do we do it, how do we translate to something
that the device can understand.
If the device has specific features that may not be common on most scanners, we can divide
these commended subgroups that are very easy to implement or not in a way that makes it
obvious what the device can do.
For the end user, nothing changes.
The whole point of the library, the application that chooses the library doesn't need to adapt
anything.
It's the library itself that's plug-and-play.
In terms of compatibility, so far we support quite a wide range of scanners.
Some of them use Bluetooth, classical low-energy.
Some of them are integrated.
This means, for example, a smartphone with a scanning camera on top of it.
For some situations, the Android camera is all you need, so the smartphone's camera,
in which case we support both the legacy camera API and the new camera 2 API.
One of the biggest upgrade we made recently last year was the compatibility with the Zebra
data-wage.
Zebra is one of the main manufacturers in the back-off scanner industry.
Data-wage is their proprietary service that communicates with most of the fleets of integrated
scanners.
I think this one, for example, allowed us to pretty much support everything these manufacturer
produces.
Any device that's not in the list, whether it uses the existing supported technologies
or something else, for example, USB, if Android lets you access this way of communication,
theoretically, nothing stops you from adding compatibility.
It may just require a bit more boilerplate to get working the first time.
But overall, we have a lot of already set of helpers to make the process easier.
What comes next for this library?
So like I said, we have a lot of scanners that are supported already, but obviously not
all of them can be.
There's a lot of devices out there, so more and more devices are going to be added as
we get all of them.
We also want to provide an external documentation containing guides and examples for the code.
So right now we have pretty complete API dots, but not a lot of guides and quick starts for
people who want to judge before starting implementing it whether or not this library is in the
list, what they expect and what they want for the need.
We also want to provide a more complete separation of the core library and the existing SDKs
that are implemented to let you just download what you need and not support dozens of devices
you might not use.
Another thing we want to add is a standalone app, so both an application and a service
published to the Android Play Store.
So in case the defaults, functionalities of the library is all you need, you already
have access to it and you might not want to reimplement everything in your application.
And finally, better Bluetooth support.
So we already support Bluetooth pretty well, but a lot of devices have specific methods
of pairing with your Android phone.
Sometimes they require pairing via scanning a barcode that's generated by the device.
This is through NFC pairing, which we do not support right now, but we want to in the
future and Android support for the activities like camera that we provide.
Now what we need help with, because obviously, like I said, we do not have access to every
device.
It's not possible.
There's too many of them, but maybe you do.
Maybe you have access to barcode scanners that we haven't tested yet, in which case you
probably can help us to expand this library.
So for example, by just simply testing whether or not the device you have is supported or
not by the library.
Sometimes even if it's not explicitly tested, manufacturers do reuse some of their code and
some of their protocols, in which case maybe a device that we haven't tested does work
with the library.
Or if not, we know we need some work on it.
You can also add easily more SDKs to make more devices compatible.
So for example, if you have a device that we do not support and that's not compatible
with the library, you can try to either reverse engineer it or provide the documentation
necessary so we can add its functionalities to it.
And finally, if you see any feature that you think is missing that could be done better,
or optimized maybe, you can try your hand at upgrading the code base, basically.
We try to be reactive with issues and questions that we receive.
So if you want to take a look at it, there's a barcode to the GitHub repository.
So if anyone has any questions, I can answer some of them.
And otherwise, if you want to stop in the hallways or open discussions on GitHub, you're
welcome to do.
Thank you very much, Paul Singh.
We have one question.
Hi.
Can I ask, are you planning on supporting any other platforms because a worrying amount
of POS software still runs on Windows XP with serial?
So Android is like right now it's only an Android library, mainly because in the mechanisms
we use to connect to the different scanners are specific to Android.
But the core compatibility layer, basically, with each device is not specific to Android.
So even if connecting to a scanner uses Android, you could probably take the code base used
to translate messages and port it to Windows or Mac or whatever else.
Anyone else?
Okay.
Well, thank you very much, Antoine.
That was great.
Thank you very much.
And...
APPLAUSE