My Mistakes with CWAC-Camera
My CWAC-Camera library
is an attempt to make taking pictures with Android’s Camera
API
somewhat easier, to hide a lot of the fiddly bits with previews and
so forth.
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.
Of note:
-
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 theCamera
subsystem, notablyCamera.Parameters
. Google has now deprecated theCamera
API, replacing it withandroid.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 underCamera
. -
I envisioned the library as being a replacement for the
ACTION_IMAGE_CAPTURE
andACTION_VIDEO_CAPTURE
Intent
actions, 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
ACTION_IMAGE_CAPTURE
and ACTION_VIDEO_CAPTURE
Intent
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
existing one: CameraFragment
and CameraView
, for example. I
am even looking to add a drop-in replacement for
ACTION_IMAGE_CAPTURE
and ACTION_VIDEO_CAPTURE
Intent
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.