Android vs WP7

After a short stint in android development, I thought of experimenting with a different mobile platform. I didn't have too many options. iPhone development was ruled out since i did not have a mac and wasn't quite comfortable with Objective C. I chose WP7, hoping to catch up with C# coding which I haven't been doing for a looong time. And moreover the latest buzz about the next version of windows phone, Mango added up to the excitement to see what it offers to the developers. I made up my mind and setup the environment  and started off with a simple BMI calculator application for WP7 and android. Here is the summary of stuff that I discovered last week.

Android	Windows Phone 7
The multiple screen sizes are handled by android itself. The developer is concerned with following the best practices to support this.	Though only two screen sizes are possible, you need to code differently for them. Even conditional statemenst in code and different xaml files might be required to cater different screen sizes.
The template editor is still basic. Throws up exceptions when background of an element is set to an xml. Needs a lot of improvement in this area.	Has a very decent template editor - more similar to what we've seen and used to design the template for VB and C# windows applications. It is very dynamic and responsive to changes in xaml file and vice versa.
Though you'll find some surprises its easy to draw analogy from web development.	Silverlight is used for development. Requires too much of code to achieve even the simplest functionality.
Takes a good amount of time to setup the eclipse plugin and android SDK. But once setup development and testing in emulator is much faster than WP7	Setting up the environment takes more than three hours and the tools are pretty slow if you are developing and testing it in the emulator frequently.
Costs only $25 to register as an android developer and start publishing.	To publish an app in the marketplace, you need to pay an annual subscription fee of $99

The source code for android and windows phone are available in github.

Ruby - Gems - Manage dependencies

Had a chance to work on a Ruby on Rails project recently. It is almost impossible to have a ruby application without using any gems. Gem is a packeged ruby application or library which can be used in other applications (equivalent to a jar in a java project). You can specify the gem dependencies for your application in the Gemfile. The bundler takes care of resolving the gem dependencies of the application for you. It makes sure that the same version of gems are used in all the machines/environments wherever you develop/deploy the application.

Still, you could run into the problem of nested dependencies not being resolved, as I did. My application was dependent on a gem (say Gem-A), which was dependent on another gem (say Gem-B). You'll naturally expect the bundler to resolve this and install Gem-B for your app. But the bundler failed to resolve this in my case.

Let's take a small peek into how gems are built. Gems are ruby projects in themselves. In case of  a gem, you have another place (apart from the Gemfile) where its gem dependencies should be specified. Enter the gemspec file. The gemspec file contains the specification of the gem, like the name, version, authors. A sample gemspec file would look like this:

Gem::Specification.new do |s|
  s.name              = 'my_gem'
  s.version           = '1.0.0'
  s.authors           = ["Me", "Myself"]
.
.
.
  s.add_runtime_dependency      'activesupport',  '~> 3.0'
  s.add_development_dependency  'rails',          '~> 3.0'
  s.add_development_dependency  'rspec',          '~> 2.0'
  s.add_development_dependency  'rake'
  s.add_development_dependency  'sqlite3'
end

If any application is dependent on 'my_gem', the bundler will look at the runtime dependencies from the my_gem.gemspec file and it'll install the 'activesupport' gem as well, since it is a nested dependency.

Coming back to the problem in hand, the root cause was in the way Gem-A has specified its dependencies. It has added Gem-B as a dependency in its Gemfile, but hasn't specified it as a runtime dependency in its gemspec file and hence the bundler cannot identify Gem-B as a dependency. To resolve this, I had to add Gem-B as a dependency to my application as well.

It is a good practice to specify your runtime and development dependencies in gemspec and include it in your Gemfile, while developing gems. Your Gemfile will look something like:

source 'http://rubygems.org'
gemspec
gem 'ruby-debug',   :platform => :ruby_18
gem 'ruby-debug19', :platform => :ruby_19

This will save a lot of time for the developers who use your gem.