Invoking the RIM Alternative
As discussed earlier, sometimes you may want to launch a native RIM application to handle media capture instead of using MMAPI. Some times this will be your only choice, such as if you need to take a picture on a device without software version 4.6 or take a video on a device without version 5.0. Even if your device supports your desired operation, you may prefer the interface of the native application to what you can provide on your own.
Starting recording in this manner is much simpler than MMAPI: it only takes a single line to start. On the other hand, getting data back out is quite a bit trickier. Because Invoke does not offer a mechanism for passing capture information back to the invoker, your only choice is to observe the filesystem. Once you see that a valid file has been created, you can assume that it was created by the capture application, and then perform whatever processing you want on it.
The listener must implement the FileSystemJournalListener interface. It will receive notifications whenever the filesystem has changed. Listing 2-2 shows a basic listener that will notify via system output when a video has been saved. At the same point, it also could prompt the application to do something with that file.
Listing 2-2. A Class That Listens for Recorded Video Files public class VideoFileListener implements FileSystemJournalListener {
private long lastChangeNumber = 0;
public void fileJournalChanged() {
long nextChangeNumber = FileSystemJournal.getNextUSN(); for (long change = nextChangeNumber - 1; change >= lastChangeNumber^ && change < nextChangeNumber; --change)
FileSystemJournalEntry entry = FileSystemJournal.getEntry(change);
break;
if (entry.getEvent() == FileSystemJournalEntry.FILE_ADDED) {
String path = entry.getPath();
if (path != null && path.indexOf(".3gp") != -1) {
System.out.println("Video saved in " + path); break;
lastChangeNumber = nextChangeNumber;
Then, just register your listener before launching the camcorder app. It will launch after a brief delay, as shown in Figure 2-5.
VideoFileListener listener = new VideoFileListener();
UiApplication.getUiApplication().addFileSystemJournalListener(listener); Invoke.invokeApplication(Invoke.APP_TYPE_CAMERA, new ^
CameraArguments(CameraArguments.ARG_VIDEO_RECORDER));
Note: If you want to run this code on an actual device, you will need to sign your COD to provide access to the RIM APIs. Read more about this process in Chapter 9, which discusses the RIM security model.
- Figure 2-5. An image captured by the native camera app Several items in Listing 2-2 bear closer examination.
■ RIM uses a journaled filesystem, where each file operation is assigned a unique number. For performance reasons, you should search backward from the most recent operation to the oldest, as shown earlier in Listing 2-2. Otherwise, it may take a very long time to find the event you're looking for.
■ fileJournalChanged() will be invoked every time a file is added, deleted, or modified. It's very possible that it will be called for a file other than our video. Keeping track of lastChangeNumber ensures that even when it is called multiple times, each entry is checked only once.
■ Likewise, because this can be called for any file, we should verify that the correct type of file was added before accepting it. Here we just print it out; in a real application, you would likely pass the file name back to the main application for more processing.
■ Don't forget to unregister your listener once you have the data or detect that the user has canceled and returned to your application. Do this with UiApplication.removeFileSystemJournalListener().
■ APP_TYPE_CAMERA has been available since software version 4.2 to capture still images. ARG_VIDEO_RECORDER was added in version 4.6 to record videos.
Most developers will likely view the Invoke system as a stop-gap measure. It's good to have available for phones that do not support your desired capture mode in a given software version, but it provides less control and will generally be a poorer user experience. Fortunately, as devices increasingly migrate to more advanced software versions, the need for this alternative will fade away.
Post a comment