The CommonsBlog

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 the Camera subsystem, notably Camera.Parameters. Google has now deprecated the Camera API, 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 Camera.

  • I envisioned the library as being a replacement for the ACTION_IMAGE_CAPTURE and ACTION_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.

Need a speaker at your Android development meetup? Mark Murphy is available, in person in the Boston/Pittsburgh/DC triangle, or by remote anywhere in the world! Contact Mark for details!