Windows phone app not comming back straight to the player after last update

[bhobg]

---

@Peter wrote:
Do you always get this behaviour, even if you move the app to the background and then immediately swap to it again?

---

ALMOST always.  

Because my day job involves being OCD about software bugs, I spent some time trying out variations on this - changing the way I navigate back to the running instance of the app (long-press <back> + task switcher, or just keep pressing <back>), changing whether the "now-playing" song was offline or streaming, whether it was playing or paused, etc.  In all those attempts (and there were dozens), I saw it behave *correctly* twice (i.e., resuming the app actually resumed the "now playing" screen).  I wasn't able to repeat the correct behavior, even with the same input variables, which is weird.

This is the quickest repro possible, probably:

1. Start a song playing, get the "now-playing" full screen;
2. Tap the power button to turn the screen off, and immediately tap again to turn it back on - slide up the lock screen
3. Note that the "now-playing" screen shows up when the app resumes, then flashes, then switches back to whatever screen you were on BEFORE step 1.

Peter, are you NOT seeing this?  Is anyone else not seeing it?  That would make this even weirder...

[Peter__]

Can confirm this is an issue. I'm going to raise it as a bug after I gather more details.

[brunoosti]

It has just updated today (version 4.0.5360.30235).

The problem still there, but it`s working properly sometimes now. 

Even so, i`d guess the core issue is still withing the app. The ting that is broken, and always was, since i`ve had the app, is the history tree or history hierarchy of the app. 

From start it has always mixed its navigation history with the OS history. Each app should have an "internal" history which would serve to navigate within the app. Than, if you hit back as many times to go to the app`s home screen, only there you should go back to any other app or OS home screen. 

I`ve just tried it now, and the right behavior is just not  constant.  Is it that hard to program a history tree that keeps the last screen on memory?? 

maybe it has something to do with how the player handles the OS player vs how it navigates through the musics.

[bhobg]

Hi bruno,

I don't think anything changed (re: this particular problem) in the new update - I saw it work correctly a few times in the previous version, but in the *vast* majority of cases (easily 9/10, maybe 19/20), it didn't, and I could never get the correct behavior to happen reliably.

You raise an interesting point about navigation history in general that I hadn't considered.  There have definitely been times where I've been surprised by where <back> brings me, but I haven't done any even-slightly-rigorous testing around that.  Maybe I will next time I'm listening 🙂

bobg