BlackBerry: Sending an HTTP request in a separate thread

Sending an HTTP request in a separate thread is a very common operation for almost every client-server web application. The idea is to spin-off a background thread that will send a request and process the response data, but won’t block the main (GUI) thread on the same time.  At the end of its execution the background thread should use some kind of a callback mechanism to pass response results back to the main thread. Since this operation is very common I was expecting that pretty much every modern framework should have a lot of tutorials available online describing how to implement this functionality in a quick and easy way. However this was not the case for the BlackBerry Java API -  after a couple of hours researching I still didn’t find anything that was ‘quick and easy’…

Finally, looking through RIM’s API docs I found a method Application.invokeLater() which can take a runnable object defined in a background thread and start it in the main thread. This method allowed me to pass execution control back to the main thread.

Here is a sample code:

First let’s create a ConnectionThread class that can take a URL (to send a request to) and call a method of some screen once the response is received (for the sake of simplicity we’ll be calling a method of the screen that is currently on top of the screen’s stack).

public class ConnectionThread extends Thread {
	String URL;

	public ConnectionThread(String URL) {
		this.URL = URL; //URL to send a request to
	}

	public void run() {
		//optional: show some popup "Please wait screen"
		final Screen dialogScreen = new WaitPopupScreen(); //wait popup screen extends RIM's PopupScreen class
		UiApplication.getUiApplication().invokeLater(new Runnable() {
			public void run() {
				UiApplication.getUiApplication().pushModalScreen(dialogScreen);
			}
		});

		//send HTTP request and save the response
		HttpConnection connection = null;
		//use API 5.0 Connection factory class to get first available connection
		byte responseData[] = null;
		try { 
			connection = (HttpConnection) new ConnectionFactory().getConnection(URL).getConnection();
			int len = (int) connection.getLength();
			responseData = new byte[len];
			DataInputStream dis;
			dis = new DataInputStream(connection.openInputStream());
			dis.readFully(responseData);
		} catch (Exception e) {
			 // TODO Handle exception 
		} 

		final byte[] responseDataToProcess = responseData;
		//use invokeLater method to pass results back to the main thread
		UiApplication.getUiApplication().invokeLater(new Runnable() {
			public void run() {
				UiApplication.getUiApplication().popScreen(dialogScreen); //hide wait popup screen
				//pass results to the callback mathod of the current screen
				((MyScreen)UiApplication.getUiApplication().getActiveScreen()).callBackMethod(responseDataToProcess);
			}
		});
	}
}
This is the actual screen where we spin the connection thread off:
public class MyScreen extends MainScreen {
	public MyScreen() {
		super();
		// add a button that will initiate an HTTP request
		ButtonField requestButton = new ButtonField("Send HTTP Request");
		requestButton.setChangeListener(new FieldChangeListener() {
			public void fieldChanged(Field field, int context) {
				//start connectionThread on a button click
				new ConnectionThread("http://mnarinsky.com").start();
			}
		});
		add(requestButton);
	}
	
	//this method will be called from the connection thread
	public void callBackMethod(byte[] responseData){
		//process response
	}
}
Finally this is a code for an optional 'Please wait' popup screen – displays a simple “Please wait..” text. If you want you can make it little more fancy by using some animated GIF image.   
public class WaitPopupScreen extends PopupScreen {
	public WaitPopupScreen() {
		super(new VerticalFieldManager());
		LabelField labelField = new LabelField("Please wait...",
				Field.FIELD_HCENTER);
		add(labelField);
	}
}

Microsoft Certification

mcts-logo

Last month I have passed Microsoft Exam 70-515 (Web Applications Development with .NET Framework 4.0) and thus finally completed my long term project of getting a Microsoft .NET Developer Certification.

It all started in October 2009 – back then I’ve decided to pass MS Exam# 70-536 (.NET Application Development Foundation), which was a pre-requirement for all Microsoft development certifications. I’ve got a preparation book, studied it thoroughly and was ready for an exam around March 2010 - just a month before .NET 4.0 came out and Microsoft has announced a complete new set of exams targeting the updated framework. New exams became available on July 2010, but no preparation materials were released until December 2010. Around Christmas 2010 I finally got a new preparation book, spent another 2 months preparing and, voila, passed it in February 2011 – just 14 month after the start :)

Anyway, glad that this project is finally over – time to move on to the next one…

Customizing ASP.NET AJAX Control Toolkit AsyncFileUpload look

