Scenarios to be considered in making network request (iOS)

There are lot of chat and social networking apps blooming everyday. Network request has an integral part in these apps. In this blog we will see the various scenarios in which the network request can be applied.

We will learn about the scenarios to be considered for network request. Let’s assume that we are not using core data and socket.

1.) View Will Appear:

Consider you are developing an app where you need the updated screen only when the user checks the screen. In this case put request in ViewWillAppear for screens which you would like to have updated data whenever you visit that screen. So that whenever the screen appears we will be updated with the recent data from server.

Objective-C:

          – (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
[self fetchUpdatedDataFromServer];
}

Swift:

override func viewWillAppear(animated: Bool) {
super.viewWillAppear(animated)
self.fetchUpdatedDataFromServer()
}

2.) Background to foreground:

The other scenario is that the screen might not be in the foreground. In that case if the app goes to background and enters foreground means need to put network request to fetch the latest details. You can achieve this by making use of UIApplicationWillEnterForegroundNotification notification. This can be seen evidently in the apps such as WhatsApp where the push notifications play a major role.

Note:* Add the notification in viewWillAppear & remove the notification in viewWillDisappear methods in order to avoid unwanted notifications getting called for irrelevant screens or notifications listening when it’s not used.

In Objective –C:

           – (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(fetchUpdatedDataFromServer)
name:UIApplicationWillEnterForegroundNotification
object:nil];
}
– (void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
[[NSNotificationCenter defaultCenter] removeObserver:self
name:UIApplicationWillEnterForegroundNotification object:nil];
}

In swift:

override func viewWillAppear(animated: Bool) {
super.viewWillAppear(animated)
NSNotificationCenter.defaultCenter().addObserver(self,
selector:”toFetchDetails”, name:
UIApplicationWillEnterForegroundNotification, object: nil)
}
override func viewWillDisappear(animated: Bool) {
super.viewWillDisappear(animated)
NSNotificationCenter.defaultCenter().removeObserver(self,
name: UIApplicationWillEnterForegroundNotification, object:
nil)
}

3.) Pagination:

If we make use of pagination it will be much better way to avoid delay (If we need to get all the data in a single request then it could take long time to get the data) which makes user to wait for long time. Using pagination will get data only when it’s needed. We can set our own limits for number of data to be fetched on each request.  This scenario can be seen in the case of browser view of Facebook. The app will load to a particular set of data and once you reach the bottom then the other set of data will be fetched. This pagination will avoid user waiting for long time and improve user experience.

4.) Pull to refresh:

Use pull to refresh for screens which contains dynamic or ever changing/updating data. We can use pull to request to fetch the latest data from server and update the screen content. This scenario can be predominantly seen in the mobile view of the facebook apps, where you need to pull to refresh. This used in those kind of apps where the data is high if it fetches continuously and hence can be fetched manually when necessary by the user.

5.) Handling network failure & Synchronisation:

For example let’s consider that we are posting a comment for a post or sending a message or mail in those scenarios we could do the following,

i.) Before sending a message check whether internet is connected or not. If it’s not connected then don’t allow the message to get posted instead show an alert to user that you are not connected to network, please try again later.

ii.) Else if you have core data (local DB), you can synchronise the network calls by saving the message in database and whenever network available you can put network request by passing the parameters which is saved in core data.

iii.) In case if you decided to go with synchronising and send stored request when network avails we need to handle an important scenario i.e, if the user logout from the app when there are pending requests in database then while user perform logout we can need to clear all the data(pending requests) form the database.

Other scenarios to be considered:

  • If the initial request failed means we can have the retry option. The retry button may be placed in centre of the screen or in the navigation bar.
  • If load more option i.e, request for certain amount of friends failed means, we can have retry option. The retry button may be placed in the last cell.
  • If user initiates 2 or more requests at the same time which are irrelevant the user will be facing the delay if multiple requests process at a time. In this case we can stop the request which are not needed currently which will reduce the time delay.
  • If you are using the NSURLSession to download the details, we can control the task states. If the app goes to background means you can suspend the task, which is nothing but pausing the request and if it enters fore ground means you can resume (to start from the pause) the task.

These scenarios has to be based on the requirements of the application. If you can define the working and the necessary functions of the application then the network request can be called to fit the needs.

iOS Team,
Mallow Technologies.

Leave a Reply

%d bloggers like this: