If you’ve written more than a very simple BlackBerry application, you’ll know that you need to sign most applications with keys obtained from RIM. Getting keys from RIM and signing applications within Eclipse is an easy process and well documented on the BlackBerry web site.
If however you change computers, its a bit more difficult. Depending on what you read you’ll see that the signing keys are tied to a single computer, or you need to request new keys from RIM, or you can just copy keys between computers.
The latter of these is the closest to the truth, but there is still a sting in the tail.
When you move development computers, to move the code signing keys with you, you need to copy the following directory to the new computer.
eclipse\plugins\net.rim.ejde\signTool
Once you’ve copied the keys over, you need to import them into Eclipse using the “Import Existing Keys” option on the “Window | Preferences” dialog as shown below.
That appears to be everything you need to do, however if you try to sign some code now, you will get an error back:
The private key is not located in the sigtool.csk file
To overcome this issue, you need to copy the sigtool.csk and sigtool.db files that were copied above into the vmTools folder.
eclipse\plugins\net.rim.ejde\vmTools
Having followed these steps, you should be able to sign applications on a new computer.
I’ve recently been looking into NoSQL databases and found this
poll over at
JavaLobby.
According to the poll, the top 3 NoSQL databases are:
- Apache Cassandra - 33%
- Apache CouchDB - 21%
- MongoDB - 15%
Out of these top 3, MongoDB seems to be the one that most fits my needs. Its a scalable document centric database that has a simple Java API. Getting up and running with MongoDB is a very simple process and to easy to start writing apps against it.
If I had time to spend looking at Cassandra and CouchDB, I’d probably find them very similar, but for the moment I’m concentrating on MongoDB.
I’d be interested in others thoughts about these 3 NoSQL databases (or indeed any other NoSQL database).
I recently
posted on how to programatically set the background color using Java within a BlackBerry app.
This technique works fine if you are using Field Managers to add components on to the screen.
If however, your user interface is drawn within the paint(Graphics g) mehod, this technique does not work. In this case, you need to override the paintBackground(Graphics g) method to set the background color.
protected void paintBackground(Graphics g) {
g.setBackgroundColor(0x000000);
}
Setting the background color on a BlackBerry screen is fairly easy. Since JDE 4.6.0, the BackgroundFactory class can be used to accomplish this.
public class MyScreen extends MainScreen {
public MyScreen() {
// Initialization…
Manager manager = getMainManager();
Background bg =
BackgroundFactory.createSolidBackground(Color.BLACK);
manager.setBackground(bg);
}
}
In most programming languages, such as .NET or Java, if you wanted to create a Color object from an RGB, you would execute some method on a Color class passing in Red, Green and Blue values where these values are typically within the range 0 through 255.
If you want to do perform a similar operation in Cocoa, i.e. creating a NSColor object, you need to pass in color values within the range 0 through 1.
Typically, to create a NSColor object in Cocoa, you would use a method such as
[NSColor colorWithDeviceRed: green: blue: alpha:]
To convert RGB values into the appropriate values for this method, you need to add 1 to each separate RGB value and then divide by 256.
So, for example, Alice Blue with an RGB of (240, 248, 255) could be instantiated as a NSColor using the values:
Red: (240+1)/256 = 0.941
Green: (248+1)/256 = 0.973
Blue: (255+1)/256 = 1.0
[NSColor colorWithDeviceRed:0.941 green:0.973 blue:1.0 alpha:1.0]
I’ve spent the last hour or so trying to track down a problem with a multi-threaded GUI Cocoa application that I’ve written.
The problem turned out to be that I was trying to update the applications UI from a background thread. In Cocoa apps, you should only really be updating the applications UI from within the main thread. If you don’t, you get strange results such as the app working in debug and not release or sometimes even hanging altogether.
I fixed the problem by updating the GUI from the background thread by using the performSelectorOnMainThread method. Something similar to below.
-(void)backgroundThread {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
// .. Update main UI.
[self performSelectorOnMainThread: @selector(updateGui withObject:results waitUntilDone:NO];
// ..
[pool drain];
}
-(void)updateGui:(NSString*) results {
// Update the gui.
}
RSS Feed