In my last post, I showed what is needed to get started programming for Android.  There’s a lot that goes into setting up your machine’s environment (SDK’s, IDE’s, Plug-Ins, etc).  Once that’s all done, you are probably ready to start programming in Eclipse.  My first obstacle I encountered was creating a new Android Project.

When creating a new project in Eclipse, you are presented with a “New Project'” wizard.  If you installed & setup all the items I mentioned in my last post correctly, you’ll have a new project type of “Android Project” in the “Android” folder.  It should look similar to below:

Once you’ve selected to create an Android project, your SDK mapping will kick in and the subsequent step of the wizard will populate all the build targets for you as well as present you with a ton of project creation options.  If you don’t have any build targets, you’ve not set your SDK location properly.  You can do this by going to Windows >> Preferences >> Android and fill in the SDK location.  Below are screenshots of the “New Android Project” step in the wizard.  I’m going to go over what these project creation options are.

Project Name:  This is the name of the directory where all the project files will reside.  This is an "Eclipse” thing.  Just make sure that your project name will be intuitive and unique.

Build Target:  This is basically the minimum version of Android which your application will run on.  Keep in mind that Android applications are forward compatible.  So if you choose Android 2.2, it will compile against the Android 2.2 platform library, but technically it should be able to be ran on  Android 3.0.  So choose your minimum supported version for your target here.  Pick the lowest version your application can support.

Application Name:  This is the title of your application.  This will be seen by your users on an Android device.  It is good to be descriptive, but keep it somewhat short.

Package Name:  This guy is a bit tricky.  It is the namespace which your application’s source code will reside under.  The tricky part is the realization that on Android devices, the package name MUST be unique.  So if two applications are running under the same package name (namespace) of “HelloWorld”… bad things.  As a result, there is a “domain-style” naming methodology that should be employed to keep things unique.  The suggestion is to always follow a “com.companyname.packagename” type of a naming model.  The “companyname” can be your organization, company, or unique name which identifies the developing entity.  I’ve also read that com.google, com.android, and com.example are reserved.  So stay away from those.

Create Activity:  This is a class that is auto-created by the plugin which is a subclass of Android’s Activity class.  The class is a stub which will be launched when your application starts up.  Other activities can be created from your application, but this is the first one that the user will experience.

Min SDK Version:  As I previously noted with the build target, you choose the minimum SDK version which your application will support.  This option tells what the minimum API level will be along with the minimum SDK version.  Each build target should have a corresponding API Level assigned.  Pick the API Level for the build target you previously chose.  So again, the Min SDK Version number will match the Build Target number for most applications.

In my previous post, I gave a brief overview of the current state of computing and why I felt that being an expert in .NET is not enough to effectively address the mobile market.  I chose to learn to develop for Android first.  Before I delve into what you’ll need to get started programming for Android, I’d like to go over a bit of background on Android.  This background will help you understand why you need what you need to get up and programming.

The core of the Android platform is ran on a Linux kernel which has all the drivers needed to run the display, camera, keypad, flash memory, etc.  On top of that, we have native libraries (OpenGL, SQLite, etc) and the Java virtual machine (JVM) which is responsible for interpreting and executing Java bytecode.  Android has its own JVM called the Dalvik VM which is highly optimized to run on low-end handled devices.  As applications invoke these core libraries, each application gets its own Dalvik VM instance to execute under.  On top of the Linux kernel and native libraries/VM, we have the Android Java API’s which include UI, package installs and security, telephony, locations, resources, graphics libraries, etc.  Basically the Android SDK supports most of the Java Platform but replaces the Abstract Window Toolkit (AWT) and Swing with it’s own fourth generation UI framework.  So from this architecture, we can assume we are going to need java and android software development kits, and an IDE to program, compile, and simulate such.

