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

Built For BlackBerry

Posts: 295
Registered: ‎02-14-2012
My Device: Nokia N950 / BB Playbook

difference between rejected and accepted BFB Application - Example: ClipMan

[ Edited ]

I would like to try to explain the difference between a rejected and a accepted Built for BlackBerry App. At least from my personal point of view. I'm not sure if this is according to the internal guidelines of BlackBerry but perhaps this may help others to understand what may be needed.

How will I do this?

It's simple. One of my Apps were rejected from Built for BlackBerry about 4 weeks ago. After a lot of frustration I gave it a second try and improve my small application in a private coding marathon.
I were now finally able to get it thru the Built for BlackBerry testing. At the second try. Yay!

So we have now something we could compare in a before / after scenario.

I will try to explain in this Posting what I've changed in my project. Since the Z10 launched in the meantime I had to remove my old version from the store to avoid confusion, so you're sadly unable to check out the two versions yourself to see and compare the small differences. So I will try to write in this posing about the differences. I know, every project is a totally different story. But perhaps other developers may get by this Example a Idea what could be the small difference which is needed to get a Application approved.

What is this Application about?

ClipMan is a small clipboard manager. Thats it. It watches for changes in the Clipboard while opened and stores every appearing text in a small database. Such a clipboard history can get very handy while texting. You get often to a point at which you recall a similar sentence you've written before. If you have copied those to the clipboard you are now able to get the text fast back. Even if you have restarted your device in the meantime.
At least I'm using a similar application called ditto at my desktop frequently. And it really improves my response and especially my developing speed.
ClipMan is the mobile replica of one of the most useful tools at my developer machine. :smileyhappy:


So, enought advertising. Only this single useful aspect is not enought for the Built for BlackBerry certificate. I tried, trust me. You will get: "basically only a single core function", even if there were a lot more (write protected stuff, database import / export, clean up, share functionality - it was simply not good enought)

So, what have I done?

Lets look and compare how it looks after the first startup: (Note: use the desktop version of this site if the picture is not visible)
640_Part01 - Startup.jpg
On the left we have the original Version. The screen is empty, the user has no idea what the Application could do. In contrast to this empty startup screen we have now the current version with a SystemToast Message with a short description. The database is already filled up with 6 more or less useful example messages with data related to the user itself (BBM Pin at example). The App is ready to play around with its features.

Here we see the two versions filled up with 6 text items:
640_Part02 - Appearence - Lock Feature.jpg
It looks very similar, all items are unlocked. If you asked yourself now what this unlocked means you got already a Idea why the old version was bad by design. The user sees on the left 6 red symbols, a unlocked padlock. But the user has no idea what this means. At the new version the fix was implemented simply by showing no lock indicator.

We get a better Idea of this when we open a item:
640_Part03 - Appearence - Lock Feature - Detail - unlocked.jpg
On the left we see the red unlocked status indicator. On the new Version at the right there is no indication since still nothing happened.
At the menu bar there is at the old version a green lock, the function the user may trigger by tapping this Symbol. We have a very similar symbol at the right, but it acts differently.

Lets see what happens by tapping this Symbol:
640_Part04 - Appearence - Lock Feature - Detail - locked.jpg
Now we have the Item Locked. At the old version the symbols have simply changed. The user still doesn't know whats the point of this function. But at the new Version the Lock in the Menu got activated (according to the design guidelines) and we have at the top a clear indicator including a explanation what happened.

The IMHO important aspect: The user was not confronted with any kind of indication that this feature may exist until he finally tried it the first time. No confusion, clear functional design.

Here we see how the list looks now:
640_Part05 - List Locked Item.jpg
The old version was for me as the developer of the App clear and understandable. The color was indicator enought, all features worked. But as learned in a session about good design in Amsterdam: The application should work for everyone, also colorblind people. Those usergroup had a obvious handicap at the old version of ClipMan.

Cleaning Up:
640_Part06 - Clean Up.jpg
This is very similar at both Applications. The Dialog should explain in detail what happens and what the user may except.

The result:
640_Part07 - Cleaned List.jpg
All Items except the locked were deleted. Additionally the database got compressed to keep it fast. But we shouldn't bother the user with this feature. Only we, the developers should care to keep the application performant.

