What are the benefits of awaiting PushAsync?

Answers

  • VelocityVelocity NZMember ✭✭✭

    Check out this article, particularly the section "Async All the Way".

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Have you read up on await / async in general? Do you understand the concept of asynchronous operations?

  • AlessandroCaliaroAlessandroCaliaro ITMember ✭✭✭✭✭

    I think when you see "Async" you should "Await"

  • NMackayNMackay GBInsider, University mod
    edited July 2017

    Basically you will lock the UI thread if you don't await the navigation push. All your data fetches etc should asynchronous, otherwise your users will hate using the app.

  • heathbmheathbm GBMember ✭✭

    @NMackay said:
    Basically you will lock the UI thread if you don't await the navigation push. All your data fetches etc should asynchronous, otherwise your users will hate using the app.

    I never notcied because the pages load too fast anyway. So it's only beneficial if your new page takes a while to load.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Look at it from the reverse perspective.... Is there a reason to NOT do work (any work, loading pages or otherwise) in an asynchronous way? Isn't it better to have a good multithreaded app, period? Then as it grows over the coming years you dont' have to change anything. If a fast process becomes more intense later - so what, you're already async. Rather than do it synchronous until yo have a problem, then you have to change everything. No advantage to doing that.

  • heathbmheathbm GBMember ✭✭

    @ClintStLaurent said:
    Look at it from the reverse perspective.... Is there a reason to NOT do work (any work, loading pages or otherwise) in an asynchronous way? Isn't it better to have a good multithreaded app, period? Then as it grows over the coming years you dont' have to change anything. If a fast process becomes more intense later - so what, you're already async. Rather than do it synchronous until yo have a problem, then you have to change everything. No advantage to doing that.

    For the most part, I load all my pages in an async Task in the constructor of the page I'm on, store those object. And just use them while navigating synchronously. I don't want to create too many threads, because I'm lazy loading lots of images and data already. I just thought there might have been some weird Xamarin advantage to awaiting that particular method. I actually prefer stopping the user interacting with the page they are leaving, stops them from trying to do something else. Anyway thanks guys for the quick reply.

  • NMackayNMackay GBInsider, University mod

    if you await your not technically spinning up a new thread

    https://stackoverflow.com/questions/27265818/does-the-use-of-async-await-create-a-new-thread

    If you do Task.Run you do start a new thread.

  • Gigex42Gigex42 USMember ✭✭✭✭

    @heathbm said:

    @ClintStLaurent said:
    Look at it from the reverse perspective.... Is there a reason to NOT do work (any work, loading pages or otherwise) in an asynchronous way? Isn't it better to have a good multithreaded app, period? Then as it grows over the coming years you dont' have to change anything. If a fast process becomes more intense later - so what, you're already async. Rather than do it synchronous until yo have a problem, then you have to change everything. No advantage to doing that.

    For the most part, I load all my pages in an async Task in the constructor of the page I'm on, store those object. And just use them while navigating synchronously. I don't want to create too many threads, because I'm lazy loading lots of images and data already. I just thought there might have been some weird Xamarin advantage to awaiting that particular method. I actually prefer stopping the user interacting with the page they are leaving, stops them from trying to do something else. Anyway thanks guys for the quick reply.

    Async Await is no xamarin thing. Its from the .Net Framework 4.5

    When you load your data within the constructor and the user is faster with clicking than getting and storing your data you could get an exception because your data isnt loaded yet.
    When awaiting your load method you can show a loading indicator which prevents the user from accessing no avaible data.

    Your constructor cannot be async. There for you could use the OnAppearing() method of your page which can be async.

  • heathbmheathbm GBMember ✭✭

    @Gigex42 said:

    @heathbm said:

    @ClintStLaurent said:
    Look at it from the reverse perspective.... Is there a reason to NOT do work (any work, loading pages or otherwise) in an asynchronous way? Isn't it better to have a good multithreaded app, period? Then as it grows over the coming years you dont' have to change anything. If a fast process becomes more intense later - so what, you're already async. Rather than do it synchronous until yo have a problem, then you have to change everything. No advantage to doing that.

    For the most part, I load all my pages in an async Task in the constructor of the page I'm on, store those object. And just use them while navigating synchronously. I don't want to create too many threads, because I'm lazy loading lots of images and data already. I just thought there might have been some weird Xamarin advantage to awaiting that particular method. I actually prefer stopping the user interacting with the page they are leaving, stops them from trying to do something else. Anyway thanks guys for the quick reply.

    Async Await is no xamarin thing. Its from the .Net Framework 4.5

    When you load your data within the constructor and the user is faster with clicking than getting and storing your data you could get an exception because your data isnt loaded yet.
    When awaiting your load method you can show a loading indicator which prevents the user from accessing no avaible data.

    Your constructor cannot be async. There for you could use the OnAppearing() method of your page which can be async.

    Guys, please don't waste your time with these question. I Can't delete it. I was only looking to see if there was some perfromance benefit in Xamarin by doing this. Of course I would never use an object that hasen't finished loading. I believe I just spin wait for it to be not null.

Sign In or Register to comment.