As a .NET developer, I am very familiar with Visual Studio and TFS.  I currently program in VB, however I do have a C# background as well.  It would be wonderful if I could leverage Visual Studio as my IDE along with already known programming languages to program for Android.  Technically, building Android apps can be done in Visual Studio either by getting creative with batch scripts and workarounds, using WinGDB, or by purchasing Mono for Android for $300.  Each of these solutions have some serious drawbacks such as spending money, no intellisense support, and larger application download size.  On top of this, most tutorials on the web are tailored for Eclipse for Java Developers, not Visual Studio.  On a good note, TFS can integrate into Eclipse with Microsoft Visual Studio Team Explorer Everywhere 2010.  As a result, I plan to stomach the pain of learning a new IDE and going with Eclipse for Java Developers.  I’ll have TFS integration, it’s free, most online tutorials will be using it, there is an ADT plugin which offers GUIs and wizards to assist in project creation, and I’ll have intellisense support.  The only unknown I have is TFS auto-builds.  A quick glance on the web appears to have some solutions, so I’ll cross that bridge when I get there.

Now that I know I want to use Eclipse as my IDE with TFS integration, I need to download and install the items I need.  Here are the steps that I took to get my development environment up and going on Windows 7. 

1) Install the Java Platform (JDK – Java Development Kit) – You need this to develop Java applications on your computer.  Download and install the 32-bit version as other items we will be downloading and installing will be 32-bit.
2) Add the JDK path to your System Environment Variables – This will allow you tap into executables provided via the JDK from the command prompt.  In Windows 7, you can do so by right-clicking Computer >> Properties >> Advanced System Settings >> Environment Variables >> User variables for xxxxx >> New.  Variable name will be “Path”.  Variable value will be the local path to where the JDK bin directory is.  On my machine it was “C:\Program Files\Java\jdk1.7.0\bin”.
3)  Install the Android SDK (Software Development Kit) – This kit will provide the libraries necessary for you to develop Android applications.  After you’ve downloaded and installed this, you should have the Android SDK manager application.  This will allow you to download and update the Android SDK libraries and components.  I went ahead and launched the program and had it install & update everything.  Warning: it took a long time to do this.
4)  Install Eclipse for Java Developers -  This is the IDE of choice for developing Android apps.  It’s free and plugins are available for Android and TFS.  Again, download and install the 32-bit version of it.
5)  Install the ADT Plugin for Eclipse (Android Development Tools) – You can download and install this plugin by navigating to Help >> Install New Software in Eclipse.  It should bring up a dialog which you can click the “Add” button which will bring up an “Add Repository” dialogue.  Within this window, you can give it a name of “Android ADT” and for the Location type in: “https://dl-ssl.google.com/android/eclipse/”.  Confirm, select all available components to install, and click through the wizard and it should download and install the ADT plugin into your Eclipse IDE.  For more information click here.
6)  Set the Android SDK Location in Eclipse – In Eclipse, you need to set the Android SDK location.  To do this, go to Window >> Preferences >> Android in Eclipse.  Browse to the Android SDK install location.  On my machine, it was “C:\Program Files\Android\android-sdk”.
7)  Install the TFS Plugin for Eclipse (Microsoft Visual Studio Team Explorer Everywhere 2010) – If you want to integrate TFS into Eclipse, you’ll need a license for Team Explorer Everywhere and need to download the “TFSEclipsePlugin-UpdateSiteArchive-10.1.0.zip” (or whatever version is the latest when you go to install it).  Like the ADT Plugin, you have to install the plugin by going to Help >> Install New Software in Eclipse.  This time, you can browse to your local disk and select the “TFSEclipsePlugin-UpdateSiteArchive-10.1.0.zip” file for the location instead of a remote URL like before.  You can add a project to TFS by right-clicking a project and going to Team >> Share Project.  The first time you run the TFS plugin, you’ll be prompted to enter your license key.  You should be able to take it from here.

