It can't be changed, it's handled by iOS not the application itself *edit* hardcoded into the application itself. About Memory Management
There was a very good under the hood session on Go this year at devcon, I don't recall specifically, but I do remember you can't plan against it because it changes not only when FMGo is first launched, but during app switches and other apps being launched on the device as well.
Are you running into a hard crash from overflow? I know systems like EasySync suffer from that on large text strings in memory.
No crashes from overflow, but I was trying to design against the cache value for a layout that has a list view with images. Trying to maximize the number of records that will load before FMGo needs to fetch more.
Basically we have 16GB iPads that only run FMGo. Even at the smallest storage size 16GB is far under used. I might look at a one way sync for images and store them locally on the iPads. Downside is any UI file updates will be larger downloads. Always a trade off.
The best thing you can do is reduce the image size as far as possible.
I'd suggest using GetThumbnail() to reduce the image size to a "portable" size. You might want to move the original images to a separate table that is never sent down to the client.
Unfortunately the images are a big part of the solution and visible quality is also a concern. All the images are 1.5x-2x on the layouts. I have been able to reduce the thumbnails to pretty small sizes. Large images are in a separate table already and they are sent to the client just one at a time only when needed.
I did a test with just the thumbnails I need on the iPad and it is amazing smooth. It was always a fast solution but this is much better and smoother for the users and also gives some basic offline data when needed. There are about 80,000 images in the file. A find can sometimes return up to 1000 records with images that need to be viewed.
I have run into the actual limit now with mostly text. There is still some slight delay in loading records but it seems to be grabbing a lot more at once now and it is faster.
Maybe one day when I get all the other tasks finished I will think about doing a full sync system, but I tend to not like the idea in general. Sometimes it's better to tell people they can't have any data instead of telling them they may have old data and warn them to be careful how they use it.
An optimization for text is to use merge text instead of edit boxes. This speeds up WebDirect a lot, not sure how much it would speed up Go.
That's pretty big stuff, the only other thing I could think of is to preload your data onto an iPad somehow. Local performance will always trump WAN loading.
Thank you for your post and responses.
I was unable to find FileMaker Documentation about the Go Application and it's caching, so I requested some information from Testing and Development which I just received a reply.
It seems the cache is dynamic, not user definable and that the cache will be approximately 10% of the device’s available memory. (Much like Mike described)
I hope this information is of use!