The standard HTML <input type=”file”> element does not work inside ASP.NET update panel due to security reasons and restrictions a browser implies (It is not allowed for JavaScript to directly access files in a user's system and it is not allowed to access the details of the selected file). ASP.NET AJAX Toolkit AsyncFileUpload control seems to be an easy way to solve this issue – it works out-of-box (well, after you add AjaxControlToolkit binaries to your project) and provides an excepted functionality to the end-user.

One problem I faced during my work with AsyncFileUpload was inability to customize the look of the control. This is a pretty common issue with a <input type=”file”> element in general and a pretty neat solution for this is described here. The basic idea of this solution is that you place <input type=”file”> element on top of another custom element (picture, button, etc.) and then set <input type=”file”> element’s opacity to 0, so it will be transparent and the user will only see the element underneath (picture, button, etc.), but clicking on that element will causes <input type=”file”> to fire off it’s click event.

This technique seems to work fine when working with regular <input type=”file”>, however AsyncFileUpload control does not allow to set its opacity…

So in order to solve this let’s take a look at how AsyncFileUpload control is being rendered.

Turns out that this code:

<div id="fileUploadDiv">
    <asp:AsyncFileUpload ID="AsyncFileUpload1" runat="server" />
</div>

will be rendered as:

<div id="fileUploadDiv">    
    <span id="MainContent_AsyncFileUpload1">    
        <input type="hidden" name="ctl00$MainContent$AsyncFileUpload1$ctl00" id="MainContent_AsyncFileUpload1_ctl00" />    
        <div id="MainContent_AsyncFileUpload1_ctl01" name="MainContent_AsyncFileUpload1_ctl01">    
            <input name="ctl00$MainContent$AsyncFileUpload1$ctl02" type="file" id="MainContent_AsyncFileUpload1_ctl02" id="MainContent_AsyncFileUpload1_ctl02" onkeydown="return false;" onkeypress="return false;" onmousedown="return false;" style="width:355px;" />    
        </div>    
    </span>    
</div>    

This means that using a CSS selector #fileUploadDiv input[type=file] you can modify the style (including opacity) of the AsyncFileUpload control the same way you do it with the regular <input type=”file”> control therefore you can still use this nice solution I mentioned before to give AsyncFileUpload control a custom look you want.

ASP.NET 4.0 Chart Control breaks IIS 7.0

I’ve decided to add the new ASP.NET 4.0 Chart Control to one of my web apps. Everything worked fine during the testing on my local machine, but once I published it to remote IIS 7.0 server I’ve got the following error:

HTTP Error 500.23 - Internal Server Error
An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.

Turns out that it occurs because ASP.NET modules and handlers should be specified in the IIS <handlers> and <modules> configuration sections in Integrated mode.

So the simple solution that worked for me was just to remove the following entry from web.config <system.web> section:

<httpHandlers>
<add path="ChartImg.axd" verb="GET,HEAD,POST" type="System.Web.UI.DataVisualization.Charting.ChartHttpHandler,
    System.Web.DataVisualization, Version=4.0.0.0, Culture=neutral,PublicKeyToken=31bf3856ad364e35"
    validate="false" />
</httpHandlers>

Also make sure that <system.webServer> section has the following:

<handlers>
	<remove name="ChartImageHandler" />
	<add name="ChartImageHandler" preCondition="integratedMode" verb="GET,HEAD,POST"
        path="ChartImg.axd" type="System.Web.UI.DataVisualization.Charting.ChartHttpHandler,
        System.Web.DataVisualization, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</handlers>

Creating a .cab file with C#

.NET does not have any classes for creating cabinet files out-of-box, so today I had to look what else is available out there. There are a couple of solutions I found for creating a .cab file from the .NET code. The one that actually worked for me was a library developed by Microsoft(!) as part of their Windows Installer XML (WiX) toolset. This toolset is distributed with a bunch of dlls as part of its SDK. The library that allows to create cabinet files is called Microsoft.Deployment.Compression.Cab and located under <WIX_Installation_Folder>\SDK.

In your project you need to add a reference to the Microsoft.Deployment.Compression.Cab.dll and to Microsoft.Deployment.Compression.dll (located under the same folder and has some base classes for types defined in the Microsoft.Deployment.Compression.Cab).

After doing this you can add files to a cabinet file from .NET with just a couple of line of code:

using Microsoft.Deployment.Compression.Cab;
//create a instance of Microsoft.Deployment.Compression.Cab.CabInfo
//which provides file-based operations on the cabinet file
CabInfo cab = new CabInfo(@"C:\Cabinet1.cab");

//create a list with files and add them to a cab file
List<string> filesToArchive = new List<string>() { @"C:\file1", @"C:\file2" };
cab.PackFiles(null, filesToArchive, null);
            

//add a folder (including subdirectories) to another cab file with a maximum compression level
cab = new CabInfo(@"C:\Cabinet2.cab");
cab.Pack(@"C:\folder", true, Microsoft.Deployment.Compression.CompressionLevel.Max, null);

//unpack a cab file into C:\Unpacked folder
cab.Unpack(@"C:\Unpacked");

The library has an MSDN style help file located under <WIX_Installation_Folder>\doc\DTFAPI.chm.

Another dll that also comes with WiX toolset SDK is Microsoft.Deployment.Compression.Zip.dll that provides similar functionality for packing and unpacking zip files.