So there you have it.  6-7 steps to setting up your machine to develop for Android.  Most of the steps are for setting up the Eclipse IDE.  It definitely is not the 4 hour install process that Visual Studio makes you go through, but it does require manual setup.  The nice thing is that all of this is free except for the TFS piece.  I already had an MSDN subscription so this wasn’t an issue for me, but it may be an issue for others.  In that case, you could probably find other options to use for your source control.

I’ve been programming for the last 10 years predominantly with Microsoft technologies and languages.  I can develop windows, web, silverlight applications & services easily in .NET.  The .NET Framework provides a great foundation to develop applications which can span many computing technologies and platforms.  Handheld devices (phones & tablets) is where the future end-user computing is going to be.  Unfortunately, knowing how to program .NET applications doesn’t appear to be able to assist much here.

The 2 dominant mobile operating systems are Apple’s iOS and Google’s Android.  Microsoft has tried to get in the market, but has had difficulty doing so.  My .NET skills can make mobile applications on Windows Mobile, but the OS is rarely supplied on new phones.  As of February 2011, Apple, Android, and Blackberry comprise of over 90% of the smartphone market in the US.  So even if you could use your .NET skills in the mobile market, you would be reaching less than 10% of mobile users.

Yeah, Yeah.  I’ve read and seen Windows 8 and its “Metro” apps offer.  But penetrating a mobile market that’s already dominated by Google and Apple will be no easy task.  And if they beat the odds, I already know .NET and XAML… so I can easy kick out a metro app if I needed to.

After sitting back and watching what has been happening in the mobile market over the last few years, I don’t think my .NET expertise is enough to sufficiently program for mobile users.  So it’s time to step up my game and tackle programming for a new OS:  Google’s Android.

Why Android?  Well, I think both Apples iOS and Google’s Android are here to stay.  Both are attractive and legitimate mobile operating systems.  In the end, I believe Google’s Android will reach more users and devices than Apple’s iOS and some statistics show that it already has in the smartphone sector.  ComScore reported for February 2011, the Android platform now accounts for 1 in 3 smartphone users.  Even more interesting, recent trends show Android has been taking more and more of the smartphone market share at an increasing rate.  February 2011 had Android taking the largest increase in smartphone market share over 3 months and is #1 at 33%.  Obviously trends may change, but this is showing that the Android OS has continued to grow at a rapid pace and has finally past Apple’s iOS on smartphones.

If you factor in tablets with smartphones, Apple’s iOS takes the cheese with 53.04% market share.  However Google’s Android did not come out with tablet support until 3.0.  Hardware manufacturers have not released a competitive tablet device with Google’s Android OS on it to successfully compete against the iPad.  That will eventually change.  Amazon recently announced it is going to release its own Kindle tablet running Android and more devices are sure to come.

So why do I think Google’s Android will have the higher mobile market share in the end?  Let’s look back in recent history to the 1990’s.  Apple has always controlled the end-to-end hardware and software product offering.  This yields a less buggy and better optimized product.  On the flip side, Microsoft had Windows that could run on many hardware manufacturers’ products.  Developers took to Microsoft’s OS & development technologies for many reasons and propelled it to have the dominant market share.  Is the mobile battle going to end the same way?  This time, Google’s Android is Microsoft's Windows.  I don’t necessarily think it will win out on innovation or quality of products, but it will prevail when it comes to market share.

So why is market share so important?  Apple could release the next new iPhone or iPad which rocks Android devices and trends could favor Apple.  I would agree that this will happen and things will go back and forth, but when it comes to developers developing applications, they typically stick with the dominant platform which will reach the most users and will be around a long time.  They also migrate to the platform which is easier to develop for.  Android is showing that it is a dominant mobile OS, is trending up, and it will be difficult to dislodge.  It’s SDK’s, IDE’s, tutorials are all free, easy to learn, and run on Windows as well as Mac.  As a result, I think Google’s Android will have the majority of market share both with smartphones and tablets in the not-to-distant future.

