Archive | Blackberry RSS feed for this section

What makes blackberry app a super app – summary of webcast

25 Feb

What makes a Blackberry appliactoin to be a super app? This is the question that Mike Kirkup – head of developer relations at RIM tried to answer today in a free webcast. There has been an obsession recently with super phones and super apps as it seems. And why phones and/or apps have to be necessarily super?

So there seem to be two definitions of super apps according to Mike Kirkup.

If you take the blackberry phone from the user and he misses this app – then it is a super app since it provides an inherent value for the end user.

Another “definition” is more technical – so what are the main components that make a BlackBerry app a super app:

  • Always on experience
  • Seamless integration with 3d party apps
  • Notification driven
Not sure about you, but I see here a small misconception. On one side Mike says that if the application is extremely useful up to the point where if taken away from the user he will surely miss it but on the other hand there are specific points which actually make an app to be a super app. So what if the app is very useful to many people to the extent that they will surely miss it if taken away such as for example DailyHoroscope application for BlackBerry. Because many users of DailyHoroscope application are going crazy and flood us with mails in case we experience even minimal downtime. So the application is extremely useful to its users and certainly has value for them but according to the bullet points, DailyHoroscope is not a super app.
The source of confusion I think is that Mike meant if you take away BlackBerry device from the user, then other devices that may have similar apps will not be able to fill the gap. That’s what makes any BlackBerry app a super app I would guess. The push mechanism and the multitasking and deep integration is something that does not exist on iPhone and/or iPod Touch, but similar things exist on Android and WebOS and Maemo are also actively developed and progressing  towards richer and richer platform.

So what makes specifically BlackBerry platform a super app enabler platform accodring to RIM? The first and the point which was put most of the emphasis was the “multi-threaded OS with background apps”. Other enablers mentioned were:

  • Contextual integration with apps
  • Rich event based notification model that integrates deeply in the system
  • Efficient push services
  • Integrated LBS and Mapping

Mike argued that the possibility of deep native integration allows easier “native” application integration in a cohesive manner into the system. The main point seems to be that since the applications do not have to invent everything from scratch by using built in components/services etc, the applications can deliver unified user experience which lowers the learning curve for the applications and eliminates most of the confusion in mastering a new app.

Starting from OS 5.0 RIM introduced (or better say exposed to 3d party developers) much richer built in components such as autocomplete, file picker, map field, browserfield, media player components (JSR 135 or MMAPI)

The power of push. Mike mentioned that RIM invented the push and were running it in production for more than 10 years and they know exactly what they are doing. (hear that Apple? haha… ). The push limitation for BIS is 8KB while for BES it is much higher and is specified by BES administrator but is hard limited (by I think 1MB in the older BES versions with much higher limit value in BES 5.0 – I think around 10Mb)

Overall it was an interesting webcast and Mike did a great job talking about all the things that are great about BlackBerry platform. I personally was a little disappointed since I expected much more technical session.

Q/A Session:

