Ditching Camera Chapters - Wade?


#1

I thought more about your points about ditching the camera chapters and understand the frustration of directly dealing with them. However after using the implicit intents in chapter 21 I started thinking why not let the camera app that comes with the device do the preview and pic for you? So I looked and lo and behold there is a camera Intent ACTION_IMAGE_CAPTURE that lets you do exactly that!

I thought this was decent - developer.android.com/reference/ … GE_CAPTURE

You can still control where the image file ends up if you want it in your app private storage, or anywhere else you want it, right? And the OEM camera app will take care of any platform-specific issues.

One thing I wonder though is whether through the Camera Intent whether you can set any camera parameters such as resolution. I saw you could set this for video with an EXTRA - if this is used for still image capture it returns you the thumb but if you specify the OUTPUT EXTRA it will store the “full sized image” according to the docs where you specify. Hopefully “full-sized” means max res for the hardware, and any you can do any resizing down from there that you want.

I just thought this seems much more inline with the concept of reusing existing code - no worrying about surfaces, the camera hardware specifics, etc. And the user is still free to adjust camera parms himself when taking the pic.

What do ya’ll think?


#2

That’s exactly what we’d suggest for most uses.

If you do need to host a Camera in your own interface, we recommend using this library from CommonsGuy:

https://github.com/commonsguy/cwac-camera


#3

Thanks for the reply Wade. I did go back and redo the Chap 17 activity with the ACTION_IMAGE_CAPTURE intent of the Camera App. I ran it on a Galaxy s4 which has a 1920.1080 screen. Some funky stuff went down (as always).

First design-wise since the Camera App requires the pathname of the file you want to store the image in to be passed on the Intent, you need a persistent mechanism to retain the pathname so you can process it in onActivityResult() - so the thing to do is in the onClick method for the button create a zero-length file wherever you want it (I used external storage so I could see it while using an unrooted S4), instantiate a Photo object with the full path of the File, and set it on the Crime. There are more elegant ways of structuring the data I’m sure but I wanted to proof out the use of the Camera App not grind on style points :wink:

As a result of this if onActivityResult() does NOT get a RESULT_OK you should free up that file and reset the Crime’s Photo to null.

The next set of issues was in PictureUtils.getScaledDrawable and how it resizes. Using the code from Chapter 20 which used the Camera interface I noticed the following values for srcWidth destWidth - 4128 and 3096. Depending on the orientation of the device when it was called destWidth and destHeight were 1920x1080 or 1080x1920. So in the Chapter 20 code no matter what the orientation, the scale factor was either 2 or 3, and NEVER 1.

Well using the camera app I found that the srcWidth destWidth was being set to 4128x2322 - NOT 3096! No idea why. Anyway the effect of this is that the scale factor in one scenario is 1, and if you set the scale factor to 1 it will not show the picture in the image view (I confirmed this by going back into the Ch20 code and making it 1 no matter what).

So WHY wont it show the drawable (or bitmap) when the scale factor is 1?

Another question is I tried to force the Camera App to landscape with:
i.putExtra(MediaStore.EXTRA_SCREEN_ORIENTATION, ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);
and it had no effect whatsoever.

While I learned a lot about debugging through this adventure and finding the issues I am still exacerbated with the Camera! I also learned that looking at the sizes of the height and width of the ImageView during onStart was another deadend since they are 0 at that time.

There simply must be an ez simple way to have your App take a pic that you incorporate via thumbnails and large images in an OEM neutral fashion - so what is it?

Should the code that scales the image just look at the EXIF info of the image itself to determine orientation and use a completely different strategy for scaling images down to what you need?