Companies looking to create applications will obviously want to develop a mobile application and reach users where they are at.  Because Google’s Android and Apple’s iOS is the majority of mobile operating systems, that’s where the work will be.

So, like I said, I’m stepping up my game and I plan on learning how to program for Google’s Android.  As a result, I plan to blog on it occasionally as I progress.  I’ve just got my 1,000+ page Pro Android 3 book from Amazon today… So here I go.  Weeeee.

In my previous article (part 1), I shared what an n-Tier architected application is and why you should familiarize yourself with the concepts behind them.  In this article, I will take this a step further and show you how you can create a simple n-Tier architected ASP.NET application using Visual Studio 2010.  I won’t create all the CRUD (create, read, update, delete) operations for the business objects, but it should give you a strong start to creating a simple multi-tiered ASP.NET application.

When we are finished, your Visual Studio solution will have the following layers:
1) SalesSystem.Web - ASP.NET website
2) SalesSystem.Presentation - Presentation Controllers
3) SalesSystem.BusinessObjects – Business Logic Layer (Objects)
4) SalesSystem.Core – Core Utility Objects

We will start by creating an empty Visual Studio solution and then adding projects to it.  Each project acts as a logical layer (tier).  Projects can reference each other via the use of project references.  When you build the Visual Studio solution, it will build each project for you automatically.  Before I show how to create an empty solution and add projects (logical layers/tiers) to it, here’s a brief explanation of what each project will do.

SalesSystem.Core – I used this project to contain generic utilities, functions, extensions, helpers, etc which can be used across any new application you may develop.  Think big.  You don’t want to reinvent the wheel if you don’t have to.  I thought I may be developing more web applications in the future, so a common task is reading connection strings from the web.config.  So I wrote a utility object for the web.config and put a base class to be inherited on all web pages in there too.  This project/assembly is used by each of our other tiers.

SalesSystem.BusinessObjects – I made this project to house all of my business objects.  I didn’t take the time to create an official DataAccess Layer… but business objects often are made to interact with one particular data source type.  In this case I am interacting with a SQL Server and the connection string to run the queries on is passed in via a connection string to still maintain a dynamic and flexible approach.  Regardless of merging the business objects in with data access routines, I am able to use these business objects going forward easily as long as the application (whatever type it is) supports CRUD operations on a SQL Server.

SalesSystem.Presentation – Okay, this project may be a bit confusing for most.  I made another tier/layer to act as the liason between the UI and business objects.   I have a couple of reasons for this.  First, it makes calls simpler from ASP.NET page code behinds.  An ASP.NET page can have one controller which does a myriad of tasks (page centric) on many types of objects.  Second, it will help with automated unit testing in the future if we decided to take it to that level.  Your presentation layer should essentially be presenting the UI and capturing data from the user.  The less “clutter” you can put in the presentation the better.  So using presentation controllers can assist here.

SalesSystem.Web – This project is the presentation layer and we are using an ASP.NET website to do this.  Our objective in this layer is to simplify the logic down to presenting and capturing data from the user.  Any business object acquisition or saving should be done through the controller.  This makes the UI code much cleaner and simpler.

Here’s what the final solution will look like:

Step 1: Create an Empty Solution – First we want to create an empty Visual Studio solution so we can add our projects (layers/tiers) to it.  Below is a screenshot on how to do this.

Step 2: Add Projects to the Solution – Next we want to add projects for each tier we want to our solution.  We have 4 layers that we want to develop, so we’ll add 4 projects to the solution which will facilitate logical layers.  Each layer may be a different project type.  For instance, the presentation tier (SalesSystem.Web) will be an ASP.NET web project.  However our core, presentation controller, and business projects will all be windows class libraries as they simply have .NET classes in them.  Below are screenshots to help facilitate how to add the projects to our empty solution.

