Forum› Xamarin.iOS

Best way to combine UI and Web requests.

ConradBrayConradBray GBMember ✭
in Xamarin.iOS

Hi all,

We have an app that makes web requests that can take several seconds over a slow network. The web requests Start and Stop external services. Currently we disable the UI at various points to prevent the user from getting the UI out of sync with the web requests. A simple example would look like this...

User selects item from table ->

  1. Disable UI
  2. Display spinner
  3. Send "Start" web request

Web request completes ->

  1. Enable UI
  2. Push new view to allow user to perform task.

User pushes back button ->

  1. Pop topmost view
  2. Disable UI
  3. Display spinner
  4. Send "Stop" web request

Web requests completes ->

  1. Enable UI

The problem we have at the moment is that under iOS 8 it seems almost impossible to disable the back button. And indeed there is now the "left-swipe" gesture which allows the user to go back through the navigation stack. While there are various work arounds for disabling the back button, none of them seem to be the "correct" approach. All this leads me to wonder if we are going about this the right way.

Is our current approach sensible, or are there better ways to mix UI and web requests?

Tagged:

Posts

  • KrystianKrystian USMember ✭

    Hi @ConradBray you can override default back button like NavigationItem.LeftBarButtonItem = new UIBarButtonItem("Back", UIBarButtonItemStyle.Plain, ()=>NavigationController.PopViewController()); so that way you can specify yourself when navigation back can be performed also this will disable Swipe back gesture

  • ConradBrayConradBray GBMember ✭

    Hi @Krystian,

    Thank you for the response. I was aware we could replace the Back button, and we might go down that route. But it seems that this is forcing the issue rather than doing things the "right" way.

    I was wondering if there was a different approach that was more in keeping with iOS?

  • Tom-PrattTom-Pratt GBMember ✭✭
    edited July 2015

    I think you should always leave the back button enabled. Two options that I would consider are:

    • Cancel any ongoing web requests in ViewWillDisappear or ViewDidDisappear.
    • Let the request finish even if the user navigates away and cache the result ready for if they visit the screen again.
  • ConradBrayConradBray GBMember ✭

    Hi Tom,

    In this instance the Start/Stop web requests allocate resources on the server (a video stream) and we don't want to leak them. I'm not keen on cancelling the requests mid-flight as it leaves the server in an unknown state. As for caching the result - It's a possibility but again, there's no guarantee that the user will go back to that page, and therefore we would end up leaking resources.

    Ideally we wouldn't disable the back button. But allowing the user free reign would ultimately mean that the UI and web requests are completely separate state machines. Right now that's a level of complexity we would like to avoid as, other than this one issue, it's a reasonably simple app.

  • Tom-PrattTom-Pratt GBMember ✭✭

    Yes keeping things simple is a worthwhile goal and can always be tweaked later on. How about if you show your view which initiates the request as a modal instead of pushing it onto the current NavigationController. Modals have no automatic pop mechanism and you will have full control.

    I suspect you will want to modally present a new NavigationController with the view set as the initial view controller, then when the web request completes push the next view onto this new NavigationController stack.

    I would say though, that some of those scenarios you hope to avoid might still be inevitable if users are experiencing poor internet connection or if they suddenly close the app or turn off their phone.

Sign In or Register to comment.