My Mistakes with CWAC-Camera
My CWAC-Camera library
is an attempt to make taking pictures with Android’s
somewhat easier, to hide a lot of the fiddly bits with previews and
It also serves as an abject lesson in the problems with writing reusable libraries, as I made mistakes along the way… mistakes that will now require me to pretty much rewrite the library from scratch.
I envisioned the library as being a wrapper around
Camera, rather than being a clean abstraction around the act of taking pictures and recording videos. As a result, I exposed bits of the
Camera.Parameters. Google has now deprecated the
CameraAPI, replacing it with
android.hardware.camera2. A cleaner abstraction would also make it easier to blend in other camera APIs (e.g., SONY’s remote camera stuff) that might not show up under
I envisioned the library as being a replacement for the
Intentactions, as third-party camera apps definitely vary in how well they support those actions. However, I did not more forcefully restrict the scope to be just that functionality, and I did not design an API around extensibility. As a result, when requests came in for new functionality, either the functionality had to be in the library, or the functionality would not exist. This was rather frustrating, as it meant a lot of extra code in the library for scenarios that are not really all that near any itches that I was really seeking to scratch. A camera library, more so than many libraries, needs a small core with an extension model that allows other developers to add plugins to the library to handle their own itches without having to re-develop the core.
My lack of scope control and extensibility also makes it very difficult to rewrite the implementation without breaking the API. Of note, some devices seem to not like it if you change the camera parameters on the fly, and that’s difficult for me to fix within the confines of my current API.
I suck at JavaDocs. I’m much more fond of long-form prose than short-form method and parameter descriptions.
I still need a library for my core use case: replacing the
actions. But I cannot rely upon
Camera for the long term —
if device manufacturers have inconsistent
Camera support now,
Camera support will only decline now that
Camera is deprecated.
And, I really need to address the extensibility issue, as otherwise
this library will be an unmaintainable mess for the long term.
So, in mid-December, I’ll begin rewriting the library. This will
take some time, as the new
android.hardware.camera2 API seems
to be your typical under-documented Android API. I will work on
patching a few bugs in the existing library, particularly ones
that do not involve API changes, but for the time being, significant
work on the existing library is frozen pending the rewrite.
The rewritten library will share some common aspects with the
CameraView, for example. I
am even looking to add a drop-in replacement for
actions, to make it easier to move to a library from relying upon
third-party camera apps.
However, the other aspects of the API are going to change, hopefully
for the better. I will provide instructions to help those migrating
from the old to the new API as the new library starts to stabilize.
In other words, stay tuned for further developments.
Need Android app development training for your team? Mark Murphy has trained hundreds! Learn more!