Note: To my current knowledge, most Boox devices use a single API to unify the way the screen updates, so because of that, I will treat this suggestion like a software problem that can be implemented for all Boox devices, not just the Note Series.
Disclaimer: I am a developer, but I am not super familiar with the specifics of the Scribble, TouchHelper, and Pen APIs listed under Onyx Intl’s Github. I have not written my own port with them yet, so most of my information is based off of reading the docs. So, this means that while I am basing this idea off of something, it could easily be that my understanding is flawed at this time.
The Problem: Honestly, the boox devices’ embrace of Android and its ecosystem is such a smart move in the face of Amazon’s closed nature of their kindle devices. There are tons of ebook-aimed apps, and there’s no shortage of ways to read on any boox device. However, the only thing standing in the way of making this device legendary is the fact that the same openness for 3rd party note-taking apps is hindered by the fact that the 3rd party apps would require the developers to add support for this tablet, an occurance that is unlikely for big-name apps like OneNote.
The Solution: If possible, I would love to see a “Note Mode” section in the app optimization menu. Basically, this would “simulate” the currently-supported method of updating the screen, but instead of requiring the app developer to provide the API with the information needed to update the screen, the user could do that with the items in this Note Mode section. Basically, the options it’d have are:
- Toggle to enable “notes mode” in the app in question
- Some UI element that controls for stroke width, style, and color.
- A UI element that customizes the way eraser-marks should be rendered. It should allow the user to specify if the app itself should handle it, or if it’s OK for the API to render (for example) paint a custom-colored/patterned line on the canvas to signify the path of the eraser just before things are erased.
- A UI element that customizes the way the lasso tool should be rendered. Like the eraser, it should be a choice between the app handling everything (so basically, no lasso tool in the eyes of the API), or if the lasso tool should also have its own custom colored/patterned line that should be drawn by the API.
- An optional “in-app floating toolbar” to display when “notes mode” is enabled. This would give the user the ability to change the rendering of stroke style, color, and width while the app is running.
- An option to have the toolbar be hidden unless the pen’s side button is pressed.
Once “notes mode” is on and the elements are properly configured, the app is good to go! The app should render normally until the digitizer is within hover-distance to the screen (or when indicated by input from the floating button). Then, the app’s rendering is “frozen”, and the Pen/TouchHelper API is called to properly render the pen and eraser’s strokes. While the app’s rendering is “frozen”, the app is actually still running, so when the pen gets pulled away and the changes need to be made permanent, everything that the Pen/TouchHelper API rendered should be erased, and the rendering of the app should be restored.
If this happens quickly enough, the experience will probably be kinda wonky, because of the potential differences in rendering systems between the 3rd party app and the Pen/TouchHelper API. It’ll look like you’re using the notes app when you draw, but then the image will snap into whatever the 3rd party app had in mind when it processed the input. However, it will still provide a solution that is responsive enough to allow 3rd party note apps to be usable, which would make it worth the wonkyness in my book.
The Implementation: Because this is such a far-out idea, I’ll provide some intuition regarding how I might go about doing this. To implement this, I’d probably use the Pen/TouchHelper API instead of the Scribble API, Below, there’s a quoted section[1] from the docs. Given this information, the biggest issues for implementation are the as follows:
- Figuring out what the
RawInputCallbackobject should do, so we can pass it toTouchHelper.create(...). - Figuring out what stroke width to give to
touchHelper.setStrokeWidth(...), and what stroke style to give totouchHelper.setStrokeStyle(...).
The 2nd issue is actually solved by the 2nd, 5th, and 6th options provided in the optimization menu. If we assume that data is provided freely by the user, this immediately becomes a non-issue, becasue you could just pull from that. The 1st is a bit more complicated, because it involves deciding what the best way to respond to certain kinds of pen-inputs is. It is, however, solved by the 3rd and 4th options provided in the optimization menu. So, the behavior of when and when not to render things is decided and customized by the user’s configuration.
[1] Quoted Pen SDK Docs
2. Init
TouchHelperTouchHelper.create(view, callback) .setStrokeWidth(3.0f) .setLimitRect(limit, exclude) .openRawDrawing();
viewis that you want to scribe.callbackisRawInputCallbackthat you can receive data being scribbled.limitis a rect specify the region you want to scribble on the view.excludeis a list ofRectto be excluded from the view.3. Control Pen
AfterTouchHelper().openRawDrawing(), you can calltouchHelper.setRawDrawingEnabled(true)to start scribbling,touchHelper.setRawDrawingEnabled(false);to pause.
You can call
touchHelper.setRawDrawingRenderEnabled(false)to disable render during scribble, and you can calltouchHelper.setStrokeStyle();to set stroke style. In order to fully stopTouchHelper, you need calltouchHelper.closeRawDrawing().4. Recieve Input Data
Pen :RawInputCallback.onBeginRawDrawing() -> RawInputCallback.onRawDrawingTouchPointMoveReceived() -> RawInputCallback.onRawDrawingTouchPointListReceived() -> RawInputCallback.onEndRawDrawing()erase :
RawInputCallback.onBeginRawErasing() -> RawInputCallback.onRawErasingTouchPointMoveReceived() -> RawInputCallback.onRawErasingTouchPointListReceived() -> RawInputCallback.onEndRawErasing()var callback = new RawInputCallback() { @Override public void onBeginRawDrawing(boolean b, TouchPoint touchPoint) { // begin of stylus data } @Override public void onEndRawDrawing(boolean b, TouchPoint touchPoint) { // end of stylus data } @Override public void onRawDrawingTouchPointMoveReceived(TouchPoint touchPoint) { // stylus data during stylus moving } @Override public void onRawDrawingTouchPointListReceived(TouchPointList touchPointList) { // cumulation of stylus data of stylus moving, you will receive it before onEndRawDrawing } @Override public void onBeginRawErasing(boolean b, TouchPoint touchPoint) { // same as RawData, but triggered by stylus eraser button } @Override public void onEndRawErasing(boolean b, TouchPoint touchPoint) { // same as RawData, but triggered by stylus eraser button } @Override public void onRawErasingTouchPointMoveReceived(TouchPoint touchPoint) { // same as RawData, but triggered by stylus eraser button } @Override public void onRawErasingTouchPointListReceived(TouchPointList touchPointList) { // same as RawData, but triggered by stylus eraser button } };