If you wan't to inform the user about more details of the Software, put it inside the Info screen:
640_Part08 - Info screen.jpg
The old version was very rudimentary. The new version, clear in the beginning, more detailed in the long text below.

How I have improved the core functionality of the list in the main screen?

Context Menu:
640_Part09 - Context Menu.jpg
It was not really needed since at the old Version every function was available by simply opening a item. But if I understood the design guidelines correct every ListView should have a context Menu. The user expects this behavior.

Search function:
640_Part10 - Search.jpg
I added a search function to the list. Since I'm keeping myself the list always very empty I had no demand for a search button. Personally I have the list only filled with the stuff I'm currently using. But othery may use this Application in a different way. So a search function was needed.

Built for BlackBerry means built especially for BlackBerry10. And so the Application should integrate itself in every aspect into the BB10 system.

Here we have the minimized Applications in the Task View:
640_Part11 - Task View.jpg
Easy to see which one is the old, and which is the new version. At the new Version you get only in the first 2 seconds a minimized version of your list. From this point on it displays always the current content of your clipboard. Quasi the extension of all this swipe and peek stuff. "Not sure what you have currently in the clipboard?" - Minimize your corrent app, look at the ClipMan App to check and go back to your task before pasting the wrong text.
Simple, clear, useful.

Overall integration

Since the share functionallity was a selection criterion at the BFB checklist ClipMan had a share button even at the first version.

Neat feature, simple to implement, but surely not enought. Why? Every App with a text field has a share function integrated by default via the context menu at a selected text. So why should a extra Button to sharing a text be this special?

Thanks to jtegen and also the already accepted FancyTran Application I got finally a Idea about the whole BB10 flow concept. It shouldn't be needed to leave a application to do something useful with a other application.

So ClipMan got a invocation target:
640_Part12 - Invocation Target.jpg
There are 2 possibilities as you see in the screenshots. Share via the normal dialog and I integrated it additionally into the text selection context menu. Perhaps not a good idea for every application. Personally I would hate it to have every application integrated into this menu. But since a text is now marked and the context menu is opened, the most users want now to interact with the clipboard. If copied and ClipMan is opened the text will get pushed to the ClipMan database. If you know you haven't opened ClipMan you can push now your text using this button to your clipboard manager.
This is the nature of ClipMan as a clipboard manager, extend the functionality of the clipboard. So in this case it is a good idea to have it placed in every application near the Cut, Copy and Paste Buttons. The most applications should be fine by simply integrating itself into the share button at which the App you want to use gets selected. It's only a single additional tap away.

But this invocation integration delivers also a additional benefit:

A user is now able to select a text and replace it with a different without leaving the current task.
640_Part13 - Invocation Target - Put Text to Clipboard.jpg

push a different text to the clipboard

640_Part14 - Invocation Target - Paste Text.jpg
paste it into your Application, in this case a email

Simply mark a text, Open it in ClipMan (the text gets stored for later use) - you can now go back to what you have done before OR select a different text, push it to the clipboard, go back to your App and paste the text snipped wherever you want. Even at a form in the next text area.

And I would say now we got the BlackBerry 10 flow.

Store experience:
I had two versions of ClipMan in the store. A free, and a paid app. Sadly this is also a bad design. I got this explained at several places so I guess it played also a role to get it rejected. "Bad store experience."

The user downloads the free version from the store, got a first impression but with a limited functionality. You have to explain this in many places and dialoges. And you have to do some kind of advertising in your App why the user should pay now to get more. If the user was bugged enought he has to go to the store, search for the paid version, he has to pay and install the full version and after this, uninstall the old version manually.

And think about the data the user has already created (at ClipMan perhaps no problem since the free had the store function disabled), but at other applications the user has the problem that he may loose all settings and stored data from the free version since the paid gets installed to a different "sandbox" and has no access to the old data.

Because I had not enought time (deadline) I decided to simply remove the free version and concentrate myself only on a single version, the paid.
But the better solution, instead of two versions or simply only a paid would be a upgradeable free version with in app purchase. The Freemium model.

