05-13-2013 11:15 AM
We understand the frustration. But note that these are not APIs which are being hidden intentionally. Perhaps, I caused some confusion in my answer before (my apologies). The original question demanded an answer on how the core media apps implemented the thumbnail preview feature. It uses several internal services which are not not ready to be exposed to 3rd party applications for various dependencies & security reasons (they are often changing and might break external 3rd party apps). There are various complications related to the database syncing that needs to be considered as well. This feature was more of an *app* feature (as opposed to be platform feature).
Either way, from what it seems to me, the best way to go forward with this limitation is if you place an API feature request accordingly. Please try to include as many use cases and reasoning as possible. The more developers/apps we can have voicing for this feature request, the easier it will be escalate your feature request against the internal development team(s).
05-13-2013 12:49 PM - edited 05-13-2013 12:56 PM
I understand the need for security, but I still think your approach is flawed. If there are internal APIs that you are testing with a limited set of partners, then why are the larger companies the only ones that seem to get access? Why not make it a process that anyone can apply to so that the smaller companies are on a level playing field. If a smaller 3rd party developer comes up with an idea and posts it in a public forum and then a larger company gets word of it and intergrates it into their application becuase they have this partner access, then something that could have made this solo developer into a larger developer is now taken away from them. And not only that they may lose sales because when they finally get to release thier app many users may have already purchased the app from the larger company who has had time to work out the bugs. I think once things are available to be tested on a partner level then it should be broadcasted in the same fashion to all developers and let those who have an immediate need for it apply for its usage. Because in my opinion many innovations are first introduced by smaller independent developers and made popular by the larger comapnies who have more visibility and you would get better coverage from the person with the original idea creator and not someone who took a top level idea and tried to make low-level usage out of it.
I can give you a shallow example of this with BBM Voice. I created and tested a small PTT application using PIN messaging and BBM around 5-6 years or so ago that used many workarounds to get the BBM contacts from the backup file. Then BBM access was removed for a few years (2 or so I think) and I got away from the project. And now there is the BBM Voice application from BlackBerry that I'm sure uses many of the same ideas that I was probably using to send data back and forth strictly between BlackBerry handhelds. I know its not the exact same because I had to use binary encoded PIN message and encode and decode the messages myself, but the principle is similar in that it allowed users to make toll free calls directly between BlakBerry handheld using only the users data plan.
05-13-2013 03:40 PM - edited 05-13-2013 03:56 PM
I can understand that some deep integration needs more than just API documentation. It may need two coders (one at BB, one at the partner) working together on the project. It is obvious that BB would do that for a major cloud player, but not with little Innovatology, though we'd love to do that kind of project.
What bugs me (a little) is seening our idea implemented by others while our hands are tied. It's OK that we've lost some competitive advantage - a better platform is good for all of us - but we've many other ideas that could take it two, three, four steps further than what we're seeing in BB10 today. Too bad BB hasn't allowed us to take those next steps.
What bugs me more is that months later, there is still no sign of progress. We asked to get "in on the action" back in september/october after spotting early signs of our API request in action, but so far no luck. Perhaps we'll see some change tomorrow at BBLive.
05-13-2013 03:51 PM - edited 05-13-2013 07:58 PM
Either way, from what it seems to me, the best way to go forward with this limitation is if you place an API feature request accordingly. [...] The more developers/apps we can have voicing for this feature request, the easier it will be escalate your feature request against the internal development team(s).
https://www.blackberry.com/jira/browse/TABLET-423 from Jan 2012. Zero votes.
As for feature requests: I really don't think JIRA is suitable as a voting mechanism. For instance, I entered a feature request for headless apps, also a year and a half ago. Great to see it is finally being implemented (though we still have to see the details). If you've been watching the forums, blogs and social media lately you'll know that this is one of the most requested features. Still, it received only 3 votes in JIRA.
05-14-2013 05:42 AM
05-14-2013 10:59 PM
>as the way Box & Dropbox are integrated into BB10 was my idea
I can't even access your idea. For some reason many bugs are not accessible by all (pretty sure this reason is important though).
06-14-2013 05:22 PM
Further to what Rashid has said here... (I have to chime in on this, as I owned this component for a time)...
The multimedia indexer on the platform is more of a shared component used between a couple of our multimedia apps. It isn't really a platform feature presently. It's as if the "Pictures" app went off and did the indexing by itself, stuffed some results in a database, but also shared the results with the "Videos" app.
You are totally free to poke around at the database that it generates and try to interpret the contents. We can't really stop you from doing so. It is not sandboxed in any way.
Since the requirements of this indexer are evolving on a weekly or monthly basis due to the multimedia apps evolving requirements, it would be very frustrating to developers if we had to keep asking them to rewrite their stuff to adapt. Any time it needs to be alterred, we have to co-ordinate with multiple teams to ensure things don't break.
Once things stabilize a bit more, there will be a formalized interface to this database. For now, the people who would be doing this formalization are very busy working on related deliveries.
I get it. People want this. The multimedia team gets it. I suggest you just continue raising issues in JIRA and pestering the Product Management team (eg. Russell) and tell them that this is important to you!
As to the "no private APIs" decree -- this is still the decree. But as a side-effect of the rapid pace of development, sometimes things have to be massaged around a bit, and test-driven for a while before we can formalize them. If product is shipping on Friday and my application team comes to me with a problem that requires a new API on Wednesday, I try to help them out with something quick if it doesn't exist already, and then I have to go off and formalize it for the next release, document it, etc. None of this sort of thing is being intentionally hidden.