5. Development
This page will summarize how to modify enioka Scan, whether it is to contribute to the project or for your own needs.
5.1. Developing for Android
In order to start developing and testing the library:
Have Android Studio installed and open the project with it
Connect a compatible android device via USB, it should then show up in Android Studio’s device manager
Run the demo app with the android device selected. The app includes the library and all available providers
In case the android device is not detected by Android Studio:
Make sure the device is in developer mode and has USB Debugging enabled
Make sure the USB cable supports data transfer (some cables only support charging)
5.2. Adding to the ReadTheDocs documentation
To test documentation changes locally, you need to install Sphinx and other dependencies. Using
python 3, you can run pip install -r ./docs/requirements.txt
in your virtual environment.
In order to build the documentation, run sphinx-build -a ./docs <build-dir>
.
To view the generated documentation, use the url file://<build-dir>/index.html
in your web
browser.
All documentation is written in markdown. Due to the lack of proper java support, the API reference
was “hacked” using default method
directives for functions, and cpp:var
or cpp:enum
directives
for attributes and enums respectively.
Note that anchor links to methods and members are not well supported, so in general it is better to link to the parent class or interface rather than the method or attribute itself.
5.3. Adding another SDK / Scanner provider
A scanner SDK contains at least a Scanner
implementation
(interfacing between the code and the device) and a
ScannerProvider
implementation (handling
scanner creation and device compatibility checks).
In order for a new scanner SDK to be found by the library, the
ScannerProvider
implementation implementation
needs to be declared as a service in its AndroidManifest.xml
, with an intent-filter containing the
action com.enioka.scan.PROVIDE_SCANNER
for “regular” devices, and
com.enioka.scan.PROVIDE_SPP_SCANNER
for bluetooth devices.
The associated Java class does not need to extend Android’s Service
class(the
tools:ignore="Instantiatable"
attribute may be added to the service in the manifest),
but it must provide a public default constructor as it will be instantiated using Class.getName()
.
See also
The
Scanner
interface documentationThe
ScannerProvider
interface documentationThe sources of various scanner providers on the GitHub repository, mainly the Mock SDK
5.4. Library tests
While not every aspect of the code may be easily tested, some parts can and should be. For example, parsers and translation methods used to convert enioka Scan API methods to device-specific commands should be unit-tested to ensure payloads are properly handled.
The repository contains GitHub Action pipelines to build the library and launch both JUnit and Android Instrumented tests for both Android API levels 19 (the minimum supported version) and 28 (the target version).
5.5. Release process
Once enough features or fixes are merged into master
, a new version tag will be pushed by a
repository owner/maintainer. This will trigger a GitHub Action workflow to create a release with an
artefact of the core library, and will upload all artefacts to Maven Central.
Every tagged commit should include an increment to demoscannerapp/build.gradle
’s versionCode
value, even if the previous release was canceled. The Google Play Store console will not accept
the re-publishing of an existing versionCode
value, and fixing a denied version code will require
the re-push of the release. The versionName
value should just match the tag, and multiple releases
can have the same versionName
.
Warning
The release tag must be pushed from the CLI, as a tag or release created from the GitHub web UI will fail to trigger the workflow.