Ebooks are up on the market!

Locktech app's available on the android market :

Ebook Think and Grow Rich Free

Ebook The Law of Success

Ebook The Prince, Machiavelli

Ebook Goody Two Shoes

Notebooks Leonardo Da Vinci v1

Check them out, feedback/bugs etc. post in the comments!

Android Development - Getting Android source code

Getting access to the android source code is not as straight forward as it may seem for an open source project. No source is shipped with the SDK tools and using eclipse you only end up with the decompiled skeletons generated from the binary platforms jars when you try to look at the code definitions.

Get the Source. There are a number different ways to get the source, as you will need to grab the version which is consistent with what you are coding. Using git you can clone the source tree and then open up the branches which are appropriate to the SDK you are developing against.

Clone the git tree using the following command :

git clone git://android.git.kernel.org/platform/frameworks/base.git android-base

The syntax is git <command> <source>  <target-dir>. So in this example the frameworks/base repository would be downloaded to "./android-base". At this point the head(master) version of the code will be availble to browse.

Browse the full android git repository here

Get the SDK version. Now a local copy of the repository is available you need to get the appropriate SDK version.

To list the branches available remotely run the following command from the directory you cloned base.git to (android-base in above example) :


git branch -a

This will show the list of branches with the star being one currently checked out.

* eclair
  eclair-release
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/cdma-import
  remotes/origin/cupcake
  remotes/origin/cupcake-release
  remotes/origin/donut
  remotes/origin/donut-plus-aosp
  remotes/origin/donut-release
  remotes/origin/donut-release2
  remotes/origin/eclair
  remotes/origin/eclair-passion-release
  remotes/origin/eclair-release
  remotes/origin/eclair-sholes-release
  remotes/origin/eclair-sholes-release2
  remotes/origin/froyo
  remotes/origin/froyo-release
  remotes/origin/master
  remotes/origin/release-1.0


To then move to the branch version for the SDK you are developing against run :

git checkout eclair-release

For the command line averse another way to do this is to add the repository in eclipse. In the Git Repository Explorer perspective right click in the Git Repositories panel elect Add Git Repository :

Browse to where you cloned the git repository to on your local machine and select the repository, and hit ok, eclipse will import the repository. Now if you open up the repository and select the branch that corresponds to the SDK you are developing against :

So for example Android 2.1 (SDK 7) corresponds to the branch eclair release. Right click and select Checkout this will revert all the source code in the repository to how it was at the time of the branch.

This should then allow the source code you browse (with or eclipse or from the file system) to match up with the exception line numbers being thrown from the dalvik VM <if your code throws exceptions :-) >.

Android Development - Selecting a phone.

 At some point during your during your first android development project you are going to have to break away from the emulator and do some real world testing of your new app. For this you are going to need at least one android phone.

The gaps between a real phone to test and the emulator are significant, and it will save much development time if hardware testing is done before release.

One of the main gaps is how your app will react to the user events via actual hardware. Screen events from the emulator are an approximation of what actually happens on the device at best, for example responding to a single tap on the screen corresponds to a single mouse click on the emulator, but you will find on an actual device multiple touch events are received even for a very  brief tap on the screen. Also the other hardware sensors like the accelerometer and compass are often quite difficult to emulate so going to the hardware can speed up development.

A large part of the decision process for selecting a phone will depend on the different phone models availability in your location and your budget, this guide will focus on general advice and resources rather than specific models.

Check the hardware. There is a significant segmentation in android hardware with screens ranging from 240x320 to 480x800 and processors from about 400MHz. to 1GHz. ram can be anywhere from 128MB to 576MB currently and this will have a big impact on the performance and upgradeability of the device, as there is talk of android 2.2 not being supported on devices with less than 256MB and there are also rumours that android 3.0 will need 512MB. The type of touch screen (resistive or capacitive) will impact how sensitive the screen is and its general useability. As a general guide go with the following :

Screen >=  320x480
Processor >= 528MHz.
Ram >= 256MB.

A capacitive screen is generally preferable to resistive also check whether the screen is capable of supporting multi touch. Check the model your after has the other sensors/connectivity (accelerometer,  gyroscope, compass, GPS.

If you go for a high end device (480x800, 1GHz, >512MB) you should be fairly confident it will be supported up until android 3.0 after that who knows though.

Check the Android version.  This is heavily dependent on the manufacturers, For some phone models the android version the phone was released with will be the only version it ever gets, other manufacturers are more proactive with supporting older devices (where a device is considered old after 6 months!). It is crucial to check how well supported the phone is by the manufacturer so you are not stuck with a legacy device. A lot of phones are still being sold with 1.5 (Feb 2009) and 1.6 (Sep. 2009) versions of android which are pretty long in the tooth when the current version 2.2 was released in May 2010. If you are building apps to support the maximum number of users an older android version does give you a lowest common denominator approach so designing and testing on a 1.5 device might give you access to a larger user base than designing for the latest and greatest version.

Check the forum support.  A popular phone with very active forums will be a lot easier to get along with than one that is unique to yourself, as you will have to solve every problem on your own. Phones with very active forums will often be easier to root which gives you access to wider variety of software and they will also often have custom roms available which will may allow you to upgrade a 1.5 device to 2.1 (for example) even though the manufacturer has not released any updates.

Here are a couple of good starting points:

xda-developers
modaco

Also as a rule of thumb the googles current phone model (Nexus One) gets the latest versions of android well ahead of other manufacturers and offers few barriers to providing an excellent development experience.