Blackberry 4.2 JDE development

So recently I was doing some audio recording on the blackberry JDE 4.2 using JSR135

I was surprised that the Manager.createPlayer() and RecordControl.setLocation() methods don't save the wave-file with the proper wave headers.

Anyway, after some digging I found the specification for wave header. Here is a method that creates that header.It requires the filesize of the raw data. So just write 46 nil bytes on to the stream, then start recording, then close file, then reopen the file and call this method.

private static byte[] byteShift(int number){
return new byte[]{
(byte)(number & 0xff),
(byte)(number >> 8 & 0xff),
(byte)(number >> 16 & 0xff),
(byte)(number >> 24 & 0xff)};

}

private static byte[] createWaveHeader(long fileSize){
try{
int fileSize_int = (int) fileSize;
byte[] array1 = byteShift(fileSize_int-8);
byte[] array2 = byteShift(fileSize_int-46);
if(array1.length == 4 && array2.length == 4)
{
byte[] header = new byte[] {
(byte)'R',(byte)'I',(byte)'F',(byte)'F', // RIFF
array1[0],array1[1],array1[2],array1[3], // filesize - 8 (4 bytes)
(byte)'W',(byte)'A',(byte)'V',(byte)'E',(byte)'f',(byte)'m',(byte)'t', // WAVEfmt
0x20, // space
0x12,0x00,0x00,0x00, //chunksize (4 bytes)
0x01,0x00, // format tag (2 bytes)
0x01,0x00, // channels (2 bytes)
0x40,0x1F,0x00,0x00, // sample per second (4 bytes)
(byte)0x80,0x3E,0x00,0x00, // average bytes per second (4 bytes)
0x02,0x00, // block align (2 bytes)
0x10,0x00, // bit per second (2 bytes)
0x00,0x00, // extra size (2 bytes)
(byte)'d',(byte)'a',(byte)'t',(byte)'a', // data
array2[0],array2[1],array2[2],array2[3], // filesize - 46 (4 bytes)
};
return header;
}
}catch(Exception e){

}
return null;
}

It requires the filesize of the raw data. So just write 46 nil bytes on to the stream, then start recording, then close file, then reopen the file and call this method.

RESTful Web architecture

Started to learn, how to build a web-service using the "RESTful" way.

In summary: (quoted from: http://www.xfront.com/REST-Web-Services.html)

• Client-Server: a pull-based interaction style: consuming components pull representations.
• Stateless: each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server.
• Cache: to improve network efficiency responses must be capable of being labeled as cacheable or non-cacheable.
• Uniform interface: all resources are accessed with a generic interface (e.g., HTTP GET, POST, PUT, DELETE).
• Named resources - the system is comprised of resources which are named using a URL.
• Interconnected resource representations - the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another.
• Layered components - intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, etc.