Nine-Second Startup on a Preloaded Offline Sales App
Field sales reps use an OutSystems mobile app that opens on a 'My Accounts' screen. On a mid-range Android phone the first screen takes 9 seconds to appear. The screen uses a local aggregate over Account with no Max Records. The module's OnApplicationReady logic preloads all 3,200 accounts and 18,000 contacts into local storage at first login. Each Account also has a 1.5 MB PDF stored in a binary attribute. Reps visit 8-12 rural customers per day and often have no signal. They rarely browse the full book, but the business insists they must be able to search any account by name offline and must see the account header and contact phone numbers. PDFs can wait until connectivity. The team's proposal is to remove offline mode entirely, which would make startup fast. The current first-login sync transfers about 480 MB.
1. Explain where the 9 seconds comes from and evaluate whether removing offline mode is a valid fix.
Read the worked answer
The 9 seconds is mostly self-inflicted. A local aggregate without Max Records materializes every matching row from the device database into the screen's data set, so 3,200 accounts are read and bound before the screen renders. On top of that, OnApplicationReady blocks startup while it pulls 480 MB, including 1.5 MB PDFs per account, into local storage. The PDFs are the dominant transfer, and they are not needed to render the list.
Removing offline mode would make startup fast only by deleting the capability the business requires: today's route must work with no signal, and account name search must work offline. That is not a fix; it is a requirements failure. It would also strand reps in rural areas mid-route.
The correct diagnosis is three separate problems: an unbounded list query, a blocking initial sync, and an overly broad sync scope that includes large binaries. Fixing any one alone will not get startup under control. The screen should load a small, indexed page; the sync should bootstrap only the route data; and the PDFs should be fetched on demand when the rep has connectivity.
2. Redesign the sync scope while preserving offline search of any account by name.
Read the worked answer
Split the data by access pattern. Keep an AccountHeader entity with the fields the rep must see offline: Id, Name, normalized SearchName, phone, and address summary. Add a lightweight ContactPhone entity with AccountId, Name, and Phone. These are small enough for 3,200 accounts and 18,000 contacts to fit comfortably in local storage.
For search, do not load full Account rows. Sync a compact AccountIndex entity (AccountId, SearchName, DisplayName) and run the offline search against it with an indexed prefix or contains query. When online, the same search box can call a server-side search for freshness and broader fields, but the offline index remains the fallback. This satisfies 'search any account by name offline' without preloading PDFs or full records.
For the route, use a SyncUnit filtered to today's 8-12 visits plus a small look-ahead window, and sync it incrementally. The full index can arrive in a background pass after the route is usable. PDFs should be lazy-loaded by URL or downloaded on demand and cached, with a clear offline message when not cached. This keeps the first usable screen small while preserving the offline search requirement.
3. How would you restructure startup so the first screen appears in under 3 seconds, and what would you measure to prove it?
Read the worked answer
Stop blocking OnApplicationReady on the full download. Bootstrap only the minimum needed to render: today's route headers, the account index, and the rep's profile. Render the My Accounts screen from a bounded local aggregate with an explicit Max Records and a filter on route date or search term. Show a non-blocking sync indicator for the background pass, and let the rep start the first visit while the rest of the index downloads.
Order the work: local database open, minimal bootstrap, first screen render, then background sync of the remaining index, then on-demand PDFs. If the device has never synced, allow a degraded first screen with today's route even if the full index is not ready, and make search show a 'still downloading' state rather than freezing.
Measure cold-start time from tap to first interactive screen on a low-end reference device, not on a flagship. Measure the size and duration of the first sync, the number of rows bound by the list aggregate, and the time to first search result. Set budgets: under 3 seconds to first screen, under 30 seconds to a usable full index on 4G, and no PDF in the startup payload. Re-test after each change so you know which fix produced the gain.