Building a Native Camera Access Library - Part II - Transcript.pdf

Building Native Camera Access - Part II
Now that we have the generic code of the library lets go into the Android port

Android Port
© Codename One 2017 all rights reserved
✦Use the include source feature
✦You can implement and debug the code right within the
native IDE
✦This applies to both iOS & Android
If this is the first tutorial on building native interfaces you are going through then here's an important tip. Use the include source feature of Codename One and build an
Android Studio project. Then implement the native interface within Android Studio. You can then copy and paste the code back into the Codename One project.

This is far more convenient as you can implement and debug the code right within the native IDE.

The same is true for xcode when working on a Mac. In this case because the native interface was so simple (albeit large) I skipped that stage but I have a bit of
experience doing this. Most of you would probably feel more comfortable building the hello world app with the native interface and implementing it in Android Studio.

import com.wonderkiln.camerakit.*;
import com.codename1.impl.android.AndroidNativeUtil;
import com.codename1.impl.android.AndroidImplementation;
import java.io.File;
CameraNativeAccessImpl
The Android port is trivial. Once we have the native interface we can right click the project and choose "Generate Native Stubs" which produces the skeleton code for
this implementation class.

Unlike before I'll start with the imports as some of them are a bit challenging.

I just imported everything as it was simpler

This is an important helper class when writing native Android code, you will see me use it soon

I wanted one method from the implementation: runOnUiThreadAndWait. It's really useful in some cases

public class CameraNativeAccessImpl {
private CameraView view;
private CameraKitEventListener listener =
new CameraKitEventListener() {
public void onEvent(CameraKitEvent event) {}
public void onError(CameraKitError error) {
String errorMessage = "";
if(error.getException() != null) {
errorMessage = error.getException().toString();
com.codename1.io.Log.e(error.getException());
com.codename1.io.Log.sendLogAsync();
}
CameraCallbacks.onError(error.getType(),
error.getMessage(), errorMessage);
}
public void onImage(CameraKitImage image) {
CameraCallbacks.onImage(image.getJpeg());
}
public void onVideo(CameraKitVideo video) {
CameraCallbacks.onVideo("file://" +
video.getVideoFile().getAbsolutePath());
}
};
Lets get into the code itself.

The view is the camera preview UI, I keep it as a member to return later.

}
}
}
}
};
The listener is bound later in the code, it just delegates all the calls into the callback. Notice I have only one listener on the native side.

All calls are eﬀectively the same they just invoke the `CameraCallbacks` class methods

}
}
}
}
};
Android native file paths should be prepended with file:// to work in Codename One's FileSystemStorage.

public void start() {
AndroidImplementation.runOnUiThreadAndBlock(new Runnable() {
public void run() {
if(view == null) {
view = new CameraView(AndroidNativeUtil.getContext());
view.addCameraKitListener(listener);
}
view.start();
}
});
}
public void stop() {
AndroidNativeUtil.getActivity().runOnUiThread(new Runnable() {
public void run() {
view.stop();
}
});
}
public boolean isStarted() {
if(view == null) {
return false;
}
return view.isStarted();
}
The next step is lifecycle and view methods. After the start method is invoked I'd like the view object to be valid otherwise we might have a problem. This code MUST run
on Androids native EDT hence the need for runOnUiThreadAndBlock()

public void run() {
if(view == null) {
}
view.start();
}
});
}
public void run() {
view.stop();
}
});
}
if(view == null) {
return false;
}
}
We initialize the view, bind the listener and start(). Notice we can start & stop() more than once

public void run() {
if(view == null) {
}
view.start();
}
});
}
public void run() {
view.stop();
}
});
}
if(view == null) {
return false;
}
}
We don't need to "wait" for stop() to complete but it still needs to run on Android's dispatch thread

public void run() {
view.stop();
}
});
}
if(view == null) {
return false;
}
}
public void setMethod(final int param) {
public void run() {
view.setMethod(param);
}
});
}
public android.view.View getView() {
return view;
}
public boolean isSupported() {
return true;
}
This method returns a PeerComponent in the Java side. The Android view is translated automatically

public void run() {
view.stop();
}
});
}
if(view == null) {
return false;
}
}
public void setMethod(final int param) {
public void run() {
view.setMethod(param);
}
});
}
public android.view.View getView() {
return view;
}
public boolean isSupported() {
return true;
}
The isSupported method is a standard method in native interfaces which defaults to false. When you implement a version in a platform set it to true

