Take the 2-minute tour ×

I am writing a mobile app (Android) that will allow the user to 'write' to a canvas using a single-touch device with 1 pixel accuracy. The app will be running on a tablet device that will be approximately standard 8 1/2" x 11" size. My strategy is to store the 'text' as vector data, in that each stroke of the input device will essentially be a vector consisting of a start point, and end point, and some number of intermediate points that help to define the shape of the vector (generated by the touchscreen/OS on touch movement). This should allow me to keep track of the order that the strokes were put down (to support undo, etc) and be flexible enough to allow this text to be re-sized, etc like any other vector graphic.

However, doing some very rough back of the envelope calculations, with a highly accurate input device and a large screen such that you can emulate on a one for one basis the standard paper notepad, that means you will have ~1,700 strokes per full page of text. Figuring, worst-case, that each stroke could be composed of up to ~20-30 individual points (a point for every pixel or so of the stroke), that means ~50,000 data points per page... WAY too big for SQLite/Android to handle with any expectation of reliability when a page is being reloaded and the vector strokes are being recreated (I have to imagine that pulling 50,000+ results from the SQLite db will exceed the CursorWindow limit of 1Mb)

I know I could break up the data retrieval into multiple queries, or could modify the stroke data such that I only add an intermediate point to help define the stroke vector shape if it is more than X pixels from a start, finish or other intermediate pixel, but I am wondering if I need to rethink this strategy from the ground up...

Any suggestions on how to tackle this problem in a more efficient way?



share|improve this question
add comment

2 Answers

Is there any reason of using vector data in the first place? Without knowing your other requirements, it seems to me that you just need to store the data in raster / bitmap and compress it with regular compression methods such as PNG / zip / djvu (or if performance suffers, simple things like run-length-encoding / RLE).

EDIT: sorry I didn't read the question clearly. However if you only need things like "undo" and "resize", you can take a snapshot of the bitmap for every stroke (of course you only need to take a snapshot of the regions that change).

Also it might be possible to take a hybrid approach where you display a snapshot bitmap first while waiting for the (real) vector images to load.

Furthermore, I am not familiar about the android cursor limit, but SQL queries can always be rewritten to split the result in pieces (via LIMIT... OFFSET).

share|improve this answer
I'm using vectors for storage so that I can easily convert/scale the data, export it from the device and be able to edit it in other applications, etc. Since posting this question, I've figured out how to represent the vectors in Android, and how to store thme efficiently; essentially as SVG paths. I'll post a full 'answer' shortly detailing this a little more. Thanks for the input. –  Paul Mennega Feb 7 '11 at 4:55
add comment
up vote 0 down vote accepted

Solution I am using for now, although I would be open to any further suggestion!

  1. Create a canvas View that can both convert SVG paths to Android paths, and can intercept motion events, converting them to android Paths while also storing them as SVG paths.
  2. Display the Android Paths to the screen in onDraw()
  3. Write the SVG Paths out to an .svg file


share|improve this answer
add comment

Your Answer