Q&A session was quite interesting. Mike zipped through more than 200 questions in less than 40 minutes with great and to the point answers. Thank you Mike! I documented the most interesting Q&As to my taste and the ones that are most likely to be interesting to other developers.

  • When advertising will be available?
  • For BB alliance the beta will be opening very soon. For the rest of the publishers – the time line promised by Mike was approximately 2 month
  • Time for application approval?
  • Depends on the type of the application submitted. In general it is about 10 days but they are supposedly getting at about 48 hours time
  • Is the PUSH service free for all the developers?
  • It is free for almost all the alliance partners but they are working on releasing it to all the developers
  • All those super apps running in the background will make the devices slow – what about more resources for the devices?
  • Mike said that they will continue to innovate in the device area but the overall answer was extremely vague
  • More tutorials and code?
  • There is a lot of tutorials and code currently available online but it is hard to find it. Current knowledge base will be restructured and reorganized and mostly replaced by developer resources which is some new knowledge base.
  • Book for developers from RIM?
  • Working on that with authors and the community RIM is unlikely to release the book of its own.
  • Developers competition for super apps? Is it something that is coming?
  • RIM is planning to run super app development challenge in 4 regions very soon and pick up the best super apps and showcase them in BBDevCon in the end of September
  • When 5.0 JDE will be out of Beta?
  • 5.0 JDE will be out of beta soon and will finally NOT require simulator restart to push the new build to the simulator (YEY!!! Great news, hopefully Eclipse will mirror that as well)
  • UI tools for GUI building
  • Working on UI tool which will be drag and drop tool that will generate Java code for you (That would be a blessing, although knowing how RIM executes development tools projects, the tool might very likely be quite unusable for anything more serious than placing a label field with “Hello World”)
  • Paid applications worldwide timeline?
  • Worldwide is particularly difficult since RIM is supporting more than 150 countries. Support will be rolled out increasingly
  • Is JDE going to be phased out in favor of Eclipe?
  • Not right now. When RIM will feel that Eclipse has matured enough it will happen, but in general Eclipse is destined to replace the JDE
  • Are other development platforms going to be supported except Windows?
  • Mac is in the pipeline and support is likely to appear until the end of the year
  • App World is not as advertised as Apple’s App Store
  • Rim will start being much more aggressive about promoting App World in the future but this is highly dependent on RIMS relations with carriers since RIM is tightly integrated with carriers and they rub each other’s shoulder. (well, of course…)
  • Payments through carriers as opposed to payment through PayPal
  • App World 2.0 will have options to pay with either credit card, PayPal or through the carrier
  • Is Verizon’s store going to compete with App World?
  • Not really as RIM is not competing with any of the 3d party stores like Handango, GetJar etc…
  • Are subscription based payments going to be supported in App World 2.0?
  • It is not clear exactly what it is going to be, but some sort of subscription payment will be available
  • What is the best cross framework to use for developing for BB? PhoneGap
  • PhoneGap is great but the apps built with those cross platform frameworks will not be super apps! This is not possible since those frameworks are targeting the lowest common denominator.
  • Suggested books?
  • There are 2 good books John Wargo which is more like a reference manual. Anthony Rizk is more smooth read book and is less like reference.
  • What is the OS version to use as the lowest common denominator for development of super apps?
  • 4.6
  • Can I create a super app with SDK prior to 4.6
  • Yes you certainly can – many of the capabilities are available in the prior versions of the platforms
  • What is the process of migrating a simple app into a super app?
  • Think about how your simple app can take advantage of all the mentioned components that comprise a super app. Start thinking about your application and you will most likely realize that there are many ways to improve
  • Monitoring f uninstall of your own app – will it possible?
  • This is something that should be available in the next version of the next version.
  • Are free apps going to be able to use payments for donations?
  • Certainly – using in app payments is possible for that
  • Is advertising network be available worldwide?
  • Yes at the launch the advertising service will be available worldwide and then local advertising agencies will be added locally
  • What are you doing for developer training especially in Asia and Africa?
  • RIM will run BlackBerry developer days around the world. Follow our development blog for more details and updates.
  • Knowledge base is broken, I can not find any information there
  • The KB will be phased out and replaced with BB resource center
  • When normal developers will be able to use BIS?
  • This is something that RIM will be doing soon
  • Samples of a super apps?
  • Poynt app that was highlighted through MWC definitely have several characteristics of a super app
  • Are there any security risks with all this deep integration of the apps into the system
  • There is a
  • Any battery drain issues with the application always on interfacing with different system components?
  • RIM will release a simulator that will be able to simulate battery drain of the applications

Problems running BlackBerry Simulator (fledge) on Windows 7 64 bit

22 Jan

As I already wrote, BlackBerry development is not a lot of fun.  Not only you basically can not develop in Linux and OS X (although there are some workarounds, it makes the process even more painful than it already is). But you will also have problems with 64 bit operating systems. RIM is in a position that they do not officially support 64 bit systems.

The main problem with 64 bit Windows 7 for me was that I can not close the simulator (or actually the “fledge” application that runs the simulators). There are 2 possible solutions to this problem:

  1. Kill the task through task manager
  2. The simulator should close if you are in debug mode and you disconnect the debug session

There is also another inconvenience which is caused by your cautiously guarding Windows system. It will warn you every time that (Oh my!) fledge will change something on your computer. You know – the standard User Control Account message. To avoid that message always popping up, you will have to adjust your setting in User Control Account panel. Hit “Windows” then just type UCA, you will get it. Adjust it to the minimum and you’r good to go.

BlackBerry development with Eclipse plugin – fixing corrupted *.jdp file

13 Aug