Sadly we are unable to revert a once made decision after a App got published. Once in the store we have to stick to paid. We can't change the licence model and ask the people which have already paid for the old version to pay again to activate the new free version to get again what they have already paid for. This could cause a **bleep**storm at your App reviews.

I'm currently creating a small but perhaps useful tool Application to test this freemium model myself and how to integrate it into my Apps. But I'm sure, my next big Application will have this integrated from the beginning. No free / paid versions of the same App anymore. Only free, paid or freemium. Not several versions of the same App anymore.

Bug fixes:
Last but still very important:
My App were unable to handle different text encoding correctly. I found the bug and it is now able to store and handle also arabic, chinese, cyrillic, greek, japanese and many other character encodings.

Bottom Line:
There can't be a universal recipe for every App. And its completely in vain to simply copy and recreate my application or one of the other BFBB Applications since they won't accept severals of the same App type. Perhaps you have the luck to have currently already created a App which could get a Built for BlackBerry with some minor modifications as mine. Or you realize now that your App could never reach this level as some of my other Applications may never have a chance to get BFBB even if they are really good at their core functionality. I would say both insights are better compared to utter cluelessness. :smileyhappy:

I hope this posting was worth a read and may help some other developers with their projects. At least I hope my time was not totally wasted.
If you have any questions don't be shy to ask. But be warned, I don't know any internals and I have no Idea which of the changes I explained above were crucial to get accepted. If you have a App which got also approved at the second or third try, please post also your story to give other developers a impression what could be needed. And as always don't forget to hit the like button if you wan't to honor the work behind this "essay". :smileywink:

Thanks to jtegen, peter9477 (was great to met you in Amsterdam :smileyvery-happy:), neilwick, connyhald and all the other developers in this forum and at twitter which helped, comforted and motivated me a lot. :smileywink:

Posts: 30
Registered: ‎11-06-2012
My Device: BB 10 Dev Alpha

Re: difference between rejected and accepted BFB Application - Example: ClipMan

This post is totally awesome! Thank you!

Trusted Contributor
Posts: 176
Registered: ‎01-20-2013
My Device: Bold 9790

Re: difference between rejected and accepted BFB Application - Example: ClipMan

I love this post, helex. Thanks for doing it.


I think that avoiding multi-coloured icons in the action bar is important to maintaining the BB10 look and feel. You give a lot of good suggestions here.

Posts: 295
Registered: ‎02-14-2012
My Device: Nokia N950 / BB Playbook

Re: difference between rejected and accepted BFB Application - Example: ClipMan

Thanks for this totally awesome feedback! :smileyvery-happy:


I just got a official mail by BlackBerry about this posting. Overwhelming. I guess I just got it. :smileyhappy:

Posts: 145
Registered: ‎12-23-2012
My Device: BB10 Dev Alpha

Re: difference between rejected and accepted BFB Application - Example: ClipMan

Thanks, I was looking for something like this, great help indeed

Posts: 6,541
Registered: ‎10-27-2010
My Device: HTC One, PlayBook, LE Z10, DE Q10

Re: difference between rejected and accepted BFB Application - Example: ClipMan

Nice post, Glad you made it.
Trusted Contributor
Posts: 107
Registered: ‎07-26-2012
My Device: Blackberry Z10

Re: difference between rejected and accepted BFB Application - Example: ClipMan

[ Edited ]

Very good post.. nice

Try my HTML5 app CountDown (free)

Click Accept as Solution if this post that have solved your issue(s)!
Like if you found this post useful..
Posts: 16,360
Registered: ‎07-29-2008
My Device: Z10 LE, Z30, Passport

Re: difference between rejected and accepted BFB Application - Example: ClipMan

good to see such a case study, and i am pretty sure that the hardcore users will find your little tool very useful.
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
New Developer
Posts: 13
Registered: ‎02-08-2011
My Device: Curve 9320

Re: difference between rejected and accepted BFB Application - Example: ClipMan

Helex, thanks for sharing this experience with us. I really appreciate it. You truly earned that BFB-badge.
New Developer
Posts: 101
Registered: ‎11-08-2012
My Device: 9790

Re: difference between rejected and accepted BFB Application - Example: ClipMan

Totally Awesome Post .