Resource string v. local string constant

[Morgan]

I was wondering if I should use a resource string in the following situation:

I intend to upload a file to a temp directory on the phone. The file name will be of the form, "tmp/scriptX.txt" (where 'X' will be a number between 1 and 99 ). I'll determine the actual name at the time of uploading and use SPRINTF to create it with the format string, "tmp\\script%d.txt".

Now my question, should the format string be a resource, or simply a constant in my code. The trade-off seems to be between memory usage and the "flexibility" of a resource string.

For memory usage it seems better to use a local string constant for the format since it'll then be easy to determine its length and there is no wasted memory when I allocate the space for the file name. If I'm using a resource, I need to allocate enough memory to cover a worst case scenario (whatever that might be) for the size of the format string and file name.

Does anyone have any thoughts about this? Will I really regret it if I use a string constant in my code? Am I being totally brain dead?

Thanks.

[Craig Evans]

I hope these files are only going to be temporary, and you are including a mechanism to remove them ... the OEM implementations of the BREW API have a finite number of files that can be created on the phone (and this is something that the certification process test for). The 3035 had something like 256 files (total, across all apps and directories), while the Sharp had a far more limiting 96 files.

A suggestion I'd like to make (hopefully before a "file" basd system is embedded too deeply in your design) is that you use a single database to store the information you require. Then you can access the information along the lines of "databasename"/"record number", rather than file1.txt, file2.txt, file3.txt ... file99.txt.

Just a thought. This was an area that our app ran into probs in certification because the file number limitation wasn't *ahem* advertised *cough* at the time.

CSE

[Morgan]

Thanks for the info! It's always good to find out about "features" before they pop up 'n bite 'cha.

Unfortunately, in my case they do have to be files, but the user will be presented with the option to keep or delete -- so it's all on them :-)