For mobile apps, is it "best" to load data before transitioning screens?

Question

In a mobile application you almost always make some sort of api call to fetch data to populate view elements on a screen. Say I am on a home screen (screen A) and want to transition to a profile screen (screen B). Should I load the data for screen B on screen A (fetch data for B on button tap on screen A... loading dialog would be displayed)? Or should I transition to B, show a loading dialog, populate data, and dismiss loading dialog.

I've always done the latter, but my only reasoning for doing so is to keep screens and data modular (disclaimer: only Android experience here). This saves me from the headache of passing the fetched data to the screen that's actually using it or saving it in a globally accessible class.

Thoughts?

Answer 1

If someone performs an action (usually selecting a button / icon), you should respond to that action as fast as you can. What that response is may vary, but if you delay responding while you get some data, it will appear that your app is sluggish and the person may think that the action wasn't recognised.

Now, how you respond depends very much on your app. If the icon were supposed to load a video, it would be fine to immediately change to the screen where they would see the video and then show some loading video animation. At least then they know that their action was responded to.

If it were a list and you are loading more elements, then you can easily show a loading animation at the bottom (or top if they are scrolling up) letting them know that you are fetching new elements.

There are many more examples, but I won't go through them all. In short, you should respond immediately, but the type of response should be suited to the application.

---

An exception is where you know before an action is triggered what data you will need to show your customer. In that case, you should load the information in the background so that you can respond as fast as possible without making them wait for anything.

Instagram does this by starting the upload of an image before any filters or effects are added to an image. This makes their upload seem a lot faster than it really is.

Answer 2

As an alternative take or answer to the one given by JohnGB, I would make the api call to fetch the data for screen B while still on screen A and present the user with a preferably subtle indication (loading indicator or dialog) that their request is being worked on. By subtle I mean I tend to prefer displaying the loading indicator on the control if possible.

The reason for choosing this route is one of flexibility. By not transitioning to page B right away and forcing them into viewing an incomplete "view" or some mundane loader, you still give them the option to do some activity on page A or change their minds all together. I prefer to leave these kinds of options open.

Answer 3

I am of the opinion that a screen should only be shown when we have the data to display on that screen. This has multiple advantage and allows the user more flexibility. Showing a blank screen and then auto-magically filling the components with data seems odd. Following are the advantages of Fetch-then-Display over Display-then-Fetch:

• A user can cancel a request and stay at the screen he was already in. If the user accidentally clicks a button, he has an option to cancel the request using the back button(in Android).
• Suppose the user clicks a button on screen A and the data for the next screen B requires a network access. If the screen is shown before we fetch the data and if the network fails, we end up showing the user the error dialog on a blank screen(I have seen this happen in many apps). If the old screen is still shown the user has an option to try some other options.
• There may be screens in the app which the user is not authorized to see, for example some screens are available only for logged in user. This kind of security checks can be made before in the old screen before the new ones are shown.

I have always fetched the data before the new screen is shown. A progress dialog is shown in the old screen which is cancelable and when the data for the new screen is received the progress dialog is removed and the new screen is shown.

One point that I agree with @JohnGB is there are scenarios where we have the UI components already ready, like showing video, and the UI is shown while the data is obtained in the background. For such scenarios Display-then-Fetch is better than Fetch-then-Display but for other scenarios I would recommend fetching the data before displaying the screen.