Java Development

[dchapiesky]

Hello,   While I am very happy with the file explorer example within the JDE (I have 4.2, 4.5, & 4.6 - take your pick) I am extremely interested in using the existing media explorer to allow the user to find, select, and return the path & filename of the selected file back to my application via plain 'ol java calls...

The benefits of this approach are: 

1 - the user already knows how to do it.... 

2 - It's cool and handles thumbnails nicely

3 - I don't have to reinvent the wheel, again....

In message: http://supportforums.blackberry.com/rim/board/message?board.id=java_dev&message.id=638&query.id=6321...

It was implied that the net_rim_bb_file_explorer can be invoked in an "inter-application" way but this fails to point out how to usefully derive meaningful information from the execution of the explorer. 

To re-iterate, I'd like to call net_rim_bb_file_explorer (or some library which composes it) and get a filename and path after the user has found what they were looking for.

The "inter-application" bit seems a bit complex for something that should be an API call but I am darned if I can find it after 3 hours in the docs and google.... 

The media explorer is extremely sweet and I think that there are probably a lot of people who would like access to this bit of code... any ideas?

Daniel

Message Edited by dchapiesky on 07-30-2008 12:08 PM

[dchapiesky]

Alright... this is almost what I was asking for but still not as simple as it could be:

In: http://www.blackberry.com/developers/docs/4.5.0api/net/rim/blackberry/api/menuitem/ApplicationMenuIt...

Here we find:

public static final long MENUITEM_FILE_EXPLORER_ITEM

ApplicationMenuItem instances registered with this ID appear when the File Explorer applicaion is running and rendering a file. If you use this ID, you must also provide an ApplicationDescriptor that describes your application. Your application will be started to run the code in the ApplicationMenuItem.run() method. You may also register a mime type String with your menu item as the context parameter. If you do, your menu item will only appear when a file matching the registered mime type is being viewed.

The ApplicationMenuItem.run(Object) method is passed a String instance (the path to the file), when an application menu item is invoked in this context.

So we register a callback within our own application to be called externally when the media explorer is enabled and the user is selecting a file...   When the selection is made, our menu item is added to the list and our application is executed so that the callback can act upon the file. Great.

This falls short of the intent of my original post for the following reasons: (IT IS COOL THOUGH)

1) If my program is program "A" (instance 1 or "A1") and I "Invoke" the net_rim_bb_file_explorer

2) The file explorer displays my menu item for the user to select and the user selects the menu item I embedded

3) The file explorer invokes a new instance of my application "A" (instance 2 or "A2")

4) A1 never gets to play with the returned path name and file

5) A2 has no context with which to handle the path name and file it has been given...

 This problem set spawns the following questions:

When the OS tries to spawn an application and that application is already running, does the OS simply transfer to the existing instance or does it spawn a second instance?  If the former, then the above callback may work. If the latter, then I'm still in the same boat.

Sorry if I'm being verbose, but this is an interesting problem that I know can be solved.

(I am going to attempt a test of the above issues and will continue this thread with my results.  If anyone can throw some light on it in the mean time... Thanks ) 

Daniel

[MSohm]

The call for the run method of an ApplicationMenuItem occurs in a different process than your application.  Therefore it'll fire regardless of whether or not your application is already running.  The tricky part of this can be trying to share variables between the two.  A simple work around to this is to store information you wish to pass between the two processes in the RuntimeStore.

[dchapiesky]

Mark, avoiding the tricky part was the reason for my initial post.   Do you know of any way to call the net_rim_bb_file_explorer from an API level such as:

NetRimBBFileExplorer myExplorer = new NetRimFileExplorer();
String myPathAndFile;

myPathAndFile = myExplorer.RunInSelectMode();

 

The above code being purely hypothetical of course.

Failing that, are component classes of the explorer available? 

This odd form of interprocess communication is highly unportable and fundamentally flawed in design.  With an OS update the change of entry point into net_rim_bb_file_explorer could change and the whole strategy bricks the berry. (BTW - where is the info for entry points of 0,1,2 etc? Coudn't find that either...)

[MSohm]

The Invoke class is the supported mechanism for launching BlackBerry applications.  However, this does not currently support launching of the file explorer.

I have passed along your feedback to our development team.

Message Edited by MSohm on 07-31-2008 10:03 AM

[dchapiesky · Accepted solution]

Thanks Mark.

Access to the file explorer API would save alot of people alot of time.  It would also, I believe, improve the overall user experience since a consistent UI across different third-party applications would be presented.

Daniel

[babygodzilla]

Hi,

I just downloaded the latest JDE. Is it still true that the File Explorer application is inaccessible by 3rd party apps?

Thanks!

[rihan007]

Yes thats right. Nothing new has been offered by RIM

[amfp]

Hello,

Is the File Explorer application still inaccessible in the new JDE 5.0??

Thanks.