PopToo uses Core Data extensively. However, the way it uses fetched objects is not good for memory management, especially for an app like PopToo, which is focused on running background.
Unlike what’s often recommended, PopToo simply uses a few number of NSMutableArray instances to manage fetched objects from Core Data. Due to the original design structure for sectioning these objects into UITableView based on time or distance, I have postponed to use NSFetchedResultsController instead.
Though the design has worked as I intended, using NSMutableArray wasn’t the right way. As PopToo is running background, new objects will be constantly added, when new stream of PopToo Friends’ check-in data is downloaded and when the user checks-in his media information. Inevitably, memory allocation for NSMutableArrays will be grown until the user terminates PopToo, or the device system does. And as they grow, performance of PopToo is affected, which is more visible when it’s restoring to be active from being background.
For next update, I will refactor PopToo’s workflow to be more suitable for running background. Memory allocation will be strictly minimized, instead fetching objects from Core Data will be refreshed more often. I am fully aware that fetching requires some time and may not be the right solution for better performance, but I am confident it will make PopToo’s lagging issues to be less visible, enhancing the user experience.