It’s not a secret that Eclipse plugin is very buggy and although it has improved a lot over the time, the blackberry plugin still has a lot of issues and quirks. One of the problems that have been bugging me a lot was that sometimes the *.jdp file gets corrupted. This is the file where BB plugin for Eclipse saves most of the meta data for the project, including the files that are included in the project and consequently need to be compiled. So, many times I had problems with SVN meta data files corrupting this project, or sometimes perfectly legitimate *.java files that get stuck in the *.jdp file, but do not exist anymore. The result of the *.jdp file being corrupted is that your application does no longer get compiled and redeployed when you run it. And the worst part, Eclipse would not explicitly let you know about this. It would silently fail and not re-deploy the app. So unless this is the first time you run the application, or the changes you made are not visually obvious, you would not know about this. But this is completely separate issue. One of the many issues with BB Eclipse plugin already covered. Each time I have been struggling (sometimes for significant amount of times). Couple times I was able to manually delete files from the *.jdp file (although this is not recommended by RIM) and this solved the problem, but mostly I had to recreate the whole project from scratch, which if your project is large and, which is more important has dependencies on libraries, may become painful if you need to do this every few days.

So the easiest way I found so far to solve this problem is:

  1. Delete the *.jdp file (you can just rename it to *.jdp.OLD)
  2. Delete the project from Eclipse (right click the project and choose delete). DO NOT however check the checkbox “delete the contents of the project from disk”
  3. Create a new project and point it to the same place.

Since all the Eclipse project related files remain untouched, you should get your project exactly at the same state it was before it got corrupted, minus the corrupted part. Why – because when you re-create the project Eclipse plugin should re-create the *.jdp file.

Showing a dialog (or screen) from a background thread on BlackBerry

9 Jun

If you need to pop up a dialog or any screen actually from a process that runs in background on BlackBerry, it is fairly easy to do, unfortunately it is (as pretty much everything with BlackBerry development)  easy to figure out how to do.

The following piece of code should do the trick:

		synchronized (Application.getEventLock())
		{
			Ui.getUiEngine().pushGlobalScreen(new CLAScreen(), 1, UiEngine.GLOBAL_QUEUE);
		}

There are also a few things you should be aware of when using this code:

  1. Your backgroud process should implement UiEngine. Easy way is to extend Application.
  2. If you change UiEngine.GLOBAL_QUEUE to UiEngine.GLOBAL_MODAL, the dialog will block your thread until it is closed

Android development vs. Blackberry Development

11 Apr

I was contemplating quite a lot about the title for this post. Originally I wanted to give it the title of “Why developing for Blackberry sucks” but then I thought it might be too harsh and does not really reflect the content of the post which is about comparing the experience of developing for Android and experience of developing for Blackberry and settled for the current title. There were other titles revolving in my head, but all of them were just variations of  the original “why developing for Blackberry sucks”

I have been developing for Android for some time and lately I have been working on developing for Blackberry and I must say development for Android wins hands down in all aspects. Many times, especially frustrated with Blackberry buggy IDE or other cumbersome experience I wanted to write this post, but I had to find the time for it.

So what is so bad about Blackberry development? It starts at the very basics – development environment. Google has developed a very nice plugin for Eclipse which works very well and even has the basics of support for visual editing of user iterface screens. RIM – the company behind Blackberry for a long time had their own development environment – JDE. Written using basic SWING components, there’s no need to mention how bare boned and outdated it looked. They have recently introduced Eclipse plugin as well, but it is pretty buggy and half baked. It is hundreds times better than the first version of the plugin, but it is still from being stable and feature rich.

Then we have the emulators – gosh, why do I have to restart the emulator everytime I want to test a new build? It can take up to a few minutes to restart the emulators for the more advanced models. To feel the pain, just imagine the nightmare of programming the UI for Blackberry in that setup. And no, there is no visual helper that can show the layout quickly, not to mention visual builder.

The compiler, or more exactly the packager – “rapc” has many times weird problems and behaves like a whiny child with lots of attitude problems. Same goes for the MDS server emulator.

Compared to Android, this can be nightmare. Yes I’ve had some issues and observed buggy behavior with aapt while developing for Android, but it was quite easy to resolve. For the UI part of the development, Android beats Blackberry as well. Constructing layout using XML is much easier than writing actual Java code. (Apple had actually went one step furthergiving the developers visual tools.)

Localization is much easier in Android as well. Besides conceptually being easy, the support of the Eclipse plugin for localization is half baked and buggy and what’s most important, it is not that easy to find documentation on how to implement localization for Blackberry in Eclipse.

The last but not the least (and in fact probably most important) is the vibrant, enthusiastic and active community of the Android platform. It is so much easier to find answers to any problems you have while developing for Android. I was a little considered about Android being all open source in a sense that there is no central authority with central responsibility for certain things, and Blackberry has all this and it turns out that what many enthusiasts can do, easily outweighs any size company organized or not.