Crash Bang Wallop, What a Picture!

[Estimated Reading Time: 6 minutes]

The fourth and final part in the not-as-short-as-I-thought-it-would be series on building a camera app for Android using Oxygene. In this penultimate instalment we will add the capability to actually take a picture. But that won’t take very long, so then we will spend a bit of time tidying up the application UI.

Taking A Picture

Taking a picture on Android is actually very straightforward. Once you have a reference to the Camera object (which we already have) it is a simple matter of calling the takePicture() method. This method requires a reference to an implementation of the Camera.PictureCallback interface.

This is a simple interface which I chose to implement on the MainActivity itself, resulting in this new version of the MainActivity class:

    MainActivity = public class(Activity, Camera.PictureCallback)
    private
      mCamera: Camera;
      mViewFinder: ViewFinder;
    public
      method onCreate(savedInstanceState: Bundle); override;
      method onDestroy; override;
      method CaptureClick(v: View);

    private // Camera.PictureCallback
      method onPictureTaken(aPicture: array of SByte; aCamera: Camera);
    end;

The code we need to add to the CaptureClick method is trivial:

  method MainActivity.CaptureClick(v: View);
  begin
    // Stop the preview while we take the picture

    mViewFinder.stop;

    mCamera.takePicture(NIL, NIL, self);
  end;

This call triggers an asynchronous image capture from the camera. The three parameters to the method in this call are references to callbacks called at different points in the image capture process.

The first is a Camera.ShutterCallback – this is a simple notification that the shutter has fired and a picture taken. I could use this to play a sound for the user’s benefit, for example.

The second is a Camera.PictureCallback – this is called when the RAW image data is ready. I could use this if I wished to capture the RAW image data.

The third is also a Camera.PictureCallback and is called then the JPEG image data is ready. This is the only notification I am interested in for this app, which is why the first two callbacks are specified as NIL.

Of course, I also need to implement that JPEG callback – my onPictureTaken implementation:

  method MainActivity.onPictureTaken(aPicture: array of SByte; aCamera: Camera);
  var
    timestamp: String;
    dir: File;
    jpegFile: File;
    stream: FileOutputStream;
  begin
    // Get a string containing formatted datetime as the basis for a unique filename

    timestamp := new SimpleDateFormat('yyyyMMdd_HHmmss').format(new Date());

    // Obtain the location of the pictures storage directory and compose a file

    dir      := Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_PICTURES);
    jpegFile := new File(dir.Path + File.separator + 'IMG_' + timestamp + '.jpg');

    // If we have a valid File, open an output stream and write the aPicture data to it

    if assigned(jpegFile) then
    begin
      stream := new FileOutputStream(jpegFile);
      stream.write(aPicture);
      stream.close;
    end;

    // Restart the viewfinder preview

    mViewFinder.start;
  end;

You may have noticed the calls to start() and stop() the viewfinder. These were the result of a simple (manual) refactoring of the existing ViewFinder code previously contained in the onSurfaceCreated and onSurfaceDestroyed methods.

One more finesse and we’re almost done.

Maintaining (or rather Obtaining) Focus

I thought it would be cute to add a “touch to autofocus” feature. Nothing fancy, just tap the preview to trigger the camera to autofocus.

This will be handled by the ViewFinder class, so we add the View.OnTouchListener interface to the list of implemented interfaces and the corresponding onTouch method to the declaration of that class:

    ViewFinder = public class(SurfaceView, SurfaceHolder.Callback,
                                           View.OnTouchListener)
      // ...

    private // View.OnTouchListener
      method onTouch(aView: View; aEvent: MotionEvent): Boolean;

      // ...
    end;

In the existing constructor we add the simple assignment of the ViewFinder as it’s own listener for touch events:

    OnTouchListener := self;

And finally of course, implement the onTouch method itself:

  method ViewFinder.onTouch(aView: View; aEvent: MotionEvent): Boolean;
  begin
    mCamera.autoFocus(NIL);
  end;

autoFocus is another example of an asynchronous method that will notify a callback when the operation is complete, in this case indicating whether focus was successful or not via parameters passed to the call back. Again, we could use this to provide some audio feedback or perform other processing with a focussed preview image. But I’m not going to bother so can simply pass NIL.

That’s it!

The app is (almost) complete with the following features.

• Live, real-time “viewfinder” preview
• Image capture to Pictures storage on the device
• Touch-to-Focus AutoFocus feature

By no means perfect, but good enough for now.

