Open swisszeni opened 8 years ago
@PoGo-Devs/ui-team
I think that this can be done, Template10, which we're using now, uses this same approach for the Hamburger Menu template (a Shell which contains the pages and keeps the same Hamburger menu over them).
If you want to start playing with it, download Template 10 VS extension, create the Hamburger app and change Shell's style, so that you won't need to deal with navigation logic.
Yes I already know and used Template10 in some other projects. And even MS uses the Shell approach in some of their own Windows-universal-samples. Just wanted to know if some people would prefer a different approach I didn't think of. But doesn't seem like.
Will implement next week when I find time.
@ST-Apps BTW do we have any kind of backlog? Or dev comm channel? Discord seems pretty empty to me
Invited to Slack (and removed your address from here).
My ideas from Slack on this topic: We should have something similar like PoGoMessageDialog without user interaction, just to show things for 1-3secs and dissapear automatically. I would call it PoGoMessageBox. It would have 3 types:
Also those MessageBoxes would be in queue so they won't overlap and will always wait for the previous to finish.
would be warning type (speed is bigger than 60km/h..., that warning is boring some times.
I don't think we should implement the annoying speed warning... unless there is some server component requiring it. Similar to the annoying popup to "watch your environment" at the start of the game. And if we do, I would implement it with a MessageDialog like in the Niantic Apps.
Also we should have
Every awaited server request would get triggered. And at the end for a split second (200ms?) it could turn green/red if request had succeded/failed
If it is not mentioned here yet. We could use this overlay shell for connection status of requests. Instead of Busy.
yeah, well this would be the feature you listed just one post above ;)
We shouldn't add screen overlaying busy indicator (like it is now) anyway.
Better disable buttons durng a running request to prevent unwanted user interaction (or animations).
Yes, but that will be a lot of work to get right. :) Just sayin..
not that much if you hook it up centrally. Set a flag for a running request in the ViewModel, check the flag in CanExecute
in each DelegateCommand and RaiseCanExecuteChanged
on the beginning and end of every request. around 10-20LOC for every VM.
So the official Apps have multiple UI elements as overlays that persist across page navigation and independent of page state.
These are:
My approach to this would be introducing a Shell that manages displaying of these overlaying elements (eg. pass items received, shell shows/hides etc.) and wraps all other Pages of the App.
Did I miss any elements and/or does someone prefer a different approach on handling this?
Functionlist: