.

Application Development 2.0: Agile Practices Redux?

July 28, 2008 07:11 by Jorge

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.

Actions: E-mail | Permalink | Comments (0) | Trackback

End-To-End BlackBerry Application (Part 6)

July 15, 2008 18:01 by Jorge

In this sixth delivery of my end-to-end BlackBerry application walk-through, I will cover the following topics:

  • Creating a .NET http handler to send and receive information from the handheld application
  • Consuming the server-side business logic services from our http handler
  • Making requests from the handheld application and receiving data

While the previous articles of this series dealt with creating the Java application that will be installed on the handheld device, today I will be working on the server-side modules. Let’s take another look at our basic building blocks:

Building-Blocks1

The server-side modules consist of a .NET HTTP handler, a set of class libraries that contain the business logic and data access code, and a SQL Server database that will serve as the articles repository of our Knowledge Base application.

Creating The HTTP Handler

The mission of  the HTTP Handler is to extract the information from the HTTP requests made from the handheld, determine what type of action is required and ask the business logic layer to execute such actions. It will also append the results produced by the business logic to HTTP responses and send them to the handheld application.

In order for the handheld application and the handler to be able to talk to each other, all the commands that the handheld application can possibly send need to be defined within the handler as they were defined in the handheld:

// The commands the handheld can send us.
private const int CMD_SEARCH_ARTICLES = 1;
private const int CMD_GET_ARTICLES_BY_TAG = 2;
private const int CMD_GET_TAG_COUNTS = 3;

The keys identifying  each of the request parameters need to be defined as well:

// The request keys.
private const string KEY_COMMAND = "cmd";
private const string KEY_SEARCH_PHRASE = "sp";
private const string KEY_TAG = "tg";

KEY_SEARCH_PHRASE identifies the request parameter carrying the search phrase when a request to search the existing articles is made. KEY_TAG identifies the parameter carrying the tag name when the request is to retrieve the articles for a given tag.

Determining what to do is a matter of inspecting the request parameter marked with the KEY_COMMAND key:

string commandString = request.Form[KEY_COMMAND];
 
if (!int.TryParse(commandString, out currentCommand)) 
{
    // Bail if we don't receive a numeric command.
    return;
}
 
articlesServer = Shared.GetArticlesServer(context);
 
switch (currentCommand)
{
    case CMD_SEARCH_ARTICLES:
        string searchPhrase = request.Params[KEY_SEARCH_PHRASE];
        responseString = SearchArticles(searchPhrase);
        break;
    case CMD_GET_ARTICLES_BY_TAG:
        string tag = request.Params[KEY_TAG];
        responseString = GetArticlesForTag(tag);
        break;
    case CMD_GET_TAG_COUNTS:
        responseString = GetTagCounts();
        break;
    default:
        return;
}

Consuming The Business Logic Services

I won’t go into the details of the construction of the business logic and data access layers today, since they were covered in my End-to-end ExtJS application series. Something noteworthy, though, is the fact that these layers support storage of the articles in a file or in a SQL Server database. The code download for today’s article defaults to file-based storage, but you can run the included SQL script to install the database and point the business layer to it by changing the web application’s configuration file.

In the HTTP handler, SearchArticles(), GetArticlesForTag() and GetTagCounts() simply forward the requests to the business logic layer:

private string SearchArticles(string searchPhrase)
{
    Debug.Assert(searchPhrase != null);
    if (null == searchPhrase)
    {
        ExceptionPolicy.HandleException(
                new ArgumentNullException("searchPhrase"), 
                Shared.KB_EXCEPTION_PLCY);
    }
 
    string result = string.Empty;
 
    try
    {
        List<IArticle> articles = 
            articlesServer.GetArticlesForSearchPhrase(searchPhrase);
        if (null == articles) return 
                string.Empty;
        result = SerializeArticlesList(articles);
    }
    catch (Exception ex)
    {
        ExceptionPolicy.HandleException(ex, Shared.KB_EXCEPTION_PLCY);
    }
 
    return result;
}
private string GetArticlesForTag(string tag)
{
    Debug.Assert(tag != null);
    if (null == tag)
    {
        ExceptionPolicy.HandleException(
            new ArgumentNullException("tag"), 
            Shared.KB_EXCEPTION_PLCY);
    }
 
    string result = string.Empty;
 
    try
    {
 
        List<IArticle> articles = articlesServer.GetArticlesForTag(tag);
        if (null == articles) return
                string.Empty;
        result = SerializeArticlesList(articles);
    }
    catch (Exception ex)
    {
        ExceptionPolicy.HandleException(ex, Shared.KB_EXCEPTION_PLCY);
    }
 
    return result;
}
private string GetTagCounts()
{
    StringBuilder sb = new StringBuilder("");
 
    try
    {                
        Dictionary<string, int> tagCounts = articlesServer.GetTagCounts();
 
        if (null != tagCounts && tagCounts.Count > 0)
        {
            foreach (KeyValuePair<string, int> tagStat in tagCounts)
            {
                sb.Append(string.Format("{0}^~^{1}~^~", 
                    tagStat.Key, 
                    tagStat.Value));                       
            }
        }
 
    }
    catch (Exception ex)
    {
        ExceptionPolicy.HandleException(ex, Shared.KB_EXCEPTION_PLCY);
    }
    return sb.ToString();
}

After the business logic results are delivered to the handler I need to serialize the results according the formatting convention I had established when I wrote the handheld code. For example, this is the routine that converts a list of articles into a string that will be sent to the handheld as part of the HTTP response:

