MiamiCoder

Computerworld’s recent analysis Five Web 2.0 app dev lessons for enterprise IT shows how we can’t seem to stop the tendency to re-discover and re-name things that have been with us for quite some time. The analysis asserts that quick and incremental updates along with user involvement are the main characteristics of a new software development paradigm, a new process some call “application development 2.0”, championed by a new generation of Web 2.0 start-ups.

“Application development 2.0” is seen in contrast to what in the analysis is called the “traditional corporate waterfall process”, suggesting that the former could reduce development costs and improve quality, if corporate developers and managers are willing to make “hard changes” like these:

• Bring developers and end users closer and involve users in quality assurance processes.
• Keep applications simple. Stay away from unnecessary complexity.
• Favor dynamic languages.
• Release early and often.
• Let the users determine new features.

Look familiar?

With the exception of the much debated subject of favoring dynamic languages, compare the changes above to the principles behind the Agile Manifesto:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity - the art of maximizing the amount of work not done - is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

I don’t know what percent of corporate developers are using agile development methods, but I know that Agile has been around for a while, and even though it might be a common occurrence among Web 2.0 developers, it’s also made progress within the corporate community. Computerworld has also known this for a while, by the way.

So, and without dismissing the importance of waterfall methods, what should we really be talking about? How corporate developers can benefit from a new development process “discovered” by Web 2.0 companies? Or how we can all benefit from agile software development and contribute to its adoption?

Agile practices are pretty much alive. They don’t need to be brought back, they're here. And they don’t need a new name either.

Quite a few readers have requested more information about development for BlackBerry devices. In this series of posts I will walk you through the creation of an end-to-end application that will be a BlackBerry version of the web application I talk about in these articles: End-to-end ExtJS application (Part 1) and End-to-end ExtJS application (Part 2).

In case you haven’t read the articles, the web application I built is a very simple Knowledge Base System. These are the basic usage scenarios I had established for it

1. Browsing a collection of articles stored in a knowledge base repository
2. Creation, edition or deletion of articles (any user can view, create, edit and delete any articles),
3. View an article. The article’s visible attributes are
   • Title
   • Body
   • Tags, as a way to connect the article to specific topics
   • Author’s name
   • Date published

Requirements

For the BlackBerry application, I will skip the creation, edition and deletion of articles and focus on browsing and viewing existing articles. So, my first take at the usage scenarios produces this list

1. Searching a collection of articles stored in a knowledge base repository,
   • By title,
   • By tags 
2. View an article. The article’s visible attributes are
   • Title
   • Body
   • Tags, as a way to connect the article to specific topics
   • Author’s name
   • Date published

Building Blocks

Besides the BlackBerry application, I will use a .NET http handler on the server side, to channel all communications between the device and the articles database.

User Interface

I’ve found that when I enter the construction phase on a project of this kind, it always helps me if I have an idea of how the user interface is going to look. Keeping my “product owner” hat on, I am going to help my coder alter ego by putting together a few rough UI prototypes.

First comes the Home Screen. This will be the main screen of the application and I expect it to be a door into the different search features that will be available as well as the application settings.

Now to the Search Screen. This screen will allow our users to initiate an articles search by typing one or more words belonging to the article’s title.

The Browse Tags Screen will display a list of the existing tags in the database. Beside each tag there will be a count of the articles the tag applies to.

The Results Screen will show a list of articles that satisfy the criteria entered on the Search Screen. It will also allow our users to click on any listed article in order to view it.

The Article Screen will show the viewable attributes of the article that was selected on the Results Screen. This is where the user get’s to read the article.

The Options Screen will allow the user to change the application settings. In terms of settings, so far I can only think of the url our application will connect to in order to talk to its server counterpart, and the number of references to recently viewed articles to keep cached on the device.

Implementation

It looks like I can switch to “coder” mode and get started writing our device-side code. I will first take care of creating a stripped-down version of the application that does nothing but display the main user interface elements. This will allow me to validate my UI prototypes and serve as a foundation I can build upon later when I have to add the networking routines and the code that will take care of loading and saving the application settings. In this post I will create the Application Class and the Home Screen. I will tackle the rest of the screens in my next article.

The Development Environmet

The IDE I will be using is the BlackBerry JDE version 4.3.0. You can download the IDE as well as its documentation here.

The Application Class

Let’s begin with the Application Class. This class will be the entry point into our application and will be in charge of creating the Home Screen.

Worth highlighting is the constructor of the Class, which is where I create an instance of the Home Screen and push it to the display stack.

Home Screen

The Home Screen displays a list of search options.

One interesting detail here is that I'm extending the ObjectListField Class in order to be able to add a small icon to each of the search options.

The navigationClick method is where I’m going to determine what search option will be displayed.

What’s next

This is it for now. In my next article of this series, I will build the rest of the screens and lay the foundation for adding the networking code as well as the code to save a retrieve the application settings. Once I cover the device-side code, I will move to the server side and take care of the pieces that will handle the communications with the device.

Downloads

Download the source code for this article from the Downloads page.

I just attended the Certified ScrumMaster Workshop offered by Winnow Management. It was the best class I've taken in a long time.

We've been doing agile development for a while and I think there are many pieces of the Scrum framework we can benefit from. We will certainly continue adding elements of Scrum to our process.

I'm planning on coming back to this subject after we have some concrete results to comment on.