![]() Not so with BREW! When you create a record, it’s your responsibility to specify the number of fields in a record, and then create an array of AEEDBField objects, with one entry for each field. Veterans of small platforms are used to having to write their own search and sort facilities, but most lightweight database implementations let you specify the structure of a record’s fields as a C structure or similar object. ![]() What puzzles many newcomers to BREW most is the iterative nature of the IDBRecord interface. Tip: QUALCOMM has not chosen to release the BREW database format, and for that reason it’s ill-advised to write applications that access BREW databases that don’t directly use the BREW database interfaces! Although the underlying implementation may appear simple (I regularly use the UNIX od facility during unit testing to eyeball database changes), it’s subject to change without notice. ![]() Under the hood, a database is a file (or pair of files, in older versions of BREW) with an index to each record and the data of each record, stored in record fields whose representation closely mirrors that of an individual database record as it’s created. There’s no interface to perform sorts or queries it’s up to you to add that logic after you define your database schema. The BREW database implementation is emphatically a no-frills implementation, because on-disk performance is paramount. The IDBRecord interface, which lets you add and remove fields in a record, as well as remove a record from the database.The IDatabase interface, which lets you add records, iterate over records as well as fetch a record by its BREW-assigned ID.The IDBMgr interface, which lets you create, open, close, and delete databases.BREW provides three interfaces for you to use when creating and manipulating databases: Inside BREW’s Data Storage Modelīefore I begin, it’s worth taking a minute and reviewing the basics of using a BREW database. Even if you haven’t worked with BREW databases before, chances are you’ll learn something, because under the hood, this solution makes use of the entire repertoire of BREW interfaces. ![]() In this article, I show you how you can use the same trick when writing in C for BREW, so that your application’s views and controller can largely treat your application’s data model as a purely in-heap object, while creating a manageable interface to your object’s persistent representation that builds on the best aspects of the BREW IDatabase and IDBRecord interfaces. On a recent project, I stumbled across a solution that solved the complexity problem well: using the fields of the model as the data store for the underlying database record prior to serialization, and hiding the database record interface itself as a private member of the model. Although efficient, the interfaces suffer from complexity that can be hard to manage in user-interface applications, especially those utilizing the Model-View-Controller (MVC) pattern. Since QUALCOMM BREW’s inception, BREW has provided a trio of interfaces (IDBMgr, IDatabase, and IDBRecord) that permit random access to a series of records within a data store on the handset’s flash file system. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |