01-17-2013 02:06 AM - edited 01-17-2013 02:09 AM
Is there a way to enumerate all invocation targets, irrespective of mime type or uri?
I've tried passing */* and nulls in the InvokeManager.queryInvokeTargets function but it yields no results.
Basically I need to fetch all apps that have registered a bb.action.OPEN or bb.action.SHARE with their associated name, icon and invocation target details. The use case and performance criteria call for querying invocation targets up-front, before we know what type of files we'll find.
Solved! Go to Solution.
01-17-2013 03:01 AM
This is not possible. Specifying */* in the query will search for targets that support opening all types. What you need is a way to dynamically find out all targets and their supported mime types. Invocation framework is designed in such a way that you do not need to know who supports what. You just invoke and if there is a target, it will show up. If not you can gracefully fail or prompt the user accordingly. In fact, if there was a way to do this, it would break the purpose of invocation framework to begin with.
01-17-2013 09:45 AM - edited 01-17-2013 09:47 AM
Consider an invoke framework client app that displays lists of files. The types and number of files are not known in advance. The app needs to adjust the way it displays those list items (files) depending on invoke framework details. For instance, it may display the relevant icon that it acquires from the Invoke Framework. It may also adjust the layout of each list item depending on invoke framework targets. It may even insert sub-items for each related target.
Doing this from inside an item renderer is not a good idea for obvious reasons. Nor is querying the I/F for each file (type) before displaying the list - there may be hundreds or thousands of items. The logic of virtualized item renderers make this quite complicated. An elaborate caching mechanism is required to cache the invoke query response for each mime type. Doable, but not at all elegant. Caching is fine if it's needed for performance reasons, for instance if data must be fetched from a remote server, or if intensive data manipulation is needed. But it should never be due to lack of API's.
We spoke about this by e-mail and at BB Jam Americas in San Jose. I'm a little surprised you've forgotten.
01-17-2013 11:58 AM
Another use case: a remote HTTP server may be able to supply a resource in various mime types. We need to tell the remote server which mime types we support via an HTTP "Accept" header.