public void setPermissions(final int param) {
public void run() {
view.setPermissions(param);
}
});
}
public void setZoom(final float param) {
public void run() {
view.setZoom(param);
}
});
}
public void setFocus(final int param) {
// ... same runOnUiThread code
}
public void setFlash(final int param) {
}
public void setFacing(final int param) {
}
Next lets do a quick recap of the setter methods in the native interface. We can't use a Lambda yet because we are still using Java 5 for Android native code. This might
change by the time you see this!

We hope to upgrade Android native code for newer builds to use Java 8 syntax which will shorten the boilerplate here significantly.

public void setPermissions(final int param) {
public void run() {
view.setPermissions(param);
}
});
}
public void setZoom(final float param) {
public void run() {
view.setZoom(param);
}
});
}
public void setFocus(final int param) {
}
public void setFlash(final int param) {
}
public void setFacing(final int param) {
}
All of the methods here work roughly in the same way by delegating to the native call via the runOnUiThread call.

I could go for a couple of additional pages of setters but you get the drift, it’s more of the same…

public int getFacing() {
return view.getFacing();
}
public boolean isFacingFront() {
return view.isFacingFront();
}
public boolean isFacingBack() {
return view.isFacingBack();
}
public float getVerticalViewingAngle() {
return view.getCameraProperties().verticalViewingAngle;
}
public float getHorizontalViewingAngle() {
return view.getCameraProperties().horizontalViewingAngle;
}
public int getFlash() {
return view.getFlash();
}
public int getPreviewWidth() {
return view.getPreviewSize().getWidth();
}
public int getPreviewHeight() {
return view.getPreviewSize().getHeight();
Next we can review the getters which are shorter. Notice we don't need to use runOnUiThread as the getters aren't as sensitive to threading

public int getFacing() {
return view.getFacing();
}
public boolean isFacingFront() {
return view.isFacingFront();
}
public boolean isFacingBack() {
return view.isFacingBack();
}
public float getVerticalViewingAngle() {
return view.getCameraProperties().verticalViewingAngle;
}
public float getHorizontalViewingAngle() {
return view.getCameraProperties().horizontalViewingAngle;
}
public int getFlash() {
return view.getFlash();
}
public int getPreviewWidth() {
return view.getPreviewSize().getWidth();
}
public int getPreviewHeight() {
return view.getPreviewSize().getHeight();
As you may recall some of the methods here map to properties of the returned objects as is the case here and with the preview/capture methods below.

Like the setters this goes on a bit further so I’ll spare you an additional slide where I don’t have anything interesting to say…

public void captureVideoFile(final String param) {
public void run() {
String f = param;
if (param.startsWith("file://")) {
f = param.substring(7);
}
view.captureVideo(new File(f));
}
});
}
public void captureImage() {
public void run() {
view.captureImage();
}
});
}
public void captureVideo() {
public void run() {
view.captureVideo();
}
});
}
public void stopVideo() {
Finally we have the capture method calls. We need runOnUiThread as capture is thread sensitive

public void run() {
String f = param;
}
}
});
}
public void run() {
}
});
}
public void run() {
}
});
}
Files in Codename One have file URL prepended so they will act as URL's we remove this to translate the file into an Android file.

public void run() {
String f = param;
}
}
});
}
public void run() {
}
});
}
public void run() {
}
});
}
All the other methods are exactly the same. They just invoke the native Android version. This is it for the code but it won't work yet…

Build Hints
android.gradleDep=compile 'com.wonderkiln:camerakit:0.13.1';
We need three build hints to get this to work. The camera kit page asks that we add the gradle build dependency. The Codename one equivalent of that is the build hint
android.gradleDep

ProGuard
android.proguardKeep=-dontwarn com.google.android.gms.**
The page also mentions a proguard entry (a bit down in the page). This is handled by the android.proguardKeep build hint

Build Tools 27
android.buildToolsVersion=27
Unfortunately if you go through all of that things still won't compile because of the old build tools version and target so we need to use the latest version of build tools
which camera kit depends on. Specifically android.buildToolsVersion=27.

This line is a temporary fix, we will soon flip the default build tools version to 27 at which point it will be redundant. Once this is done we recommend removing it so when
we go to 28 it will use that.

Once all of this is done you should be able to use Camera Kit on Android. The challenge is now iOS…

Building a Native Camera Access Library - Part II - Transcript.pdf

Recommended

Recommended

More Related Content

Similar to Building a Native Camera Access Library - Part II - Transcript.pdf

Similar to Building a Native Camera Access Library - Part II - Transcript.pdf (20)

More from ShaiAlmog1

More from ShaiAlmog1 (20)

Recently uploaded

Recently uploaded (20)

Building a Native Camera Access Library - Part II - Transcript.pdf