private string SerializeArticlesList(List<IArticle> articles)
{
    Debug.Assert(articles != null);
    if (null == articles)
    {
        ExceptionPolicy.HandleException(
            new ArgumentNullException("articles"), 
                Shared.KB_EXCEPTION_PLCY);
    }
 
    StringBuilder sb = new StringBuilder("");
    string body;
 
    foreach (IArticle article in articles)
    {
        // Decode the html characters in the body of the article.
        body = HttpUtility.HtmlDecode(HttpUtility.UrlDecode(article.Body));
        // Strip the html characters (We're using a RichTextField on the handheld,
        // which isn't capable yet of displaying html.
        body = Regex.Replace(body, @"<(.|\n)*?>", string.Empty);
 
        sb.Append(string.Format("{0}^~^{1}^~^{2}^~^{3}^~^", 
            article.Id.ToString(), 
            article.Title, 
            article.DateCreated.ToShortDateString(), 
            article.Author));
        sb.Append(string.Format("{0}^~^{1}~^~", 
            article.Tags, body));
    }
 
    return sb.ToString();
}

Did you notice that in the code above I’m also removing the Html characters from the body of the article? I have to do this because the field I’m using to display the body of the article on the handheld is not capable of rendering Html.

All that’s left now is to send the data to the handheld:

response.ContentType = "text/plain";
int contentLength = response.Output.Encoding.GetByteCount(responseString);
response.AppendHeader("content-length", contentLength.ToString());
response.Write(responseString);
response.End();

Well,  I know the walk through the server-side code went pretty fast. I encourage you to download the code for today’s post and check it out to see all the details. Also, reading the End-to-end ExtJS application post can give you more insight on the business logic and data access layers.

Making Requests From The Handheld Application And Receiving Data

Let’s return to the device-side code and ready it to connect to the HTTP handler. The first thing I will do is stop using the MockHTTPTransport instance and start using KbHTTPTransport. While MockHTTPTransport simply simulates an HTTP request to allow for testing of all the rendering logic on the device, KbHTTPTransport is the real deal. This is how I use it from the Articles Screen or the Tags Screen:

private void sendHttpRequest(String[] keys, String[] values) {
   
   articlesList.set(null);  // Show "No Articles" while we download.
    
   String url = DataStore.getAppServerUrl();
   // Make sure we can create an http request.
   // If the app. server URL has not been set, we cannot make any http requests.
    if (null == url || url.length() == 0) {
        Dialog.alert(resources.getString(
            KnowledgeBaseResource.ERR_INVALID_APP_SERVER_URL));
        return;
    }
    
    statusDlg.show();
    
    byte[] requestContents = TransportUtils.createPostData(keys, values);
    
    KbHTTPTransport transport = new KbHTTPTransport();
    transport.setHTTPTransportListener(this);
    transport.send(KbHTTPTransport.REQ_METHOD_POST, url, requestContents);        
    
}

At this point all the pieces are in place and I’m going to use the BlackBerry simulator and MDS simulator to test the application with real data. After firing up both simulators, I will check the Options Screen and make sure that I’m pointing to the right URL for my HTTP handler:

Options Screen

Back to the Main Screen, I choose Browse Tags:

image

And here I am getting real data from the handler:

image

Selecting a tag should bring back some articles:

image

And selecting an article should display its contents:

image

Conclusion

I hope you’ve found this series of posts helpful. I think the application is at a reasonable quality level where you can use its blocks as a foundation for your own projects. Although I’ll move on into other topics, I’m willing to come back to work on or talk more about any areas of your interest. Please let me know your thoughts. 

Downloads

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

Actions: E-mail | Permalink | Comments (0) | Trackback

How-To: Signing Your BlackBerry Application Before Deployment

July 9, 2008 19:24 by Jorge

A concerned reader asked me about how to sign his BlackBerry application. In this post I will try to provide you with information on the following topics:

  • Why the need to sign your BlackBerry code
  • Registering and obtaining signature keys
  • Signing your application

Why You Need to Sign Your Code

The concept of “controlled” API's has existed since BlackBerry 3.6 as a way for Research In Motion (RIM) to track the use of some API's for security and export control reasons. In practical terms, this means that in order to run an application on a handheld, you need to register and sign the application. Signing of applications is not required to run applications using the BlackBerry device simulator.

The BlackBerry API is divided into five groups. The first group includes all standard Java API's from MIDP and CLDC and some BlackBerry-specific API's. This group is open for all developers, and applications that use only these open API's require no signatures. The remaining four groups are all controlled API's: RIM Runtime API's, some BlackBerry API's, RIM Cryptography and Certicom Cryptography.

Registering and Obtaining Signature Keys

The registration process serves to verify the developer's identity. It involves downloading and filling out a registration form that you need to fax to RIM. There’s also a one-time processing fee associated with it. RIM will send you a set of signature keys after the registration form and fee are received.

Signing Your Application

Once you receive the signature keys from RIM, you need to install them on your development environment. The detailed instructions on how to do this can be found in the BlackBerry Java Developer Guide, Volume 2 - Advanced Topics. I recommend that you study this procedure, since installing the keys incorrectly will cause the signing process to fail.

Signing the application is very easy once the keys are installed. You need to manually start the Signature Tool from the Build menu in the JDE:

Request-Signatures-Menu

The tool displays a list of necessary signatures:

 Signature-Tool1

When you press the Request button, the Signature Tool submits a hash of the application to RIM's signing authority. The signing authority automatically returns the required signature, that is automatically appended to the application. The application can be loaded onto a device after this step.

Note that RIM does not receive a copy of your application, only a hash of the file(s). This allows them to determine the author of the application by matching the hash of the application against records of the hash kept by the signing authorities.

Where to Find More Information

You can find more information on this topic in the BlackBerry Java Developer Guide, Volume 2 - Advanced Topics.

Actions: E-mail | Permalink | Comments (0) | Trackback