How to avoid running out of memory?

Targets iOS
1

With the sample code below, when a database query should return 5000 rows or more, the app silently crashes. When only a few hundred records are returned, everything runs as expected.

What is the best way with Xojo iOS to return a maximum number of rows, and stop before memory is running out?

In such case I would like to inform the user: “Only X out of Y records are shown, because of memory limitations.”

(The database is a CubeSQLServer which AFAIK does not support cursor.)

Var results As RowSet

results = db.SelectSQL(sql)

If results = Nil Or results.AfterLastRow Then
  Self.Title=Self.viewCaption
  MessageBox("No results!")
Else
  
  Self.Title=getTitle(results.RowCount)
  
  Var cellData As MobileTableCellData
  Var adr As Address
  
  // Clear previous results from table
  TableFoundAdresses.RemoveAllRows
  
  // Add new section plus data
  TableFoundAdresses.AddSection("")
  
  For Each Row As  DatabaseRow In results
    
    adr = New Address(Row)
    cellData            = TableFoundAdresses.CreateCell
    cellData.Text       = adr.GetText
    cellData.DetailText = adr.GetDetailText
    cellData.Tag        = adr  // Add address object to table rowtag
    
    cellData.AccessoryType = MobileTableCellData.AccessoryTypes.Disclosure
    TableFoundAdresses.AddRow(0, cellData)  // Add Row to iOSMobileTable
    
  Next Row
  
End If
results.Close
2

Hello,

I would use iOSMobileTableDataSource

It will allow you to avoid all the data in memory, loading only what is necessary for the display.

Also use lowmemorywarning

Another idea is to use memoryused

4 Likes
3

You could use a paging approach trying to avoid memory use abuse.
Use 2 rowsets. One to select and retrieve just the target rowids you want, and another one to retrieve blocks of the details (20? 30?) and process that block, release it after processed, and fetch another one until the end.

4

Yes, I can see that this would be a feasible workaround. At the moment I am looking into the iOSMobileTableDataSource interface, as suggested by yvonnick maçon. If this is solving my issue, I prefer to go with such inherent solutions, rather than creating my own workaround.

BTW, the lowmemorywarning event is not firing fast enough in order to react before the crash, so I’m abandoning this route towards a solution.

5

I really did not paid complete attention to your display problem. Not even noticed I was talking about iOS, for a moment, sorry, my apologies for that. I just had in mind “5000+ rows of multiple data in memory are causing a memory overflow crash, how to overcome?”.
For a table, seems like iOS/Xojo have its own implementation (internalized) and proper DataSource handling for such. Seems the way to go, and the guys that use it seem to agree. Kind of similar but ready? Seems like you need to get the list of rowids of interest, then get and send one row at time on request to the interface. The table engine will take care of everything, including disposal.