Cross platform development for mobile application

1. Phonegap and Cordova

Hybrid app

The relation between these two: ; Basically, the phonegap is a distribution of Cordova.

The project (JIRA) page of Cordova:

Phone gap gives you more service:

Comprehensive documentation:

Phong gap build:

Phone gap command line build and run:

Test and debug phone gap apps

IDE(The AppLaud Eclipse plug-in):

Using Weinre and log:

Testing library: Qunit, Jasmine (

Debugging web app on Android:

Java script debugger:

How to use eclipse to debug by jshybugger :

PhoneGap plugin:

One of Phonegap feature, hydration:

There are many mobile web UI gadget framework works on Phone gap:

(i) jQuery Mobile

(ii) Sencha Touch

(iii) GwtMobile(Google Web Toolkit)

Tips for building phonegap apps:

Pros and cons of Phonegap:


Major change on 1.0:

The CSS and HTML are gone:–css

the JavaScript Runtime environment of a Titanium Mobile application:

3. Comparison

Comparing Titanium and PhoneGap:

A thread with detail discussion about both phonegap and titanium:

4. Self-Written

Creating Native UI using javascript and HTML:

Pros and Cons and a primer for hybrid apps:


MIME type is likely to be lost along the way…

In this post Peter Eastman has shared his experience of creating a customized type for his own application and shared from web/email client to his application. In his post, he explicitly mentioned that how the MIME type defined by him will be lost by email client.

Unfortunately, there are lots of other cases that don’t work.  Here’s a really basic one:

Open the email on your computer and save the attached file to disk.Now attach it to a new email.  This causes the MIME type to be lost.When you open that email in the Gmail app, the Preview button is no longer there.  It seems that when an attachment doesn’t have a MIME type specified, the Gmail app doesn’t let you do *anything* with.  Not view it, not even save it to the sdcard, which is just ridiculous. That really needs to be fixed.

Of course, what Android really needs is a way to define custom filename extension to MIME type mappings.  Then this whole issue would go away.  But as far as I can tell, there’s no way to do that.

Here’s another case that doesn’t work: view the email in the Browser using the Gmail web interface.  The URL it provides to download the attachment doesn’t include the attachment name, nor is the MIME type specified.  Hence, you can’t open it in my app.


The same thing will happen if you expect to use file browser on the market to open a file with extension/MIME type defined by yourself. The detail is in this post:


How to write intent filter dealing with MIME type problem

As mentioned in previous post, the intent object may or may not contain MIME type in it. As Android will compare MIME type when matching intent and intent-filter, it will raise a problem when writing the intent-filter. This post answer the question.

You need multiple intent filters to address different situation you want to handle.

Example 1, handle http requests without mimetypes:

    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.BROWSABLE" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="http" />
    <data android:host="*" />
    <data android:pathPattern=".*\\.pdf" />

Handle with mimetypes, where the suffix is irrelevant:

    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.BROWSABLE" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="http" />
    <data android:host="*" />
    <data android:mimeType="application/pdf" />

Handle intent from a file browser app:

    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="file" />
    <data android:host="*" />
    <data android:pathPattern=".*\\.pdf" />

A limitation in Intent-filter of Android Application


The android team chose an unfortunate way to implement pathPattern. You can take a look at how the pattern matching is implemented in the android.os.PatternMatch class:

We’re used to .* working like it does in a regular expression, where the * match is greedy and will match as many characters as possible. In PatterMatch’s implementation, the match is not greedy. The .* will match as many characters as it can, until it finds a match for the next character in the string.


String: “/mnt/my.file.mytype”
pathPattern: “.*\\.mytype”

The “.*” in the pathPattern will match the substring “/mnt/my”, and hence will fail to match the string.

Given this limitation, I don’t see a way to write a pathPattern that can match any string that ends in “.mytype”. The best you can do is follow Jason’s solution to add additional patterns to match paths with as many dots as you are willing to specify patterns.

Jason’s solution:

I found I could just add multiple “data” elements, depending on how many dots I expected to have in my paths:

            <data android:pathPattern=".*\\.mytype"/>
            <data android:pathPattern=".*\\..*\\.mytype"/>
            <data android:pathPattern=".*\\..*\\..*\\.mytype"/>
            <data android:pathPattern=".*\\..*\\..*\\..*\\.mytype"/>

Ugly, though. Anyone know a better way?

Some trick about intent-filter

1. Some broadcast receiver cannot be declared in intent-filter

See a related post here:

Android does not seem to support manifest-registered receivers for cases where they really do not want to start up a new process. For example, you will see the same effect with the battery info actions (e.g., BATTERY_LOW).