{"id":1634,"date":"2013-09-17T20:42:54","date_gmt":"2013-09-17T08:42:54","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=1634"},"modified":"2013-09-18T09:18:22","modified_gmt":"2013-09-17T21:18:22","slug":"an-app-with-view","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/1634\/","title":{"rendered":"An App With View"},"content":{"rendered":"[Estimated Reading Time: <\/span> 8<\/span> minutes]<\/span><\/span>

Not a Merchant Ivory<\/em> production, but Part 3<\/strong> in the Oxygene for Java<\/strong> camera app for Android<\/strong> series.<\/p>\n

So far we have seen that we can work directly with the Android<\/strong> platform manifest and layout files<\/a> and how the Oxygene<\/strong> language is a first class citizen in the Java platform<\/a> and just one way in which it simplifies and improves the business of writing Java code, in Pascal.<\/p>\n

Now it’s time to make the app do something useful.<\/p>\n

<\/p>\n

First Things Third<\/h3>\n

A camera is not very useful without some way of seeing what it is you are taking a picture of (with some exceptions<\/a>). We need some sort of preview or viewfinder.<\/p>\n

In Part 1<\/a> we created a layout element – a FrameLayout<\/strong> – as a placeholder for a camera preview control, and now we need to create that control and place it in that UI element. We shall do that in code. But first we need to implement the preview control itself. To keep things organised I put this new control class in a separate file (ViewFinder.pas<\/strong>) but declared the contents as part of the same namespace<\/strong> as the rest of the app.<\/p>\n

For what we have in mind I need to sub-class the Android SurfaceView<\/strong> class and implement the SurfaceHolder.Callback<\/strong> interface. Our control will need to maintain a reference to the camera which will be supplied when we construct our viewfinder class. A Camera.CameraInfo<\/strong> object will also be useful later on. Finally we will need a reference to an entity known as a SurfaceHolder<\/strong>.<\/p>\n

Remember, this exercise has been a learning experience for me so I am no expert on the Android framework. But if I have understood things correctly, SurfaceView<\/strong> is to TCustomControl<\/strong> as SurfaceHolder<\/strong> is to the TCanvas<\/strong>. It’s not quite as direct a relationship as that, but for our purposes this will suffice. The SurfaceView<\/strong> – via the SurfaceHolder<\/strong> – provides the “canvas” on which we will render our camera preview. Our initial class declaration looks like this:<\/p>\n

\r\n\r\n  namespace nz.co.deltics.demo.camera;\r\n\r\ninterface\r\n\r\n  uses \r\n    android.content,\r\n    android.graphics,\r\n    android.hardware,\r\n    android.util,\r\n    android.view;\r\n\r\n  type\r\n    ViewFinder = public class(SurfaceView, SurfaceHolder.Callback)\r\n    private\r\n      mCamera: Camera;\r\n      mCameraInfo: Camera.CameraInfo;\r\n      mSurfaceHolder: SurfaceHolder;\r\n    public\r\n      constructor(aContext: Context; aCamera: Camera);\r\n\r\n    private \/\/ SurfaceHolder.Callback\r\n      method surfaceCreated(aHolder: SurfaceHolder);\r\n      method surfaceDestroyed(aHolder: SurfaceHolder);\r\n      method surfaceChanged(aHolder: SurfaceHolder; aFormat, aWidth, aHeight: Integer);\r\n    end;\r\n\r\n\r\nimplementation\r\n\r\n  \/\/ ...\r\n\r\n<\/pre>\n
I have added some Android<\/strong> namespaces to the uses<\/strong> list to avoid having to fully qualify references made to members of those namespaces.  This isn’t strictly necessary, and you can of course continue to fully qualify any references if necessary (or desired).<\/p>\n
For example, anywhere that Camera<\/strong> is referenced I could instead fully qualify the reference as android.hardware.Camera<\/strong> and then I would not need to “use” the android.hardware<\/strong> namespace.<\/p>\n
This is obviously similar to the concept of using a unit<\/strong> in Delphi<\/strong>, except that with Delphi you must<\/em><\/strong> use a unit in order to reference it’s contents where the same is not the case in Oxygene<\/strong>.  Oxygene<\/strong> is more similar to more modern languages such as Java<\/strong> and C#<\/strong> in this respect.<\/p>\n
So now let us look at the implementation of the class itself.<\/p>\n
First, the constructor.<\/p>\n
Anonymous Constructors and Non-Existent Properties<\/h3>\n
Since an Oxygene<\/strong> class in Oxygene for Java<\/strong> is compiled to a Java<\/strong> class, it must conform to the rules of the Java<\/strong> language and accordingly our constructor<\/strong> has no name.  Oxygene<\/strong> optionally allows us to redundantly use a name of Create<\/strong> for our constructors if we wish but this is optional (on a per project basis, according to a Compatibility<\/em> setting in the compiler options) and even with this option enabled Create<\/strong> is the only name allowed.<\/p>\n
I have opted to adopt the Java convention in this case and so no name is used.<\/p>\n
The implementation of the constructor itself is very straightforward.<\/p>\n
\r\n  constructor ViewFinder(aContext: Context; aCamera: Camera);\r\n  begin\r\n    inherited constructor(aContext);\r\n\r\n    mCamera := aCamera;\r\n\r\n    mCameraInfo := new Camera.CameraInfo;\r\n    Camera.getCameraInfo(0, mCameraInfo);\r\n\r\n    mSurfaceHolder := self.Holder;\r\n    mSurfaceHolder.addCallback(self);\r\n  end;\r\n<\/pre>\n
After invoking the inherited constructor<\/strong> of the SurfaceView<\/strong> parent class a reference to the supplied Camera<\/strong> object is stored in the mCamera<\/strong> member which we will need later on.<\/p>\n
Next we create the Camera.CameraInfo<\/strong> object and obtain this info from the Camera<\/strong>.  Notice in this case that the “getCameraInfo” method does not conform to the semantics of a property (it modifies a passed parameter rather than returning a result) and we must call it as a method.  In a real application we would need to be more sensible about how we determine which camera to get info for, but for my purposes in this app I know that the camera I want (the rear facing camera) is the first camera on my device (an ASUS TF101).  So I’m being quick and dirty and just specifying camera 0 (zero).  Not recommended, obviously.  \ud83d\ude42<\/p>\n
We will use the information in this info object later on to ensure our preview image is correctly oriented with respect to the device orientation.<\/p>\n
We then obtain a reference to the SurfaceHolder<\/strong> of the SurfaceView<\/strong> via the Holder<\/strong> property and we add a reference to the ViewFinder<\/strong> class itself as a callback handler for the SurfaceHolder<\/strong>.<\/p>\n
Yet again, this is where Oxygene<\/strong> does not simply provide access to the Java<\/strong> classes but allows us to work with them in a manner more natural to an ObjectPascal<\/strong> developer.  As far as I know, Java<\/strong> still does not formally support the notion of a “property” on a class, as a Delphi developer would be used to.  The “Holder<\/strong>” property we are reading in this constructor is in fact a regular Java method<\/strong> named getHolder<\/strong>.  As I understand it however, it is a well established convention in Java<\/strong> (stemming from Java Beans) to name accessor methods for notional properties in this way.   Oxygene<\/strong> takes that convention and presents it to the developer as if the Java<\/strong> class really did have a property formally declared.<\/p>\n
But again, you have the choice.  Although the code completion in Visual Studio offers only the “property name”, the compiler does not force you to use the property syntax.  If you prefer you can still use the formal method name.  The two are exactly equivalent:<\/p>\n
\r\n    mSurfaceHolder := self.Holder;\r\n    mSurfaceHolder := self.getHolder;\r\n<\/pre>\n
Now let’s look at the implementation of the SurfaceHolder.Callback<\/strong> interface, which is where all the real work is done.<\/p>\n
It’s For You-hooo<\/h3>\n
The surfaceCreated<\/strong> and surfaceDestroyed<\/strong> methods of the callback interface notify us when the Surface<\/strong> of our SurfaceView<\/strong> control has been, predictably enough, created or destroyed.  In our case these notifications tell us when to start and stop displaying preview images taken through the camera.<\/p>\n
First, surfaceCreated<\/strong>: <\/p>\n
\r\n  method ViewFinder.surfaceCreated(aHolder: SurfaceHolder);\r\n  begin\r\n    \/\/ The Surface has been created, now tell the camera where to draw the preview.\r\n    try \r\n      mCamera.PreviewDisplay := mSurfaceHolder;\r\n      mCamera.startPreview;\r\n\r\n    except\r\n      on e: IOException do\r\n        Log.d("Demo Camera", "Error setting camera preview: " + e.getMessage());\r\n    end;\r\n  end;\r\n<\/pre>\n
When our control’s surface is created we assign our SurfaceHolder<\/strong> to the PreviewDisplay<\/strong> property of the Camera<\/strong> object reference (stored by our constructor).  After assigning the PreviewDisplay<\/strong> we then call startPreview<\/strong> on the camera to, well, start capturing preview images, which the camera will then automatically start presenting for us.<\/p>\n
In a manner that will be familiar to any Delphi developer, We keep a wary eye open for an IOException<\/strong> and if we get one we log it for potential diagnostic purposes.<\/p>\n
Quickly going back to the PreviewDisplay<\/strong> property.  This is Java<\/strong>, remember.  No such thing as properties.  And that’s right.  Again, there is no such “property” called “PreviewDisplay<\/strong>” on the Camera<\/strong>.  There are getPreviewDisplay<\/strong> and setPreviewDisplay<\/strong> methods however.<\/p>\n
Oxygene<\/strong> doesn’t just sanitise get methods into readable properties, it does the same for writable<\/em> ones (with a set<\/strong> method) too ! \ud83d\ude42  Just as before however, you do still have the option of using the explicit setPreviewDisplay()<\/strong> method call syntax if you prefer:<\/p>\n
\r\n      mCamera.setPreviewDisplay(mSurfaceHolder);\r\n<\/pre>\n
Worth mentioning at this point is that as well as setting up automatic drawing of preview frames, if we were interested in working with the images captured during<\/em> preview there are mechanisms that enable us to receive additional notifications which receive each image captured during preview, but that is not something that we are concerned with here.<\/p>\n
So much for getting the preview going.<\/p>\n
When our surface is destroyed we must be sure to stop the preview as well, and that is take care of in surfaceDestroyed<\/strong>:<\/p>\n
\r\n  method ViewFinder.surfaceDestroyed(aHolder: SurfaceHolder);\r\n  begin\r\n    mCamera.stopPreview;\r\n    mCamera.release;\r\n  end;\r\n<\/pre>\n
We tell the camera to stop the preview and release the camera.<\/p>\n
The final notification from the SurfaceHolder that we need to respond to, is when the surface has changed.  One of the reasons that our surface may change is when the device orientation changes, causing our layout to be rotated.  When this occurs I would like to ensure that the preview image is oriented correctly with respect to the camera – this is not something that occurs automatically (and perhaps is not always appropriate though it is in my case and I can’t think off-hand of a situation when it might not be).<\/p>\n
In any event, to determine the orientation to be applied to the camera we must determine the current orientation of the device<\/em> and make the appropriate adjustment according to the natural orientation<\/em> of the camera.  The information about the camera is fixed and is contained in the Camera.CameraInfo<\/strong> object we obtained in our constructor.  We did that so that we would not need to query the camera for that information every time the device orientation changes and so can respond that bit more quickly.<\/p>\n
Obtaining the current device orientation involves a bit of hoop jumping to obtain a reference to the system WindowManager<\/strong> so that we may obtain the current rotation from the DefaultDisplay<\/strong>.<\/p>\n
With the current device rotation we can calculate the adjustment for the camera, based on the camera’s natural orientation.  Which is all a very wordy way of saying:<\/p>\n
\r\n  method ViewFinder.surfaceChanged(aHolder: SurfaceHolder; aFormat, aWidth, aHeight: Integer);\r\n  var\r\n    wndmgr: WindowManager;\r\n    rotation: Integer;\r\n    angle: Integer;\r\n  begin\r\n    if NOT assigned(mSurfaceHolder.Surface) then\r\n      EXIT; \/\/ preview surface does not exist\r\n    \r\n    wndmgr   := WindowManager(self.Context.getSystemService(Context.WINDOW_SERVICE));\r\n    rotation := wndmgr.DefaultDisplay.Rotation;\r\n\r\n    case rotation of\r\n      Surface.ROTATION_0  : angle := 0;\r\n      Surface.ROTATION_90 : angle := 90;\r\n      Surface.ROTATION_180: angle := 180;\r\n      Surface.ROTATION_270: angle := 270; \r\n    end;\r\n     \r\n    mCamera.DisplayOrientation := (mCameraInfo.orientation - angle + 360) mod 360;\r\n  end;\r\n<\/pre>\n
There are a lot of assumptions here.<\/p>\n
First of all, there’s no error checking so if something should unexpectedly go awry this app is simply going to crash out ungracefully.  This isn’t an exercise in implementing a fully robust app for use on any and all Android devices though, so again, I can get away with it here.<\/p>\n
Similarly, changing the camera DisplayOrientation<\/strong> is something that on older versions of Android (prior to SDK revision 14, Android 4.0) can only be done when there is no active preview.  On the version of Android on my device – 4.1.2 – this isn’t an issue.  But to be safe I could wrap this method in code which stops the preview (mCamera.stopPreview<\/strong>) and then restarts it only after applying the orientation change (re-assigning PreviewDisplay<\/strong> and calling startPreview<\/strong> again).<\/p>\n
In the real world this would be performed conditionally, following a test of the Android version on which the app is running.<\/p>\n
But for now, this is almost all I need for a functioning camera preview in my app.  The only step remaining at this point is to actually instantiate the ViewFinder<\/strong> class and place it in the FrameLayout<\/strong> container we created at the beginning.<\/p>\n
Creating The ViewFinder<\/h3>\n
So, returning back to the MainActivity<\/strong> class we already have, we add two new members.  One will hold a reference to the Camera<\/strong>, the other to the Viewfinder<\/strong>.<\/p>\n
\r\n    MainActivity = public class(Activity, Camera.PictureCallback)\r\n    private\r\n      mCamera: Camera;\r\n      mViewFinder: ViewFinder;\r\n    public\r\n      method onCreate(savedInstanceState: Bundle); override;\r\n      method CaptureClick(v: View);\r\n    end;\r\n<\/pre>\n
I do not need to add anything to the uses clause of the MainActivity<\/strong> unit.  The ViewFinder<\/strong> class is declared in the same namespace as the MainActivity<\/strong> class already – nz.co.deltics.demo.camera<\/em> – even though it is in a separate file.<\/p>\n
Finally, we need to add a little code to the onCreate<\/strong> method to turn on the Camera<\/strong>, instantiate the ViewFinder<\/strong> and place it in our UI.<\/p>\n
\r\n  method MainActivity.onCreate(savedInstanceState: Bundle);\r\n  var\r\n    layout: FrameLayout;\r\n    btnCapture: Button;\r\n  begin\r\n    inherited;\r\n\r\n    ContentView := R.layout.main;\r\n\r\n    mCamera := Camera.open;\r\n    mViewFinder := new ViewFinder(self, mCamera);\r\n\r\n    layout := FrameLayout(findViewById(R.id.camera_preview));\r\n    layout.addView(mViewFinder);\r\n\r\n    btnCapture := Button(findViewById(R.id.button_capture));\r\n    btnCapture.OnClickListener := new interface View.OnClickListener(onClick := @CaptureClick);\r\n  end;\r\n<\/pre>\n
After turning the Camera<\/strong> on with the call to open<\/strong> (without a specific camera ID, this opens the default camera – again, quick and dirty but adequate for my purposes) we create our ViewFinder<\/strong>, passing the reference to the Camera that the ViewFinder<\/strong> needs.<\/p>\n
We then obtain a reference to the FrameLayout we placed in our layout and add the ViewFinder view that we just created.<\/p>\n
That’s it.<\/p>\n
All Over Bar The Shouting<\/h3>\n
In this state, this application is a functioning camera preview app.<\/p>\n
The only thing it lacks is the ability to actually take a picture, which is what we will look at in the next and final (in this series) instalment.<\/p>\n","protected":false},"excerpt":{"rendered":"
[Estimated Reading Time: <\/span> 8<\/span> minutes]<\/span><\/span> Not a Merchant Ivory production, but Part 3 in the Oxygene for Java camera app for Android series. So far we have seen that we can work directly with the Android platform manifest and layout files and how the Oxygene language is a first class citizen in the Java platform and just one way in […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[212,205,4,180],"tags":[153,217,181],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-qm","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":1624,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1624\/","url_meta":{"origin":1634,"position":0},"title":"Exploring Listeners With Oxygene","date":"16 Sep 2013","format":false,"excerpt":"Part 2 in a short series demonstrating the development of a simple camera app for Android using Oxygene. In the previous instalment we looked at the basic framework of our app. For this instalment I was going to show how to implement the camera preview or viewfinder for this instalment,\u2026","rel":"","context":"In "Android"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1605,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1605\/","url_meta":{"origin":1634,"position":1},"title":"Anatomy of a Camera App","date":"15 Sep 2013","format":false,"excerpt":"Part 1 in an as yet unknown number of articles using a (very) simple camera application to demonstrate building first class Android applications using \"Pascal for Java\" - i.e. Oxygene Cooper. In this first instalment we will look at the basics - the components we are going to need and\u2026","rel":"","context":"In "Android"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screen-Shot-2013-09-15-at-10.12.32-.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":1713,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1713\/","url_meta":{"origin":1634,"position":2},"title":"How to Call Java Code from an Oxygene Android Application","date":"20 Sep 2013","format":false,"excerpt":"Lachlan just posted a link to a post on Google+ (also available as a PDF) demonstrating how to call Java from Delphi XE5. I was shocked at both the amount and the nature of the code involved. It is long, convoluted and ugly stuff (nb. that isn't a criticism of\u2026","rel":"","context":"In "Android"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1658,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1658\/","url_meta":{"origin":1634,"position":3},"title":"Crash Bang Wallop, What a Picture!","date":"19 Sep 2013","format":false,"excerpt":"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\u2026","rel":"","context":"In "Android"","img":{"alt_text":"Very Ugly Duckling","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Screenshot_2013-09-19-19-38-56-1024x640.jpg?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":2202,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2202\/","url_meta":{"origin":1634,"position":4},"title":"What is Hydrogene ?  Asked and Answered","date":"03 Dec 2013","format":false,"excerpt":"Over the past few weeks there has been some speculation as to what the mysterious \"Hydrogene\" that RemObjects have been working on may or may not be. Well, that particular feline has slipped it's captors and escaped the bag. I'm not aware of any official announcement and I hope that\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1503,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1503\/","url_meta":{"origin":1634,"position":5},"title":"Sharing Code Across Platforms in Oxygene","date":"22 Aug 2013","format":false,"excerpt":"There seems to be a perception among some people that Delphi is in the unique position of allowing developers to share and re-use code across the various platforms that it's compiler can now (and will soon) target. But this is not the case. Oxygene has had this capability right from\u2026","rel":"","context":"In "Cooper"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1634"}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=1634"}],"version-history":[{"count":12,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1634\/revisions"}],"predecessor-version":[{"id":1647,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1634\/revisions\/1647"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=1634"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=1634"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=1634"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}