ShowTable of Contents
Overview
This article describes three samples that illustrate the use of the Worklight Camera builder that's provided with the Multichannel Feature Pack for Web Experience Factory 8.0. The three samples are:
– CameraTest: A simple test model for verifying your configuration for using hybrid camera support.
– CitizenReports: An application for reporting issues such as graffiti or potholes to a city government. This is based on an earlier sample and article posted on developerWorks.
– CheckDeposit: A simple example of an application that captures two pictures (front and back of a check).
Note about sample package availability
The sample package has been temporarily removed from this page for updating. We expect to post an updated package before long.
Prerequisites
To use these samples, you should refer to the article “Getting Started and Enabling Worklight Support” which describes how to configure your environment for using IBM Worklight in combination with Web Experience Factory and the Camera builder. To use the camera support you must be running in the context of an installed hybrid app built with IBM Worklight, and that article describes all the steps involved in setting things up (there are quite a few). The final step in that article refers back to this sample and the CameraTest model. Once you have completed the configuration described in that article, you should import both of the archive files from the feature pack into your project, and you should import the attached sample archive.
CameraTest Model
This model is in the samples/fp80/camera_test folder. It is a very simple model intended just for verifying all the configuration requirements for using the Camera builder. It has two simple pages, one where the Camera builder is used, and one that shows the uploaded picture after taking a picture.
Screenshots of the CameraTest model running on a smartphone device:
CitizenReports Model
This is an application that might be part of a city government web site, and it lets users report issues they encounter such as graffiti or sign damage. When running from an installed hybrid app, they can take a picture of the issue and submit the photo along with other information. The submitted information is stored in a database table.
This model is an updated version of the sample that accompanies this article on developerWorks: http://www.ibm.com/developerworks/mobile/library/mo-aim1301-worklight-portal-4/index.html
This new version has been updated to use the Camera builder, which takes the place of hand-edited JavaScript and several other builders that were previously needed to implement the camera functionality. This version was also updated to use the new layouts and styling from the feature pack.
To create and populate the database table, open the CitizenReportsProvider model, then open the SQL Table Create builder and click Fetch Data Source Names. From the drop-down menu for SQL DataSource, select jdbc/CloudscapeForWEF. If this data source doesn't exist, it will offer to create it for you. Scroll down in the builder and click the Create Table button. This should create and populate the database table.
Screenshots of the CitizenReports model:
CheckDeposit Model
This is a very simple example of an application that lets the user take two pictures for the front and back of a check, such as you would see in a banking app for letting customers deposit checks. This application is intended just as an example of camera use, and it doesn't store the captured data at all.
Screenshots of the CheckDeposit model:
Notes on running the samples
To use the Camera builder with these samples, you will need to have your development environment configured for using Worklight with Web Experience Factory, as described in the “Getting Started and Enabling Worklight Support” article mentioned above.
To use these samples in your project, import the attached zip file into your project using the Import WebSphere Portlet Factory Archive command.
NOTE on File Upload and Security
The location in the WAR (under WEB-INF/) to which files are typically uploaded by default is by necessity a temporary location.
Your application should treat it as such and move the files to the ultimate location after verifying they're appropriate to the application (right file extension(s), appropriate content, etc).
The temporary file upload location in the WAR doesn't make sense for long term storage for multiple reasons, including but possibly not limited to:
- the fact that the WAR on disk may be wiped out and replaced on a redeploy
- Use of a multinode cluster with multiple copies of the WAR on disk(s).
For security reasons, you should not enable file upload directly into the servable content area of the deployed application, to prevent malicious content from being uploaded into a location then downloadable from a browser.
The initial temporary upload location should be located below the WEB-INF folder of the deployed application, specifically for holding temporary uploaded files until the application has validated them and relocated them to a more permanent location.