1. Make sure you have rooted your phone. This is complicated and I won’t go into it here – it differs based on what phone model you have. Search XDA for advice.
2. Make sure you’ve explicitly given the adb process attached to your phone access to root.

So, even after you root your phone, when you then connect via adb it will prompt you ON THE PHONE to allow access.

Click “Allow” and then you’re good as gold.

To remedy this you must put your phone into “Charge Only” mode before connecting it to your pc. To do this you need to go to “Settings->Connect To PC->Default Connection Type” and select “Charge Only”. Other options here are “Disk Drive” and “USB Tethering”. Once you’ve done this you’ll be able to run “adb shell” and then your attempt to run “cd sdcard” will succeed.

1. doInBackground : this is where the meat of your background processing will occur.
2. onPreExecute : show your ProgressDialog here ( showDialog )
3. onPostExecute : hide your ProgressDialog here ( removeDialog or dismissDialog )

If you make your AsyncTask subclass as an inner class of your activity, then you can call the framework methods showDialog, dismissDialog, and removeDialog from within your AsyncActivity.

Here’s a sample implementation of AsyncTask:

class LoginProgressTask extends AsyncTask {
    @Override
    protected Boolean doInBackground(String... params) {
        try {
            Thread.sleep(4000);  // Do your real work here
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return Boolean.TRUE;   // Return your real result here
    }

    @Override
    protected void onPreExecute() {
        showDialog(AUTHORIZING_DIALOG);
    }

    @Override
    protected void onPostExecute(Boolean result) {
        // result is the value returned from doInBackground
        removeDialog(AUTHORIZING_DIALOG);
        Intent i = new Intent(HelloAndroid.this, LandingActivity.class);
        startActivity(i);
    }
}

<VideoView android:layout_height="wrap_content"
		android:layout_width="wrap_content"
		android:id="@+id/videoView"/>

Then I prepared the video and added it to my project as follows:
1) Convert your video to either gp3, mp4 or wmv format. (Yeah, wmv works surprisingly. avi and flv do not work ).
2) Copy the video into your project’s res/raw folder. For example’s sake, I’ll say the video I copied there is named “my_video.mp4”
** Android will detect this and create a static resource ID for you named R.raw.my_video – you will use this (and not the file name) when building the URI to play your video.
3) Add code in my Activity that would lookup the VideoView, set the URI and start the player:

        VideoView vv = (VideoView)this.findViewById(R.id.videoView);
        String fileName = "android.resource://" + getPackageName() + "/" + R.raw.my_video;
        vv.setVideoURI(Uri.parse(fileName));
        vv.start();

There you have it…

Cloudera Hadoop Training: Programming with Hadoop from Cloudera on Vimeo.

To get apache web server with php/mysql support installed I just ran:
yum install httpd php-mysql
This is every bit as easy as apt-get. Making some really good progess. So, the first time around I terminate the instance and figure I’ll pick up where I’ve left off.
The next time when I come back to the AWS console – my instance isn’t there for me to restart. Now, here’s the thing with the EC2 server instances :

WHEN YOU TERMINATE AN EC2 INSTANCE, IT’S LIKE YOU STUFFED THE CASE WITH TNT AND THREW IT INTO A CAMPFIRE.

That’s right, terminate doesn’t mean power-down. It means obliterate. Anything on the drives is G-O-N-E.  It is no more – it’s an ex-instance.

That was rather eye-opening.  So, back to the drawing board and this time, to be safe, I made sure to pick an AMI with EC2 utilities installed on it already.   I installed my software on the instance and this time even registered the services to startup automatically.
service mysql start
service httpd start
I restarted the instance and tested that it came back up with apache and mysql running – it did.  Good enough – it was time to save this instance as an AMI into one of my S3 buckets.  After a bit of finagling I found the correct couple of incantations.
ec2-bundle-vol –cert publicCert –privatekey privatePem –user awsAccountNumber
The above command will create an imageManifestXml which you’ll use in the following statement:
ec2-upload-bundle –bucket s3BucketName –accessKey awsAccessKey –secretKey awsSecretKey –manifest imageManifestXml

This took maybe ten minutes to run both of the above, but afterwards I had new starting point AMI to use – in theory at least…

I double checked everything by starting another instance ( before shutting down the good one ) with the new AMI and making sure that it passed snuff – which it did. I shut down both instances and retired for the night – all of this to save 10 cents an hour. But more importantly it is to understand the process. No, it’s the money
This virtualization stuff is really powerful – I’ll write some more on mounting Volumes and using existing Snapshots of open-sourced datasets soon.

So, we currently use JQuery-1.2.6 and JQueryUI-1.6rc2 and I really like them a lot.  Oh yeah, we still have Prototype in the mix and it’s version 1.6 ( which is lots better than 1.5 ).

I recently, however, had issues with attempting to port new code back to a previous install.  The new code was using JQueryUI, and the old code was on Prototype 1.5 and JQuery 1.1.3.1.  Well – it took me a while to figure this out ( and I mentioned it already above ), but there is NO JQueryUI version compatible with JQuery-1.1.3.1.  It wasn’t created until the 1.2.x branches of JQuery.

So – here’s the compatibility matrix for Prototype, JQuery and JQueryUI for any of you who care:

Ciao.