Bullshark,
>I think too much is made of this. A list of 500 items with an average width
>of 10 characters consumes 7500 bytes. Is this a big deal? It amounts to .3% of
>the memory available on a lowly PIII or Zira. Yes, it's true that a palm
>chock-full other programs and records brings the ceiling down lower and lower,
Other programs and records has nothing to do with it. That affects the storage
heap size, not the dynamic memory size. Every Palm OS has the total memory
allocated by the manufacturer with a fixed allotment between storage vs dynamic,
and never the twain shall meet.
Applications and records consume storage heap. MemPtrNew() comes from the
dynamic heap.
And 7500 bytes from the dynamic heap is NOT just 0.3% of the dynamic memory
available on a lowly PIII. You're obviously calculating it based on the full
2MB memory size, and that is not the issue. For the record, a Palm III with 2MB
total memory has only 122KB of dynamic memory available to MemPtrNew(). And
that includes the dynamic memory used for *everything* not in the protected
"storage heap". That 122KB is reduced by some OS structures, stacks, hacks, all
of your other variables, yada, yada.
In reality, that 2MB device has under 100K available to your program for memory
allocations. Within that, the largest available contigious chunk will be
impacted by how much the garbage collector is constrainsted by locked handles,
etc.
If your list width becomes 30 bytes instead of 10, that same list now consumes
about 1/4 of potential memory, not .9% (ie three times your quoted .3% for a
width of 10). What if you have several popups on your form?
In your sample buildList() function, you included the line:
char *src=GetAListItem(i); //this is simplified for brevity
If the text is really obtained by an encapsulated call like that, it is trivial
to use a drawlist function. The callback just invokes GetAListItem() then draws
it at the coordinates passed to the callback.
Look ma, no dynamic memory consumed.
>Whether they delete Minesweeper, or cleanout their memos, I don't care.
>When 7500 bytes is a critical issue, they can't do anything useful with
>my applications anyway.
Minesweeper or memos has NOTHING to do with it. You can clear off all the other
applications and all their associated databases and it won't change the dynamic
memory size one byte (unless you disable installed hacks). The dynamic memory
size is fixed in the device. Compile options can alter the *stack size* within
the total dynamic memory size. It can't change the allocation between storage
heap and dynamic memory.
>This is a small platform for small applications. You can write large applications
>successfully, but to make a user happy with the result, considerable thought
>needs to be given to the API and the way it is intended to be used.
And to the range of devices you intend to support. For most 2MB models, that
means dynamic heap will typically be under 128KB and must also consider what the
OS needs for the stack, open databases, allocated forms, and anything else your
program is doing.
>When a Custom DrawList is called for (with it's attendant execution
>for *each* item in the list),
Wrong. It only gets called for each *visible* item. There is a world of
difference, and that is one of the primary reasons it works so well and is fully
scalable. Regardless of whether the list has 5 or 50 or 500 or 5000 elements,
you only need to obtain the data for the visible rows so at most you're talking
a dozen elements on most devices, and typically the visible size is less.
Even slow devices can typically collect and redraw the visible rows quick enough
for the user to never know the difference during scrolling. And you also never
have a delay when first building the list, regardless of the size of the list.
You also don't have to free the memory when the form closes.
>how much easier/faster is it to simply
>fetch the text from your own store which is already built?
That depends. It can be extremely simple to fetch the text from the same place
that GetAListItem() gets it. And even if somewhat slower per element, you never
do it for more than the visible rows at one time, so it becomes almost a moot
issue.
Also consider a form with multiple popup objects. When you load the form, you
don't even have to populate any of the lists. Until the user hits the popup
trigger, the OS won't need to run your callback, and then only enough times to
fill the visible rows.
So on slow devices, you can put up a form *faster* using drawlist then
allocating and building each list. And if they never open the popup, you don't
have to fetech any elements at all! (You may need GetAListItem() once to obtain
a value to show when the popup is closed, but again that is relatively fast.)
>>Hence, the system
>>/ought/ to be able to accept a callback so that it can retrieve the text to a
>>list item whenever it needs to.
>
>That's a thought, but is it realistic?
Sure it is. By definition incremental search only works with a sorted list,
which is precisely where a binary search is very effective. (Consider how
DmFindSortPosition works.)
>Each character addition would force
>a fetch of all text through the callback...
Do you have any idea how binary searches work? You absolutely would not need a
fetch of all text, nor would you get inconsistent results. The elements would
have to retreived in sorted order, but then that is true of a regular list with
the incremental search attribute set as well...
Whether a binary search or sequential search would be preferable will depend on
the number of items in the list, but the OS knows that too. Either way, it
never has to fetch all the text. Even with a sequential search it can stop when
it hits the first matching element or one which is "higher". Then as more
characters are keyed, it starts there and only reads until the next match. The
only time a full fetch will be required is if the first character is higher than
any entry in the list, and the element count is low enough that a binary search
is not used instead.
>The code is already there. The API already does what you want.
>Applications that use LstSeListChoices() use it freely, because it costs nothing.
It costs dynamic memory, which can be a real issue in 2MB devices (or earlier,
but I don't worry about them...). It also costs time when the form is opened,
so you can build each list. With callbacks, you only have to retrieve the
visible rows of regular lists, and no rows of popups.
>I've been writing for the palm for several years.
Then how could you not understand the difference between storage heap and
dynamic heap on a Palm OS device?
>I remain steadfast in my conviction that LstSetListChoices should be used
>in all but the most trivial cases.
Aside from design-time static lists (the most trivial cases...), I remain
steadfast in my conviction that drawList is the preferred method. Of course,
this also means I am not using incremental search. However in cases where
incremental search would be desirable, I typically just use a table instead of a
list and incrementally search as characters are added to a Lookup field, just
like the standard aps.
>The best Palm apps look, feel and run like the standards
No argument there.
>and the best way to get there, with the smallest
>amount of code is to use the API the way it's designers intended.
And the least amount of code to get there is to use your GetAListItem() inside a
callback, and just draw the string at the coordinates given. All the rest of
your code is completely unnecessary, consumes dynamic memory, and forces the
form open routine to fetch all the rows for every list and popup.
I maintain it is *faster* to only fetch rows as they are needed (or *if*
needed!), it conserves memory, avoids the need to free memory or have a memory
leak, and takes *less* code to implement besides!
But to each their own...
Doug
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
