Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Developer
Posts: 105
Registered: ‎03-09-2009
My Device: Not Specified

Desktop Manager Sync format purpose of extra byte...

[ Edited ]

in the samples for interacting with the desktop manager, they follow this format for strings:

String name = "test" 

int type = 0; 

 

buffer.writeShort(name.length()+1);  -string length + 1
buffer.writeByte(type);                    -int filed type, changed to 1 byte
buffer.write(name.getBytes());        - string converted to bytes
buffer.writeByte(0);                       - 1 padding byte

 

and on restore, it reads the short, then the type, then pulls in that length, which includes the string plus the padding byte, and I guess because of the padding byte it using the String method Trim();

 

I have found that this also works fine and saves 1 byte of data for every record using as well as source program code...

 

buffer.writeShort(name.length());  -string length

buffer.writeByte(type);                    -int filed type, changed to 1 byte
buffer.write(name.getBytes());        - string converted to bytes

 

and on restore, don't include padding byte and don't use Trim(), though it doesn't seem like trim is needed in above case either...

 

part of why I ask is I have other data types stored, including int, boolean, and long...in those cases, the padding byte at the end seems annoying...

 

should I used the padding for other types too?

Message Edited by mnpaslay on 06-09-2009 10:05 PM
Developer
Developer
Posts: 319
Registered: ‎07-20-2008
My Device: Not Specified

Re: Desktop Manager Sync format purpose of extra byte...

Are you just implementing backup/restore or are you writing a desktop manager add-in?
Developer
Posts: 105
Registered: ‎03-09-2009
My Device: Not Specified

Re: Desktop Manager Sync format purpose of extra byte...

right now just backup/restore, but I may want to write an add in later...

 

Thanks!

Developer
Developer
Posts: 319
Registered: ‎07-20-2008
My Device: Not Specified

Re: Desktop Manager Sync format purpose of extra byte...

Well, I think the reason for the extra 0 on the end of the Strings is that desktop add-ins are usually written in C++ and use null terminated strings.  The backup/restore process writes to a file on the desktop and doesn't need the null termination.  Unfortunately it's the same code on the device so you have to know which scenario you're in and prep the data accordingly.  The good news is that if you write your add-in in C# managed code, you don't have to deal with the null terminations anymore (and it's way easier than C++).  The bad news is that writing a C# add-in isn't officially supported by RIM and the only example I know if is the stuff I wrote.

 

Bottom line: stick with the backup/restore as long as possible and don't bother with the trailing 0's.   

Developer
Posts: 105
Registered: ‎03-09-2009
My Device: Not Specified

Re: Desktop Manager Sync format purpose of extra byte...

If I put in the trailering 0s for strings, are they also required for other types such as int, long, boolean, etc..?

 

I'm leaning towards just following the examples, could save time if I write in an add on... 

 

Thanks!

Developer
Developer
Posts: 319
Registered: ‎07-20-2008
My Device: Not Specified

Re: Desktop Manager Sync format purpose of extra byte...

IIRC it was only the strings that needed the trailing 0.