07-30-2008 11:54 AM - edited 07-30-2008 12:08 PM
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....
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?
Solved! Go to Solution.
07-30-2008 01:01 PM
Alright... this is almost what I was asking for but still not as simple as it could be:
Here we find:
public static final long MENUITEM_FILE_EXPLORER_ITEMApplicationMenuItem 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.
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 )
07-30-2008 03:52 PM
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.
07-30-2008 07:25 PM
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...)
07-31-2008 10:01 AM - edited 07-31-2008 10:03 AM
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.
07-31-2008 11:40 AM
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.
03-10-2009 06:53 PM
I just downloaded the latest JDE. Is it still true that the File Explorer application is inaccessible by 3rd party apps?