There is one last feature I want to add, but that is the subject of the next and absolutely final instalment.

One last thing I do want to do at this point however is tidy up the UI.

Polishing The Pig

Our app isn’t very pretty right now. In fact, downright ugly would be a more honest appraisal:

(The “Snapper” title is because I grabbed this screen shot using an early, experimental version of the app before I changed the name. The UI was otherwise exactly as described up to now)

Horrible. It doesn’t even look very “Android-y”. Of course it is strictly speaking entirely and utterly Android. But the reason it looks a bit “off” on my ICS tablet (I think I said before at some point that I was running JellyBean, but I realised I’m not) is that my app is not using an ActionBar so familiar from more recent versions of Android (since 3.0). An ActionBar will actually provide a better place for our capture button as well, allowing the entire screen (apart from the Action Bar area obviously) to be used for the viewfinder.

There are a few steps involved.

First, we set an appropriate minimum SDK version in our manifest. Action Bars were first introduced in 3.0 (SDK 11). We can get them on 2.1 devices as well with a little more work, but for my purposes SDK version 11 is good enough. While I’m at it I may as well also add the intended target version for my device (4.0.3 – API level 14):

   <uses-sdk android:minSdkVersion="11" android:targetSdkVersion="14"/>

This is all we need to do to actually enable the Action Bar for the app, but we do need to make it visible which we easily achieve with the addition of a simple call added to the MainActivity.onCreate method:

  self.ActionBar.show;

While we’re updating the onCreate method we can also remove the code that assigns the onClick listener for the button since we won’t be needing that anymore. We keep the CaptureClick method itself though. All will become clear.

Now we need to change the layout – it is actually made simpler since we do not need to explicitly declare either the Action Bar or the capture button (for reasons that will become clear in a moment):

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

 <FrameLayout
     android:id="@+id/camera_preview"
     android:layout_width="fill_parent"
     android:layout_height="wrap_content"
     android:layout_centerVertical="true"
     android:layout_centerHorizontal="true"
     android:layout_gravity="center_horizontal|top">
 </FrameLayout>

</RelativeLayout>

As I said, the ActionBar itself is provided for us automatically, displaying the application icon and name.

To add additional items to the bar, we define a menu resource. This is a further XML file placed in a folder called, funnily enough, menu, within our project folder (a sibling of the layout and values folders, within the res folder):

In this folder I create a new XML file which I choose to call main.xml, with the following content:

<menu xmlns:android="http://schemas.android.com/apk/res/android">
 <item android:id="@+id/capture_button"
     android:icon="@android:drawable/ic_menu_camera"
     android:orderInCategory="100"
     android:showAsAction="always"
     android:onClick="captureClick" />
</menu>

If I understand things correctly, this menu resource defines actions that will appear either on the popup menu of our activity when the device “menu” button is pressed, or will be presented in the ActionBar for the activity, or both. Where and when these menu items appear is governed by the android:showAsAction attribute.

In this case I have just the one item which I want always to be shown as an action – i.e. as a button on the ActionBar. This button has no caption and is represented by an icon representing a camera. I can provide my own icon image if I wish, but in this case I am simply identifying the stock Android menu icon for the camera.

This menu item replaces my previous button.

I set the onClick attribute to reference the captureClick method of my activity. However, the onClick for a MenuItem is slightly different to that for a Button, so we need to change the signature of the method – it now accepts a MenuItem parameter, rather than a View. While I’m at it, I apply the lowercase initial letter convention for methods that I am starting to grow accustomed to and which, it has to be said, is in turn growing on me. You can see that I already identified the method using this case convention in the menu item declaration.

Unfortunately, this menu is not loaded automatically. An Activity must explicitly “inflate” the appropriate menu resource at runtime. This presumably is in order to allow an Activity to choose the appropriate menu according to the runtime conditions and/or to make any adjustments that might be appropriate.

Inflating the menu is very simple and involves overriding the onCreateOptionsMenu method of the MainActivity:

  method MainActivity.onCreateOptionsMenu(aMenu: Menu): Boolean;
  begin
    MenuInflater.inflate(R.menu.main, aMenu);
    result := inherited;
  end;

And we’re done.

That might have seemed like a lot of work and very fiddly, but it really wasn’t. It took me longer to write it up for this post than it took to research (a one time cost) and implement.

I’ve learned enough in the process that I could now create myself a new project template for Visual Studio, to create an “Empty Action Bar” application in one go.

The result was well worth it I think: