App Inventor 2 - Front Camera Project

The Problem

We currently provide a property in the Camera component to use the front camera if needed.

It has been reported as not working on certain devices.

The Camera component code shows the current implementation using an extra field in the camera Intent:

if (useFront) {        intent.putExtra("android.intent.extras.CAMERA_FACING", 1);      }

This does not seem to be working anymore, at least on newer phones, and we need to change this as soon as possible.

Working on this project

Prerequisites

1) You are familiar with Java and the Android SDK.

2) You are familiar with the App Inventor codebase.

Make sure you fork the project, and work in a feature branch; we have slides for that: Contributing to App Inventor through github, and App Inventor development workflow.

In fact, there is a full course for App Inventor development here.

Workflow

1) Reproducing: Make sure the function does not work anymore (as reported). If it works for you, contact us anyway as explained in step 2.

2) Communicating: Talk to us! We want to know you are interested in working on this. Talk to us on irc (if there’s anyone there: freenode #appinventor) or start (reply to) a thread in the Open Source forum.

3) Working with the Camera: We always recommend to work with the Android SDK before working with the App Inventor sources. It’s generally a lot faster to work with Eclipse or Android Studio than it is to compile the full AI codebase.

Play with camera functions in an Android SDK app as explained at: http://developer.android.com/guide/topics/media/camera.html

Note that some of these methods are only available in API level 9. At the moment we support API level 3, but while you are working with the SDK, you should explore all the functions available in there (more information on this later).

You should also have a look at how we have created the Camera component. You will see there that we have used an intent to use the built-in camera app (a different implementation might be possible).

4) Proposal document: Now that you have an idea of how things work, you should write a brief design document and share it in the open source forum to get feedback before you start coding on App Inventor. Search the open source forum for other design documents; there’s plenty of examples there! (two examples: blocks filter proposal, Player fixes).

After a quick look at the camera docs, my feeling is that we should use Camera.CameraInfo to detect cameras, and open the front one if the property is selected (and the camera exists). I might be wrong with this, and also note that CameraInfo is an API level 9 function. You will probably come up with a better solution!

5) App Inventor coding: now it’s time to place your code or fixes into the AI codebase. Make sure you follow the guidelines in supporting older and newer devices in App Inventor to make the change compatible with older devices. There might not be a way around not having some functions on older devices, and that is fine as long as we handle those devices properly (and we send feedback to the user of the app).

Make sure you have gone through the main documents for adding components and properties.

6) test; test; test: When you think you are ready for a review, you can open a pull request (review the workflow slides). Make sure you pull again from our master and rebase your code, as this will make our lives easier and we can review your code faster.

When you open your pull request, your design proposal should briefly document any changes that you have made since you first started working on the project (design changes) and also the URL for an appspot instance with your changes deployed; make sure you include a link to a Companion app if your changes affect the currently existing one.

What happens next?

Please note that this is supposed to be a rather interactive experience. We want you to talk to us through the open source forum as soon as you decide to start looking into this, and to keep talking to us throughout the process.

Once you open a pull request, we will look at it on github; we will probably go back and forth with you there until we are all happy with the code. But that’s a rather light review. Right after that, we will push your code for internal review, and we will take a bit longer to provide feedback and make sure that everything is good for a merge. Once internal review passes, your code is automatically merged and will show up in github.

For internal review we will squash all your commits into one (that’s how the internal review server we use (Gerrit) likes things done). So once your code is merged, it will appear as a single commit, even if you made a number of commits in your feature branch.

Any questions?

Please get in touch through the open source forum.