2

I am currently implementing a few snapped views, and I've ran into a problem I couldn't find an answer to. Perhaps you beautiful minds can help me out.

When I drag my app from a filled state to a snapped state, there is a period of about 1 - 1.5 secs where the old "filled" view is still displayed in the snapped viewspace. Doesn't look good! I would imagine there would be a standard behavior that should be applied here. Do I show the splash screen? Do I animate in items (and if so, what event should I listen for)?

Thanks for all help!

Edit: Here is a bit of simplified code from one of my views who experiences this lag - a search results page:

<Grid x:Name="LayoutRoot">
  <Grid x:Name="FullViewGrid">
    <!-- Two GridViews containing up to 27 items each (not very advanced) -->
  </Grid>
  <Grid x:Name="SnappedViewGrid">
    <!-- Two ListViews doing the same thing, with different item templates -->
  </Grid>
</Grid>

Basically I'm implementing my own spin of the standard Search Contract template given in VS2012. I have a feeling the CPU is being stressed a bit too much while rendering these changes in the UI - and that's why things aren't going too smoothly.

Kris Selbekk
  • 7,438
  • 7
  • 46
  • 73
  • 1
    Seems to me that the most common is to have the 1-1.5 second view of the old view... But, that doesn't mean you shouldn't do something better :). You can handle the `SizeChanged` event of the window and maybe hide the current view... See http://stackoverflow.com/questions/10362566/how-to-programmatically-respond-to-snap-in-windows-8-metro for more details on detecting view state changes like changing to Snapped. – Peter Ritchie Mar 04 '13 at 17:24
  • Good answer - and thanks :) However, when do I know when I can animate things back again? Is there something like a "RenderingFinished"-event also? – Kris Selbekk Mar 04 '13 at 18:13

1 Answers1

1

Yeah, so this is something you are doing wrong. SnapView doesn't have a delay like that. If you are interested you can review my SnapView walkthrough: http://blog.jerrynixon.com/2012/12/walkthrough-implementing-snapview-in.html

Without a code sample from your app, this is the best I can offer right now. But hopefully this will be all you need to get on the right path for SnapView. Best of luck!

Jerry Nixon
  • 31,313
  • 14
  • 117
  • 233
  • Although I am very much open to the suggestion that my code is far from perfect, I see a lot of apps having this behavior - including some from Microsoft. Your video blog was informative, but I am already doing the same thing. My issue is that it doesn't switch over right away - probably due to an underlying issue in the rendering code used by MS. I've added some code to my original post in order to explain my situation better. – Kris Selbekk Mar 04 '13 at 22:36
  • 1
    So, my recommendation would be for you to extract the storyboard form your viewstate and try to run it outside, testing to see if the storyboard itself has the delay somehow. It is VERY possible that your storyboard is the cause (but not likely that the viewstate transition is the cause since it isn't the cause in other apps). That's also a good practice to improve the perf of your app on an ARM (to test your storyboards externally). If it's super fast outside of the viewstate then... ugh. Let's hope you just find something obvious. – Jerry Nixon Mar 05 '13 at 17:23