Drawing my views is relatively complex and slow. For higher-memory devices, is there a design pattern to draw views in advance, so that switching between them is more responsive?
Would BufferedBitmaps be an option? Or can layers be used to draw something before a view is put on the top of the view stack?
1. Assuming there's some linear flow (user clicks next, and occasionally previous) I would try to pre-draw the next view, and keep the previous (maybe user clicks previous)
2. However you;ll need to…
I don't know your code, but it might be enough to separate calculations from actual drawing in onUpdate into 2 separate functions, and then do the calculations and save the results in an object, and use…
TL;DR
- might be beneficial to schedule any precomputation step using a timer, to avoid blocking the reponse to the current event (e.g. onUpdate, onKey)
- human reaction time / lag != threshold for perceived…
Thanks to everyone who contributed to this thread!
I've completed the refactoring - unless something unexpected turns up during regression testing.
Summary of the Solution (Making Views More Responsive)Views are pre-rendered by generating drawable objects with coordinates. For vector fonts, text elements are rendered as buffered bitmaps.
For all configured sites (i.e., servers), a repeating timer sends web requests. The responses trigger pre-rendering of the corresponding views (each site can have multiple views).
Pre-rendering is broken into small tasks, managed by a task queue. The queue is executed via a timer, which also allows for user input to be processed between tasks.
The web request timer alternates between requesting data for the active view's site and other sites, using a round-robin approach.
Web requests are only executed when the task queue is empty, to avoid overload.
Each view has a dedicated exception handler, which is shared across its related tasks. If a task fails, any other tasks linked to that handler are skipped. This ensures that errors can be localized to the affected view without disrupting others.
Why I'm Happy with the ResultWhile it adds quite a bit of code, it’s cleanly separated from the core application logic, so maintenance is still manageable.
The system scales well, even with multiple sites and views. It’s designed to self-regulate and avoid becoming overloaded.
Memory usage is acceptable for newer devices.
Most importantly, this feature is optional. Devices that don't have enough memory for pre-rendering still work, with only a minor impact on memory consumption.
Potential Future ImprovementCurrently, all views are pre-rendered. As the number of views grows, it might make sense to limit pre-rendering to those nearest to the current view in the navigation structure, to optimize performance.
