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.

So, what is essentially ad aggregation network you might wonder. You certainly know ad network businesses. Even if you think you don't, you encounter them everyday. One of the largest ad networks is the Google Adsense. Another example of huge ad network is DoubleClick, well, Google owns this one as well.

Publishers can sign up with an advertising network, place a snippet of code on their website, ad supported desktop application, or recently added mobile applications on iPhone, Android and Blackberry. Once the appropriate code snippet has been placed, the ads will start to flow to your visitors/users. You don't have to worry virtually about anything except how to drive more traffic to you website/application and optimize the ads to give you best revenue. And that in fact makes a lot of sense to the publishers, since worrying about those two is quite enough to begin with and should be the only concern of the developer and/or publisher. Using advertising network relieves you from worries about where to get advertisers, how to bill them, implement an advertising platform so that you can track what is going on with the ads  etc... etc...

Let's take a glimpse into the history of online advertising. (All said, also applies to software advertising as well, but online advertising accounts for such a large portion of the "computerized" advertising, that I will just mention "online" advertising).

Since the appearance of online advertising, certain companies understood that being the mediators between the publishers and advertisers is very solid and profitable business model and many companies made big utilizing this business model and still continue to make great profit out of this business.

Those advertising platform companies did not appear right away. There was a considerable amount of time when advertisers and publishers will "manually" find one another and negotiate rates. The usual business incentive quite unsurprising applied here as well. If you were a small publisher, it was up to you to try and find advertisers to sustain you online business model. However if you were reasonably large publisher, advertisers will line up for available space on your website.

You can imagine what a pain it can be to find an advertiser if you are a small web publisher. You would have to spend considerable amount of time solving this problem, instead of worying about improving your publishing media. This deficit was identified when the problem become large enough to be noticeable and to be profitable. Companies started to aggregate advertisers and publishers and act as a mediator (or the middle man) usually in highly transparent manner for both advertisers and publishers.

When you concentrate on doing one thing, you would usually do it much better than if you would be concentrating on doing several things.  Since those mediator businesses were concerned just about one task, they could offer much reacher experience both to publishers and advertisers, suplying advanced management and statistics tools. Advertisers were getting tools to make their campaigns target more specific audience and publishers in turn could receive much better revenue for the traffic.

Now we getting to the present where online advertising seems to be outgrowing the current model and requiring additional layer of aggregation. That's where the ad aggregation and mediation networks come into play. Those networks do what ad networks did in the past. They aggregate advertisers and publishers, but instead of direct aggregatio, those mediator networks aggregate another ad networks. Those are essentially meta ad networks.

It would be interesting to see how successful those meta networks will become with time. Right now it is too soon to tell.

This problem is similar to the missionaries and cannibals problem puzzle. One additional twist to the missionaries and cannibal problem in this problem is the fact that rather than being all the same, men and women have roles and although it appears to complicate the solution, it really does not.

Problem:

Three jealous husbands and their wives need to cross a river. They find a small boat that can contain no more than two persons. Find the simplest schedule of crossings that will permit all six people to cross the river so that none of the women shall be left in company with any of the men, unless her husband is present. It is assumed that all passengers on the boat unboard before the next trip and at least one person has to be in the boat for each crossing.

As I've mentioned in the problem statement, this problem is quite hard for humans and might be very easy for a machine to solve (with the right formalization of course). The reason is that this problem can contain infinitely many repeated states. If we don't keep track of states we have been in, we could easily end up going in rounds with the same man in the boat for infinity. Thus, we have to keep track of states we have been in, and do not repeat them, since getting back to them, means that all the "progress" we made has put us back, and therefore was useless.

Another thing to pay attention is that it really doesn't matter which one of the missionaries will we get into the boat first/second or third. This is also true regarding the cannibals. In fact this small note saves us a lot of states space, making this problem very simple indeed, when treated properly.

Therefore, if you still want to try solve it, try drawing all possible situations while not distinguishing any importance given to the order between different missionaries and cannibals, and keeping track of repeated states as well.

Solution:

MMMCCC  |   |

Missioner and a Cannibal go, Missioner comes back

MMMCC  |   |  MC      MMMCC  |   |  C

Two Cannibals go, one comes back

MMM  |   |  CCC    MMMC |   |  CC

Two missioners go, Missioner and a Cannibal come back

