Advice Requested: IDatabase v. IFile | developer.brewmp.com Advice Requested: IDatabase v. IFile | developer.brewmp.com

Developer

Advice Requested: IDatabase v. IFile

Forums:

[some background] I've been coding in BREW for over a year now. My program uses the database feature, stores and reads files and makes web service calls. I even built my own HTTP(S) net code to workaround problems in the IWeb* classes. So, I am well acquainted with events and callbacks.

I am about to build a new feature for my program and could use some advice. The feature is a message in-box (assume fixed length). For business reasons, we don't want to use the phone's SMS.

The question is, where to put the messages? Into a Database or on the file system? My concerns are Database record/field length limitations vs. the need to build callbacks and/or event handling for File Read/Write. Also, Database appears to be able to grow without bound (what guarantee exists that deleted records are "garbage collected"; that is, the database file will be shrunk when total length far exceeds active records)?

I can put requirements on them (maximum length), but I'm concerned that even if I use AEEDB_FT_BINARY, I may encounter a max row length for a record or field on some phones. I plan to pack the messages myself, so I'll only have one binary record to store.

It's likely that I would create a max record size (1024) for DB or File. I plan to pre-allocate and re-use these records. There would be one header record that contains active records (index for the other records). This model essentially re-creates the database structure, but gives me slightly more control. Is this an illusion of control? Am I worried about nothing?

Another confusing point, if File Reads and Writes are not guaranteed to complete, how does the Database API get around this problem? Can a partial read or write for a database record occur? If so, what happens to the program while waiting for the completion of the read/write? If not, is there a maximum size guaranteed to not trigger a failure?

Sorry for the long message. My current use of the Database is restricted to small amounts of data, but this has always bothered me. I would rather use a guaranteed, atomic API like IDatabase over IFile, but only if it can be guaranteed for the data block size I'm using.

Thanks,

Andy

IFILE_Read and IFILE_Write don't actually block, they are both synchronous. IFILE_Readable exists because IFile is a subclass of IAStream, which supports asynchronous reading.
-Erik

IFILE_Read and IFILE_Write don't actually block, they are both synchronous. IFILE_Readable exists because IFile is a subclass of IAStream, which supports asynchronous reading.
-Erik

Erik,
Thanks. I never bothered to notice there was no IFILE_Writable().
However, this only gets curiouser.
Both IFILE_Read and IFILE_Write return number of bytes written. Strict practice requires these return values to be respected and, if the bytes are fewer than the expected bytes rd/wr, the code should retry the rd/wr with the remaining data.
In that loop, what happens when rd/wr returns '0'? Assuming there is room on the file system for more data, the application should treat that as a EWAIT. Without the IFILE_Writable() method, I can only assume this never means EWAIT and instead, a return value of '0' bytes written must be interpreted as an error condition and the app should take appropriate action. I'm guessing '0' could also mean the code doesn't have permission to rd/wr data.
The previous paragraph assumes the amount of data being rd/wr is not so large as to cause a delay in returning control to Brew (the phone's) event queue.
Am I missing something?
Cheers,
Andy

Erik,
Thanks. I never bothered to notice there was no IFILE_Writable().
However, this only gets curiouser.
Both IFILE_Read and IFILE_Write return number of bytes written. Strict practice requires these return values to be respected and, if the bytes are fewer than the expected bytes rd/wr, the code should retry the rd/wr with the remaining data.
In that loop, what happens when rd/wr returns '0'? Assuming there is room on the file system for more data, the application should treat that as a EWAIT. Without the IFILE_Writable() method, I can only assume this never means EWAIT and instead, a return value of '0' bytes written must be interpreted as an error condition and the app should take appropriate action. I'm guessing '0' could also mean the code doesn't have permission to rd/wr data.
The previous paragraph assumes the amount of data being rd/wr is not so large as to cause a delay in returning control to Brew (the phone's) event queue.
Am I missing something?
Cheers,
Andy

OK, so I think I figured out what I was missing. Unless one of the following two events occurs:
1. File system is full while appending to a file
2. Read off the end of a file
Write and Read will always return the expected number of characters to be written or read because memory is contiguous and files are stored in flash memory. When file I/O occurs, there is no "EWOULDBLOCK" for the disk to prepare for more data. This differs from network I/O where than can be profound wait times (relative to processor work/speed).
I think I've got it.
Thanks,
Andy

OK, so I think I figured out what I was missing. Unless one of the following two events occurs:
1. File system is full while appending to a file
2. Read off the end of a file
Write and Read will always return the expected number of characters to be written or read because memory is contiguous and files are stored in flash memory. When file I/O occurs, there is no "EWOULDBLOCK" for the disk to prepare for more data. This differs from network I/O where than can be profound wait times (relative to processor work/speed).
I think I've got it.
Thanks,
Andy