Step 3: Add Project References – The final step to getting your ASP.NET n-Tier architected solution to work is to setup project references to each tier can communicate, consume, and/or interact with each other.  Think of project references as “inheritance”.  If you need to use a tier’s (project’s) functions or data types, you need to add a project reference (or inherit) from it.

SalesSystem.Web References - We know that SalesSystem.Web will need to make calls to the SalesSystem.Presentation controllers which will return objects from SalesSystem.BusinessObjects.  So the SalesSystem.Web will need project references to both projects.  It will also need a project references to SalesSystem.Core because that is our core project which we have our core objects & utilities that we can use everywhere.

SalesSystem.Presentation References – This tier doesn’t care about the UI.  It makes calls to the business object layer.  Therefore it only needs a reference to SalesSystem.BusinessObjects.  Again, add a reference to SalesSystem.Core as well.

SalesSystem.BusinessObjects References – This tier is only concerned with its own business objects and interacting with the database.  It doesn’t care about what presentation layer is employed to use them… so the only references you need is to SalesSystem.Core.

Here is how you add a project reference:

Step 4: Code – I’m not going to go into detail on how to code the tiers.  Instead I am attaching the solution which includes the code in each tier to acquire customer sales from the AdventureWorks database using our n-Tiered solution.  The end deliverable is an ASP.NET website which a page’s codebehind class makes a call to our presentation controller tier which makes calls to our business objects and back out again.

Summary - Imagine taking this application to the next level and offering a Windows WPF UI option.  We could reuse the same presentation controllers, core, and business object tiers.  We would simply replace the ASP.NET web presentation tier and most of our work would already be done.  If a call to the database was broke, we’d fix it in one business object and be done.  One place, one time.  We wouldn’t have to be searching through all code-behind files trying to locate every instance of the problem.  If you had a UI designer/coder, they could be designing the look of the web pages while you focused on the business objects and back-end tiers (parallelism).  There are many reasons why applications are constructed like this.

Hopefully this helps you get a good start to understanding n-Tier architected applications and how you can accomplish this in Visual Studio using logical layers with VS projects and project references.

n-Tier Architecture – Part 1
n-Tier Architecture – Part 2

SalesSystem_Soln.zip (792.10 kb)

Throughout my career, I’ve been a guest speaker and judge at local universities.  I’ve also interviewed many job seekers over the past several years.  As a result, I’ve noticed some areas of weakness new developers have when being thrown out into the “real world” of programming.  You’d be amazed at how many new programmers do not have experience with n-Tier architected applications.

So what is n-Tier architecture?  N-Tier architecture refers to an architecture which breaks up an application into separate layers (tiers).  A tier encapsulates methods, objects, properties, interfaces, technologies, etc to perform a set of predefined tasks.  Each tier is separate and thus can reside on other servers, networks, assemblies, namespaces, classes, etc.

For an example, let’s say we have a Silverlight application.  The Silverlight XAP is the presentation layer.  Our Silverlight application then consumes a web service which creates objects which run queries on our SQL Server.  The web service creates the business objects which are part of our business logic layer.  The objects then query the database through the data access layer.

There are many advantages to breaking up the application into tiers (layers) like this:
1) Avoid changing or recompiling other layers if one layer needs changed.
2) Reduction of complexity.
3) Promotes parallel development
4) Easier to maintain.
5) Works much better with automated testing.
6) Easier to scale.
7) Promotes code/tier reuse.
8) Helps with adoption of new technologies.

In our Silverlight example, we had the presentation tier implemented using Silverlight on the client’s web browser.  The web service, objects, and database interaction were done on the server.  Because these layers were “distributed” among multiple machines, they can be referred to as “physical” layers.  On the other hand, layers separated by assemblies or sets of classes can be thought of as “logical” layers.

Now that we know the basics as to what an n-Tier architected application is, in my next article I will show you how to create an n-Tier enabled ASP.NET web application using logical layers in Visual Studio 2010.

n-Tier Architecture – Part 1
n-Tier Architecture – Part 2