MC  |   |  CCMM     MMCC  |   |  CM

Two missioners go, the cannibal brings the boat back

CC  |   |  CMMM    CCC  |   |  MMM

Now all the cannibals can get to the other shore easily one by one: two go, one comes back.

I've encountered some interesting problem which is famous mainly because it has much to do with AI (Artificial Intelligence) development. The problem is called "Missionaries and Cannibals". The description is:

"Three missionaries and three cannibals come to a river. A rowboat that seats two is available. If the cannibals ever outnumber the missionaries on either bank of the river, the missionaries will be eaten. How shall they cross the river?''

The following statement  - "If the cannibals ever outnumber " means that cannibals can't outnumber missionaries while counting anyone in moored boat. (otherwise the problem is simple)

The problem has an elegant and pretty easy solution, yet it is usually hard to humans because humans don't do a formalization of the problem which leads to many repeated states. This issue is mainly why this problem is popular. Amarel (1971) considered several representations of the problem and discussed criteria whereby the following representation is preferred for purposes of AI and why this problem is hard for humans.

Solution

1) If you understand it and can prove it, then send it to a journal of mathematics.
2) If you understand it, but can’t prove it, then send it to a physics journal.
3) If you can’t understand it, but can prove it, then send it to an economics journal.
4) If you can neither understand it nor prove it, then send it to a psychology journal.
5) If it attempts to make something important out of something trivial, then send it to a journal of education.
6) If it attempts to make something trivial out of some-thing important, send it to a journal of metaphysics.

I think that I will be not the only one and definitely not the first one to claim that recursion is a an educational milestone in Computer Science disciplines. When it comes to understanding recursion, that's one of the "truth moments" in your Computer Science career. If you don't feel comfortable with recursion and don't understand it - you should probably leave the field. Some people claim the same about pointers, but well, even when I find it to be true, nowadays pointer arithmetic plays much less significant role then before, when computer had several hundreds of kilobytes of memory and being able to do pointer arithmetic was considered  a "must master" for any programmer. I guess at a time there was really no other choice at all.

This leads to much more interesting and broader subjects. I remember those times when we were talking of buying 512MB of RAM, creating a RAM-drive and loading there Windows98, so it will run smoother. Well, we were just kids at a time. Nevertheless what I wanted to say was about recursion.

Every CS student has heard at least once during his career "Recursion is cool, however - DON'T use it!". Some might wonder well, why is it so? Well - in fact the recursion is cool indeed, BUT is slow as hell! I have compared just for fun some code that was using a recursion versus non recursive code, and it appeared that non recursive code was about 10 times (!!!!) faster for significant amount of computation. And when I say significant, I mean several hours of runtime.

One must ask - but why? And the answer would be - this is due to stack frames allocations of course. It turns out that it is quite costly to open a new stack frame. I believe there are other reasons as well, which maybe depend on the programming language, but this would be the most obvious one. So kids, don't say I didn't warn you - don't try this at home!

Problem:

How can we choose one out of 3 christmass presents with equal probabability?  Or in other words how to obtain 1/3 probability by using one unbiased coin ?

Solution:

1. The coin is UNbiased: toss the coin twice. Let TH, HT and HH correspond to each of the presents. In case of HH - repeat from the beginning.

2. The coin is biased, then we notice that TH and HT would occur with equal probability but this will only give us 2 possible outcomes with equal probability and we need 3.  Then we would have to use 4 tosses which will give us 16 possible combinations. The question is which ones we should choose to represent the presents (or outcomes). The only condition is that the number of H and T should be the same to ensure equal probability for each outcome and thus selecting each present with the same probability. One option would be to assign HTHT, THTH and HTTH to the three choices, with other  13 possible 4-toss outcomes being rejected.

Discussion:

So the obvious problem is that we need some way to extrapolate tosses of a single coin to (possibly) arbitrary number of outcomes with equal probability to obtain each outcome.  So obviously we will need several tosses to match the number of outcomes we need. However we need to pay careful attention to the fact that the toss sequences we are using have the same combined probability such as HHTT and HTHT

1. How can we choose one out of 3 christmass presents with equal probabability? Or in other words how to obtain 1/3 probability by using one unbiased coin ?
2. Solve the previous problem if the coin is biased and the bias is uknown.

Solution