I happened to see a link to a study made by visionmobile (http://www.visionmobile.com), a market analysis and research company, made in July 2011 comparing different open source projects amongst a variety of predefined factors that constitute on how “open” a project is.

This is by far one of the most balanced studies I’ve seen comparing successful (and unsuccessful) well-known open source projects. Incidentally, visionmobile’s clients include HTC, Sony Ericsson, RIM, Microsoft, Intel, etc as part of it’s well known client lists.

Their quantification of “openness” between selected mobile open source projects (both successful and unsuccesful, single sponsor and multi sponsor) is called as the “Open Governance Index”.

The results were particularly interesting:

Among the 8 open source projects listed, Eclipse was the most “open” of all the projects, and Android was the last in the list. The research paper however noted that Android is also one of the most successful projects in the history of open source. It was contradictory enough that the paper called it the “Android Paradox”.

A number of interlinking factors were cited what made Android successful:
1. Google’s financial muscle and marketing.
2. Android’s “zero cost” subsidy by Google, since Google’s ultimate purpose is to drive more eyeballs to it’s ad inventory, which results to cheap handsets and low cost internet connectivity.
3. The adoption of the Open Source project by different manufacturers in order to compete against Apple’s iphone. The OEM industry generally poured billions of dollars into Android in order to compete with the Cupertino company’s product.

In retrospect, the research paper acknowledged that in the long term, platforms with the most open governance will be the most successful. Cited success stories are Eclipse, Linux, WebKit and Mozilla. Meego has the capability to become a successful project in the long term, in my opinion.

It also went to suggest that making a project open doesn’t necessary warrant a successful community builder. They stated that Software developers are human in nature and self-centered; and will only take interest in such a project if it provides value or addresses a common need – citing Linux, GTK or Webkit as an example (need for a vendor-neutral operating system, graphics software stack, browser engine). Symbian failed in this aspect; they failed to target developers (besides this, no proper development tools, complex contributions structure, etc).

What does this mean for Android and competing open source projects such as Meego?

Android was successful because aside from the factors stated above, when Android was released to the developers, the product was already a very advanced, and complete project (by and large due to Google’s famed engineering team):

However, there are some very good lessons for us to learn from how Google has managed the Android
open source project. First, Android was released as an open source project at a point in time where it
was already a very advanced, complete project. OEMs, operators and software developers could more
or less immediately use it to create derivative handsets and applications. Second, Google kickstarted a
developer buzz around the project with the $10 million Android Developers Challenge. Alongside
financial incentives, Google provided a very strong emotional message: that of opening application
development within a previously inaccessible mobile industry. Finally, Google’s speed of innovation
(five platform versions across 2010) outpaces any external innovation, and makes the ecosystem
entirely reliant on Google.

On the other hand, when Meego was announced, it was basically starting from scratch (okay, not exactly scratch, but the earliest versions of Meego were in the command line from my perspective) – try to imagine that they essentially went from a deb-based packaging solution (Maemo) to an rpm based one, and shifted from GTK/clutter to mainly Qt. This was one of the disadvantages I saw with the early development of Meego, and I have to say most likely hampered it’s early adoption (I do like the very open way the meetings are held though – I’ve been in one of the developer meetings in the past; but due to time zones it’s really difficult for me to attend it). It has gotten way better though; with the inclusion of non-Nokia/Intel people into the upper build team, the development process is getting to a point where I believe that this operating system will likely pick up pace and steam in the very near future (it has a bright future ahead in IVI systems in vehicles for example, and the upcoming N9 is positively received by many).

I’m back, and I’ve got a little time on my hands. Let’s continue on how to use the spelldial php class now in an android phonegap application.

Now, let’s look at the actual php code that will make the spelldial call based on what your android spelldial app will send:

You can save this code snippet in a file named droidspell.php:

include "spelldial.php";
$spell = new Spelldial();
$result = $spell->get_info($_POST['spelldial'],$_POST['calltype']);
if($result->error_code !== '0')
{
die("error");
}
echo $result->content[0]->info[0]->uri;

This is a typical use of the spelldial class I made (this uses post variables spelldial and calltype, ie. tel or skype to determine what to return as output to the android application).

Now for the html code snippet:

<script src="jquery-1.4.2.min.js">jquery-1.4.2.min.js</script>
<form id="spellform" name="spellform" method="post" action="http://yoursite/droidspell.php">
<table width="300" border="0" cellspacing="0" cellpadding="0">
<tr>
<td height="27" colspan="2">SpellDial Name</td>
</tr>
<tr>
<td height="31" colspan="2"><label>
<input type="text" name="spelldial" id="spelldial" />
</label></td>
</tr>
<tr>
<td height="42" colspan="2" valign="top"><label>
<select name="calltype" id="calltype">
<option value="TEL">Telephone</option>
<option value="SKYPE">Skype</option>
</select>
</label></td>
</tr>
<tr>
<td colspan="2"><label>
<input type="submit" name="dial" id="dial" value="Call me using SpellDial" />
</label></td>
</tr>
</table>
</form>
<script>
$("#spellform").submit(function(event) {
event.preventDefault();
var $form = $( this ), spelldial = $form.find( 'input[name="spelldial"]' ).val(), calltype = $form.find( 'select[name="calltype"]' ).val(),
url = $form.attr( 'action' );
$.post( url, { 'spelldial': spelldial, 'calltype': calltype },
function( data ) {
if(data == 'error' || data == '')
{
alert('Spelldial API returned an error: '+data);
} else {
location.href = data;
}
}
);
});
</script>

As you may see, this is typical html form/jquery event code to get the result of the droidspell.php call and then determine if an error occurred and if not, go ahead to the android dialer to make a call.

You’ll see some stuff like jquery-1.4.2.min.js in the code above. Where is it placed? It is placed where the index.html is placed in the assets/www folder:

If you want to use the phonegap wrapper functions place this snippet in the <head> portion of your index.html file:

<script type="text/javascript" charset="utf-8" src="phonegap.0.9.6.js"></script>

You may rename phonegap.0.9.6.js to phonegap.js if you wish.

This is how a finished phonegap application looks like in the emulator (yeah yeah, ugliness noted, I made this quickly!):

Once you see this application running in your emulator, you might want to package this application into an apk. Simply right click on your project in the project window and select Android Tools->Export Unsigned Application Package – once you follow the instructions, this will create an unsigned apk file for you automatically.

You can also create signed apk files for distribution into the Market. For further reference, please see http://developer.android.com/guide/publishing/app-signing.html for details.

And there you have it, we have now made an android application in phonegap using the spelldial php class, tested it in an emulator, and published it as an apk file.

Well, it’s a short post.

Since I was around the area and was more or less free during the time, I attended a short meeting with a local Linux Users Group at the G2iX Techbar, IT Park, Cebu City, of which I am a member.

There was basically a short talk on Liferay, an Open Source Portal, Collaboration, Social Networking tool written in Java. After the talk was a discussion between the members about activities within the year.

Like I said, nothing much. People like Tom Wickline, head of the Bordeaux Group (a front-end to WINE), and writer to Wine-Reviews attended the meeting.

It also allowed me to show off my netbook running Moblin.

For those who don’t know who G2iX is, they’re a company headquartered in Manila, and specializes in Ruby on Rails development, Java, Dev Automation and Cloud Platform Deployment. They have also received awards like the Top Asian TechnoVisionary Awardee for 2006/2007 by ZDNet Asia, Top 20 Open Source Companies by Red Herring, among others.

We all have our favorite plug-ins for our browsers. Many people can’t live without their flash plug-in for their games and watching Hulu and YouTube videos. Other people use Java applets for their enterprise applications. Still, others use Quicktime for watching .mov videos on the browser.

What happens if a rogue plug-in runs in your browser? This is when sandboxing plug-ins become apparent.

Sandboxing applications have had it’s purpose and use in Java applications, especially plug-ins, where the program is placed in a restrictive environment that is not allowed to access system functions unless it is given access to.

This allows the plug-in to run in it’s own environment without harming the other browser or system processes.

How is sandboxing applied? Either through the plug-in itself (like java, and in a lesser way, flash), or through the browser.

Newer browsers such as Google Chrome separate their browser windows through threads, allowing rogue plug-ins to crash the affected window only. Other browsers implement some sort of sandboxing of their plug-ins. Which is better?

Since most people are in the fad of flash-bashing these days, let us make a sample of a rogue flash application that crashes the browser. Here is the link.

Mind you, I would say that flash has its uses; however as someone who dabbled in ActionScript one time or the other knows that the Flash runtime has a number of quirks and bugs that are really downright bad. In my opinion, this example is one of them.

Browsers who do not sandbox their plug-ins or separate their windows as separate threads would find this page crashes their browser really bad.

This includes Firefox, IE and Safari.

The only way to avoid spectacular crashes is to use a browser which implements some sort of separation between the plug-in and the browser itself.

Opera and Google Chrome passes this test admirably.

Interestingly, due to the flash plug-in running in a separate process in 64 bit systems in Linux (through nspluginwrapper), only the nspluginwrapper crashes, and does not take the whole browser in it.

To end, this is what I like to see implemented in all browsers. Running plug-ins in a separate process, as well as limiting it’s scope in relation to access to the underlying operating system.

Here’s an interesting take into how to make an open source program. This should make a good case study on how to plan out and develop a program for distribution to the open source community.

Presenting Binary Clock – a GPLed java program which shows the time in binary. This is a simple java midlet made for nokia phones (from what I’ve heard, it runs on samsung phones too).

Anyways, here are the steps (illustrated):

1. Decide on what you want to do with the program.  You can then make a mock drawing on a piece of paper on how the program will respond like what is shown below:

2. You would also have to determine the target audience for your program.  In this case, we target mobile phones, mainly nokia phones.  To do this, you would have to have appropriate tools for the job ready.  Shown below are the tools used to make the program (testing and design).  Note that all these tools run in linux (although there are windows versions available, except for Fireworks which is a windows program); Fireworks was run in wine (yes, it does run, for those who are curious).

The final design from the Fireworks layout is below:

3. Since we have tested this in our emulators/sdk, it is now time to test it by ourselves with our available hardware.

Click to Watch!

Click to Watch!

Click to Watch!

4. When you feel that it is more or less ready to be distributed, you announce it to the world, and allow other people to modify and enhance our code.

Many thanks to Daniel Rindt of Visetics (http://www.visetics.com) for sharing the development workflow and the actual program with me.  To get the actual source code, please get it here.