This question is locked. New answers and comments are not allowed.
During my last Windows Phone app development, i ended up with 2 kinds of busy indicators:
1. When user navigates to a new page (say, page with list, which pulls data from the server), busy indicator should be non-ui blocking, as page is empty (yet).
2. When user fills a form and is going to proceed to the next page, app should wait for server's confirmation (say, login page - server should confirm that user credentials are valid before navigating to another page) - in that case, busy indicator should be ui blocking.
For non blocking progress bar, StatusBarProgressIndicator works quite fine. And here's a behavior i'm using now, which allows binding to VM.
For blocking one, a Modal window (or a grid with ZIndex=1) with ProgressBar is working also quite fine.
What do you think about it?
1. When user navigates to a new page (say, page with list, which pulls data from the server), busy indicator should be non-ui blocking, as page is empty (yet).
2. When user fills a form and is going to proceed to the next page, app should wait for server's confirmation (say, login page - server should confirm that user credentials are valid before navigating to another page) - in that case, busy indicator should be ui blocking.
For non blocking progress bar, StatusBarProgressIndicator works quite fine. And here's a behavior i'm using now, which allows binding to VM.
For blocking one, a Modal window (or a grid with ZIndex=1) with ProgressBar is working also quite fine.
What do you think about it?