Having more Tasks in the Database than allowed in a Cache freezes device when trying to get any Task

[basshelal]

This needs testing with a pre-built and populated DB.

• Have a seeded DB with more Tasks than Task Cache Size Limit, make sure the Cache size is less than the DB size
• Initialize Caches
• Try to get stuff

[basshelal]

A possible fix is to make the Caches load lazily, meaning we only initialize when necessary and only keep what is relevant to the current screen, don't keep so much background stuff running for no reason. Example:

• Open BoardListView -> Only load BoardLists and Boards
• Open a Board -> Only open the Lists and Tasks in that board
• Leave that Board -> empty its stuff (Lists and Tasks) from the Caches etc etc

This might not be the cause of the problem, but it's definitely an optimization we should consider and it might solve the problem even though the cause is most probably something else.

[basshelal]

From Profiling, it seems that this happens only when you open a Board somewhat quickly after loading MainActivity, and when doing so and it freezes, the Garbage Collector is being continuously called and working, as a result memory usage goes up and down so almost constant but CPU usage is quite heavy, the main thread is working VERY hard, hence the freeze. The question remains though, why is the GC working very hard?

This has been solved, see below comment

[basshelal]

From Profiling, it seems that this happens only when you open a Board somewhat quickly after loading MainActivity, and when doing so and it freezes, the Garbage Collector is being continuously called and working, as a result memory usage goes up and down so almost constant but CPU usage is quite heavy, the main thread is working VERY hard, hence the freeze. The question remains though, why is the GC working very hard?

This problem has mostly been solved, was accidentally initializing the Caches twice, the first problem remains and we'll look into the lazy solution

[basshelal]

This has become less urgent, I've figured out where the problem was, still this had revealed major flaws in the current design of the Cache class which now needs to be redone.

Essentially the problem was we were telling the safeGet function to clean and trim if we were inconsistent but the definition of that was both vague and wrong, in one place it meant that if the sizes of the Cache and the DB are different then we are inconsistent, which is wrong when the size of the DB is larger than the Cache limit. In another place it meant when there existed and Id in this Cache that wasn't in the DB, which is all good, but this operation is expensive and this shows when we're dealing with thousands of Tasks.

Anyway Cache needs to be rethought a little, not much to change on the implementation side, just a little on the design and on the API side because the fundamental usage of it will change, still working on it.