Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Reply
Retired
s_rashid
Posts: 127
Registered: ‎02-27-2012
My Device: Bold

Re: To somebody at BlackBerry


@Innovatology, @simon_hain,

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).

Thanks,
Rashid



Developer
Developer
CMY
Posts: 1,123
Registered: ‎02-10-2009
My Device: 8130 / 8350 / 9530 / 9550 / 9850 / PlayBook

Re: To somebody at BlackBerry

[ Edited ]

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.

Developer
Innovatology
Posts: 1,280
Registered: ‎03-03-2011
My Device: Playbook, Z10, Q10, Z30 with Files & Folders and Orbit of course

Re: To somebody at BlackBerry

[ Edited ]

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.

 

Files & Folders, the unified file & cloud manager for PlayBook and BB10 with SkyDrive, SugarSync, Box, Dropbox, Google Drive, Google Docs. Free 3-day trial! - Jon Webb - Innovatology - Utrecht, Netherlands
Developer
Innovatology
Posts: 1,280
Registered: ‎03-03-2011
My Device: Playbook, Z10, Q10, Z30 with Files & Folders and Orbit of course

Re: To somebody at BlackBerry

[ Edited ]

s_rashid wrote:


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).


Rashid,

 

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.

https://www.blackberry.com/jira/browse/TABLET-422

 

 

Files & Folders, the unified file & cloud manager for PlayBook and BB10 with SkyDrive, SugarSync, Box, Dropbox, Google Drive, Google Docs. Free 3-day trial! - Jon Webb - Innovatology - Utrecht, Netherlands
Developer
simon_hain
Posts: 16,282
Registered: ‎07-29-2008
My Device: Z10 LE, Z30, Passport

Re: To somebody at BlackBerry

i only log in to jira to file a bug or check the progress (if i get a notification), for voting it is much too slow and lacks overview.

I got the issue explained yesterday by Brian Zubert on twitter
https://twitter.com/bzubert/status/333924172071833600
the internal APIs are PPS, the QNX way of doing things. I have used it briefly myself to get a notification about a settings change, but it is really a bit wild, undocumented and many things return a permission error.
I understand that this is very complicated, especially when security is concerned, so i hope we'll see some new official APIs soon.

Early access to soon-to-be-public APIs like headless apps is another topic. I think they don't have a corporate strategy regarding these things and handle them on a case basis. If you know somebody high enough you may get access, and if you have a high profile app they want, like skype etc, you'll get the access proactive.
Unfair, but understandable. Still quite some way from the "all APIs will be public" statements though.
----------------------------------------------------------
feel free to press the like button on the right side to thank the user that helped you.
please mark posts as solved if you found a solution.
@SimonHain on twitter
Developer
BGmot
Posts: 1,068
Registered: ‎11-24-2011
My Device: PlayBook

Re: To somebody at BlackBerry

>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).

BlackBerry Development Advisor
smcveigh
Posts: 668
Registered: ‎11-29-2011
My Device: developer

Re: To somebody at BlackBerry

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.

 

Cheers,

Sean