marchywka wrote:If your object isn't in memory, where is it? All you are talking about here is RAM versus FLASH perhaps.
Not the whole object is in memory, that is in the memory used by the process.
I'll try to explain it via Golf Scores app (can see screen shots on my website):
- when loading the first screen I create array of courses and each course only gets id and name from database.
- when you select a course and with that go to 'rounds' screen the course object goes to the database and populates its rounds array with objects of type Round - each round only gets id and 'date played' from database
- when you select Round, well you can guess what happens...
Now, when the device notify my app of low memory I can de-allocate rounds array (and everything referenced down the tree) of each course but the one that is currently been used/view by the user.
I did something similar in Windows Mobile version of Golf Scores, which I haven't been maintaining for long time - waiting for Windows Mobile 7 
Thanks RexDoug for the info!
Fortunately my apps don't really much on the things you mentioned. The only thing I need is database. I though RIM announced last December that they are going to bring sqlite in BB, what happened?
I guess what I would have, and this can be quite naive given lack of disk or even significant multi-level memory caching
in this situation, is simply index trees with pointers to course records. I have been maintaining a simultaneous tree and double
linked list structure which may seem wasteful but compared to DB probably is not 
Anyway, given this and the begin/end indicies,
it is a simple matter to get the names out of one tree with total ignorance of the rest of the target data and code that is very simple requiring no
real lookup. For example, if I just want to list names that already ordered in an index,
// this isn't my real interface, just for clarity.
Something like BonsaiIndex bidx= m_db.getFirst(INDEX_0);
while (bidx!=null)
{
String name[i]= bidx.getKey(); // this is actually a fairly slow process as string keys I maintain as chunked long[] to save space with similar prefixes
bidx=bidx.getNext();
}
If I then wanted the details, I can call bidx.getTarget() to return the complete record which could contain more
primitive types of pointers to other objects or other index entries etc.
The index objects themselves are fairly small and could be made smaller with reasonable use of base and derived
classes ( I probably ended up with redundant entries and mutually exclusive members, have to check... ). Basic element
is just the key, two pointers up to a mom and "God" as well as left, right,next, prior. Of course, there is also a pointer to
a target object which is typically something that looks like a record and an array of other index entries.
And, sure, I can wipe out complete subtrees by settting a few pointers and provide special insert methods
if I know that I am adding sorted data to a given index- I may not even care if I get a linear "tree" (list) as long as I don't
have to start at beginning each time I want to append to it
So, I'm not sure that SELECT and SORT etc are all that helpful if you already know what keys you are likely to care about.
I don't have to copy anything as the returned thing serves as an iterator on the target data without modification.
Sure, I have some kluges and performance suffers from a few dumb things I didn't want to think through but I'm
pretty sure I can fix that when I get time, and in any case it is acceptable and probably smaller and faster than
most alternatives in this settgin.
marchywka, this sounds like writing some sort
of database engine 
Why do all that when the guys that maintain sqlite have already done it for us. An the best part is that is all tested and maintained 
Also, been written in C runs very fast!
Can you imagine how much time in coding and testing is involved in this compared with something like 10 lines of code?
- run your SQL statement
- loop trough each record returned and create, populate and store object in array
I personally thing that RIM would have gotten better return on investment if they ported sqlite or derby to BB instead of writing the persistence store. But that's just me... and Apple, Nokia, Microsoft, who decided to use databases in their platform...
I'm just disappointed, that's all 
"What do you mean "garbage? Do you even know what database are and how to use them?!?!?"
Garbage of course refers to the temp objects you often get from formulating string for things like queries etc. I'm just
suggesting you normally have limited retireval modes and it is unlikely that you benefit from creating this temporary
object, the "garbage" is just a minor part but it is literally accurate ( GC).
" I want to store data so next time the users start the app (maybe in a year time) the data is still there."
Persistent store does this no?
" I want to be able to change my objects and I want the data to be still available."
I have to admit that sometimes this can be annoying but I personally haven't thought
through the various options here. I have only run into it during development and
changes are often incompatible in any case- keeping old data can just lead to inconsistent
results anyway and export/import is more reasonable than encumbering a whole
app to give an appearance of support for this type of flexibility.
"In .NET you can serialize (binary or XML) object and than even if you add/remove variables and/or properties you can still deserialize it. Now I can serialize dictionary of objects and get them back - this sound to me a lot like the persistent store, but more flexible"
In order to be flexible, it doesn't just need an API or interface with a bunch of widgets, it has to not exceed the
resource limitations of the target platform for any situation to which you try to bend it- it still have to work as part of being flexible. This is the same argument
you get regarding PDF reader or other bloated apps that add (often useless or distracting ) features and flexibility while slowing down everything else.
I'm not putting a DB generically into this "useless" catagory but pointing out that in this setting there are more "flexible"
options in terms of enabling applications consistent with device limitations. People always talk about platform
independece and flexibilty as if something could run with no platform- that is you have no concern for actual available resources.
I've been through this with SOAP and I think you are exaggerating a bit here in terms or serialization capabilities. If you
are going to write code to define a DB record it is just as much work as writing your own XML IO and it can be
generated easily anyway.
"I want to be able to export that data, like I do from the iPhone, and than import it (without the need to write translator) in another app - possibly not even written in Java, you see last time I checked java wasn't the only way you can develop."
As do I but even here the few times I've looked XML or other bloated standards don't make a lot
of sense, even if you want to limit yourself to wifi. It is often worthwhile to go to various flat-text or binary formats
depending on the specific. I'm not sure what iPhone supports but all your concern seems to be regarding XML
and further these other things will not likely be standards ( you need to write something on the server
or "flexible" app to get it to work).
"From your arguments I don't think you really know much about databases, especially in-process ones. How well they perform, how they store and retrieve data- just have look at some of the open source ones."
I was asking for performance metrics and stated repeatedly that just about anything in native code could outperform
java.Someone else even suggested the SQL lite would only produce bloat is implemented as another piece of java code.
"Do you think that your approach would perform faster? Definitely would be much more code, and for what?"
Since I am "replacing" the ultimate source and destination of my hypothetical DB lookup with the end result I'm not
sure how it could be slower (duh). I guess if you are only reading a flat list of records so you can put them on a GUI
this may be fine but I need to do a lot of other stuff and this data structure will support that.
"Are you saying that Apple made a mistake for using sqlite for their own apps? Do you think you know better than them or Microsoft using SQL Server in Windows Mobile?"
I'm confessing ignorance, looking for data not ad hominens ( although I'm up for a flame war too waiting for a GUI app to load LOL).
Again, they have their uses as do PDF files. Often however people just throw them at problems and get something
that kind of works and is projected to work much better once you buy a more expensive phone. It's like watching
your CPU max out to animate some snow flakes on a flash ad while you are trying to read email. Nothing wrong
with flash, nothing wrong with PDF, nothing wrong with animation, but you can't just throw them at problems and
that is why I'm asking to understand specific reasons people think they need a DB.
"You see I'm not the only one who is for databases. This is the only mobile platform that I have come across and doesn't have SQL database - very suppressed!"
When we settle technical arguments by a popularity contest, we have already all lost
So, do they get true ACID performance and when does reorganization occur to maintain performance or have they found
a way around this?
