winMobile Memory Considerations
High volume local databases on winMobile devices are possible because of increased internal memory along with removable memory such as SD cards and the like. This opens new possibilities for partially connected mobile apps.
To support these larger mobile databases, higher volume downloads may be needed. Example: Mobile sales order entry may need an extensive price matrix, which can become very large. Frequent massive changes can present challenges.
Because of this, apps that work in low volume may have problems in production volume.
This article presents an overview of the memory challenges when maintaining high volume local databases utilizing host-client synchronization.
1. local databases:
local databases use Storage (i.e. Flash) memory. Some devices save the ROM OS image in storage memory reducing the amount available for apps. Differing partitioning strategies can also segment storage memory in ways that make it difficult to accommodate higher volumes.
In addition, preloaded applications supplied by the hardware manufacturer generally also reside in storage memory making less available to other apps.
For all these reasons, it sometimes makes sense to relocate local databases and working folders to removable storage memory. This generally works well, but important to realize that external storage memory is generally slower than internal storage memory, so performance problems can occur.
2. Download buffer:
MS WinInet FTP and HTTP methods used to download files during synchronization also utilize internal storage memory for buffering. External storage memory (like an SD card) cannot be used for this purpose.
FTP methods have been known to create very large internal download buffers, thus needed much more storage memory- and problems can result. For this reason, we favor HTTP methods for downloading files because less storage memory is consumed. This functionality is transparent to the end user.
3. Rebuilding indexes and record deletion:
Rebuilding indexes can be a by product of downloaded additions or changes and is done in support of various application search capabilities.
Record deletion is used when downloading if an incremental download is not possible, so the local database is maintained by continually recreating database tables, i.e. deleting and the re-adding data.
Program memory is consumed in proportion to the size of the index, or the number of records to be deleted. Volume can grow to make large scale deletion or reindexing not possible.
For these situations, the database is created on the host with the various indexes in place, then downloaded into place during synchronization. This solves most, but not all large indexing issues.
Because of the variables in play (described above)the only way to confirm that a particular hardware configuration will work for a given data volume is to perform volume tests and see if it works.
A strategy may be to locate everything possible onto SD card so as to preempt the storage memory considerations as much as possible, but performance may degrade as a result (SD cards are slower then internal storage memory). Also, this strategy will not alter effects from depleted program memory (like rebuilding indexes).
Answer is to have as much program memory and internal storage memory as possible.
winMobile memory consists of storage (i.e. flash) [non destructive] and program memory (destructive). Early versions of win mobile allowed some configuration of memory for these two purposes, but not so in the later releases.
Guideline for storage memory:
32 MB - barely sufficient for low volume apps. - demo apps
64 MB - marginally effective for mid size volume. - 1-10MB db
128 MB - far more capable - 11-30 MB db
256 MB - wide open spaces - 31-60 MB db
1 GB - the new frontier - > 60 MB db
NOTE: It's not just the raw size of the database that matters here, it's the combined effect of all of the issues discussed above.
Guideline for program memory:
128 MB - minimum.
256 MB or more - wide open spaces
To support these larger mobile databases, higher volume downloads may be needed. Example: Mobile sales order entry may need an extensive price matrix, which can become very large. Frequent massive changes can present challenges.
Because of this, apps that work in low volume may have problems in production volume.
This article presents an overview of the memory challenges when maintaining high volume local databases utilizing host-client synchronization.
1. local databases:
local databases use Storage (i.e. Flash) memory. Some devices save the ROM OS image in storage memory reducing the amount available for apps. Differing partitioning strategies can also segment storage memory in ways that make it difficult to accommodate higher volumes.
In addition, preloaded applications supplied by the hardware manufacturer generally also reside in storage memory making less available to other apps.
For all these reasons, it sometimes makes sense to relocate local databases and working folders to removable storage memory. This generally works well, but important to realize that external storage memory is generally slower than internal storage memory, so performance problems can occur.
2. Download buffer:
MS WinInet FTP and HTTP methods used to download files during synchronization also utilize internal storage memory for buffering. External storage memory (like an SD card) cannot be used for this purpose.
FTP methods have been known to create very large internal download buffers, thus needed much more storage memory- and problems can result. For this reason, we favor HTTP methods for downloading files because less storage memory is consumed. This functionality is transparent to the end user.
3. Rebuilding indexes and record deletion:
Rebuilding indexes can be a by product of downloaded additions or changes and is done in support of various application search capabilities.
Record deletion is used when downloading if an incremental download is not possible, so the local database is maintained by continually recreating database tables, i.e. deleting and the re-adding data.
Program memory is consumed in proportion to the size of the index, or the number of records to be deleted. Volume can grow to make large scale deletion or reindexing not possible.
For these situations, the database is created on the host with the various indexes in place, then downloaded into place during synchronization. This solves most, but not all large indexing issues.
Because of the variables in play (described above)the only way to confirm that a particular hardware configuration will work for a given data volume is to perform volume tests and see if it works.
A strategy may be to locate everything possible onto SD card so as to preempt the storage memory considerations as much as possible, but performance may degrade as a result (SD cards are slower then internal storage memory). Also, this strategy will not alter effects from depleted program memory (like rebuilding indexes).
Answer is to have as much program memory and internal storage memory as possible.
winMobile memory consists of storage (i.e. flash) [non destructive] and program memory (destructive). Early versions of win mobile allowed some configuration of memory for these two purposes, but not so in the later releases.
Guideline for storage memory:
32 MB - barely sufficient for low volume apps. - demo apps
64 MB - marginally effective for mid size volume. - 1-10MB db
128 MB - far more capable - 11-30 MB db
256 MB - wide open spaces - 31-60 MB db
1 GB - the new frontier - > 60 MB db
NOTE: It's not just the raw size of the database that matters here, it's the combined effect of all of the issues discussed above.
Guideline for program memory:
128 MB - minimum.
256 MB or more - wide open spaces