Monday, December 20, 2010

Blackberry General Socket Exception and TCP sockets

Switching gears for a minute to the hell that is Blackberry development.
The situation is this.
I need to perform a TCP socket communication from a Blackberry Bold 9700 to a socket on a server that I have set up to listen for the requests. I won't go in to how to do that, there's plenty of documentation elsewhere. The problem is this: My app makes these socket calls very quickly, and consistently at 31 calls to the socket client my app fails with a "General Socket Exception." My app is then in a state where I have two choices. Shut down the device and restart, or let it sit for several minutes before attempting to make the socket call again. Neither option is acceptable. I've made attempts to ensure that my objects are closed and set to null. I've made every effort to ensure I don't have any leaks in my socket client.
There are alot of people running in to this, but nobody giving any real resolution. After fighting with this for a while, I've resolved my problem. Maybe it will help you with yours. As it turns out, my calls are happening too quickly for the Blackberry garbage collection to take out the trash. I'm using up my resources, and failing future calls. In order to get around this I've made use of the System.gc() method. Clean, simple, and the only solution that I've found that works. It cleans up the resources before I have a chance to use em all up, and allows my app to continue making the calls without issues.

Edit 10/7/2011
So, it's been forever, and the answer is above, but I thought I'd follow up. After getting with Blackberry engineers, asking for help, the only response I got was documentation on how to find memory leaks. Not helpful, I know where the leak is, I just don't know what to do about it. What ever, it appears that my test was much higher stress than actual production use. We have yet to encounter the issue in production use, and in fact, have had to make other adjustments that will slow the app even further. 

Friday, November 26, 2010

Libraries

Android Library
Goal: To create an Android application that essentially serves as a base application. It contains default values, it creates a standard database, it contains standard activities. Child applications will use the base application as is, only overriding strings and display settings. Finally, since I am still rocking a G1, it has to be built on 1.6.
1) As it happens, library applications are supported on Android 1.6, but you must be upgraded to release 3 in order to make that work. I fought with that one for about an hour before thinking to check the versions on my SDK. That’s an hour of creative swear words that I’ll never get back.
2) Create the base application, and make sure it runs. Check.
3) In Eclipse, go in to the project properties, select Android, and check the “library” checkbox. Run the application again, and make sure it still works. I’m pretty sure it worked, but I’ve had a glass or two of wine, so let’s try again just to be sure. Yup, we’re good.
4) Create the first extension application, under properties, select Android, and choose the library option and add the base application. Launch the application. Expected behavior would be to launch the default activity, but override the application string name. Could it be that easy? Of course not. From this point, open the AndroidManifest.xml for the child application. Under the element that points to the activity in the library application, add




From this point, I have my application launching the Activity from my library application, but using the string resources from my child application.

Now, back to XML and SQLite.

so here we go

I'm a C# developer who has had an interest in Android almost since the beginning, but I finally jumped on board as a consumer almost 2 years ago when I got my hands on a G1. From there I tossed around the idea of developing for it, but I didn't actually start until I got stuck doing a Blackberry project for work. That got me motivated to crack open the Android SDK at home, and actually write some code. I'm new to Android, and new to Java, so I imagine much of what I write about will be obvious to people who actually know what they're doing. That's ok. I'm fine with that.