Michael Narinsky

There is a couple of things I’ve learned about BlackBerry Java development that I think might be worth sharing.

1. SQLite: Don’t use Cursor.close() – use Statement.close() instead.

It turned out that Cursor.close() method is also closing the Statement that was used to create that Cursor, even if the Statement was later reinitialized. I believe that removing Cursor.close() calls from the code helped me to avoid a couple of ‘File System Error (12)’ errors while doing some IO operations over the SQLite db file. I tend to think that ‘File System Error (12)’ error actually means ‘File is locked’ (thank you BlackBerry, btw, for such nice, self-explanatory error messages and providing no documentation about them), so now it all makes sense to me.

More info: http://supportforums.blackberry.com/t5/Java-Development/Cursor-close-closes-the-Statement-used-to-Create-It/ta-p/614699

2. Memory optimization

There is a nice blog post that provides an overview of RIM’s memory monitoring tools (Memory Statistics, Object Statistics and Objects) and gives a set of steps that should be taken in order to detect a memory leak and identify the root cause. I’ve seen this article before, but this time I’ve actually read it thoroughly (all three parts) and I think it’s very good place to start if you do a memory optimization:

http://devblog.blackberry.com/2009/10/how-to-find-that-memory-leak-part-one/

http://devblog.blackberry.com/2010/01/how-to-find-that-memory-leak-part-two-detecting-the-leak/ (you might need to tweak images’ source URLs in order to get them for this part)

http://devblog.blackberry.com/2010/03/how-to-find-that-memory-leak-part-three/

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);
	}
}

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…

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.

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>