Xamarin.forms: Error on Suspending iOS App when api call is in progress [Bug]

Created on 29 Jan 2020  ·  9Comments  ·  Source: xamarin/Xamarin.Forms

Description

Steps to Reproduce

  1. Run iOS Application
  2. Press button that calls a long running http request
  3. Press the Home button
  4. If the task is still running it will error and crash the app

Expected Behavior

Task Should complete and application should not crash

Actual Behavior

Errors and crashes the application.

Basic Information

  • Version with issue: 3.6.0.264807+
  • Last known good version: N/A
  • IDE: iPod actual device
  • Platform Target Frameworks:

    • iOS: 13

  • Nuget Packages: N/A
  • Affected Devices: All

Screenshots

N/A

Reproduction Link

Workaround

I don't know how to work around this issue

high iOS 🍎 needs-info ❓ needs-repro ❔ unverified bug

All 9 comments

@james1301 Can you please attach a small project that demonstrates this issue? Thanks!

Since we haven't heard from you in more than 30 days, we hope this issue is no longer affecting you. If it is, please reopen this issue and provide the requested information so that we can look into it further. Thank you!

Hi sorry @samhouts I hadn't responded. Here is a sample app. To duplicate:

  1. Run App on simulator
  2. Click Hit me!
  3. Click Home button to minimise app
  4. Error

System.Threading.Tasks.TaskCanceledException
Message=A task was canceled.

TestApp.zip

Is this the expected behaviour? What are the recommended approaches to mitigating and improving this? It makes it a little bit complicated to design your app to always allow for any tasks to be cancelled within your app, and then be able to resume from that point later on.

And for example if a user clicks save then home to go to a new app, I think they would expect it to be saved.

Struggled to find much documentation on this.

@james1301 What you're seeing is basically the standard behaviour on iOS. When an app goes to the background it has only a few seconds to finish what it's doing before the OS stops it completely. Not sure if you've seen it, but this https://allancritchie.net/posts/introducingshiny might help!

@programmation no I hadn't come across it before. Are you saying that adds some central location for handling such events? Might be missing quite what the advantage of it is?

In my example of saving an item, call it a to do item and the user clicks the home button straight away. That process may take a little time to run. Are we saying that will be cut off straight away? In the sample app it seems to be pretty immediate?

Are we saying I essentially need to catch task cancelled everywhere and handle it?

@james1301 so the principal advantage of Shiny is that (among many other things) it abstracts the background-processing capabilities of each platform into a single API. HTTP requests are not able to run for long (i.e. more than a few seconds) in the background by default. However, each platform has a mechanism to allow long-running tasks to continue in the background even when an app is stopped by the OS. Shiny takes care of the details of that process and gives you a nice .NET API for it.
In the app I work on, we don't currently use Shiny (but I want to!) although we do catch cancelled tasks. Unfortunately, the cause of the cancellation is often that the app went to the background. We are fortunate that our servers are fast and our network access is generally good, and up to now we have simply allowed the user to refresh the screen if something failed. This works well enough for us in our situation, even though perfectionist-me isn't terribly happy with it.
However, if your app expects to be able to survive in poor network conditions, then I think catching cancellations will be something you will need to plan for, and Shiny may give you a short-cut to reliability in your HTTP work.

Sounds good, thanks for the detailed reply @programmation.

I guess my only question would be are their any plans to build this kind of stuff into Xamarin Forms by default? It seems common to me that people would be dealing with an API and these issues would be for a lot of people. And generally I know a little about Apple cutting off connections and stuff like that but it's not clear how that would occur from Xamarin side of things. Or how to make use of backgrounding.

Or a few bits available in Shiny sounded similar to Xamarin Essentials, is this not something they would look at?

@james1301 I can't speak for Xamarin folks about what they may or may not want to do :) but I agree it's a common enough scenario that a helpful framework could get concerned about trying to solve it. Shiny is the only framework I'm aware of that tries to tackle the issue in a coherent way, and you're right it does have a lot of overlap with Essentials.
Happy to continue this discussion away from this thread - david at my domain if you want to DM me.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

allessandrosj picture allessandrosj  ·  61Comments

hartez picture hartez  ·  55Comments

EdoardoCinelli picture EdoardoCinelli  ·  92Comments

dannythomas13 picture dannythomas13  ·  56Comments

juepiezhongren picture juepiezhongren  ·  66Comments