Managing Autorotation in Windows 8 metro apps - c#

How can i manage Autorotation Windows 8 Apps.
I have gone through the "Rotation" Sample from MSDN but it is hell lot confusing, what I need to do is , I need to have completely different view when in Portrait and a diiferent one in Landscape.
I have designed my view for Landscape when I need to make changes for Portrait View. I need a way to dynamically switch between to views of re-shuffle the views.

By far the easiest way to deal with this is to inherit your page from LayoutAwarePage instead of Page and leverage the Visual State Manager inside of Expression Blend to do all of the work for you.
I have a full article with lots of pictures and a downloadable sample application here:
http://jaredbienz.wordpress.com/2012/04/22/wp-to-w8-view-states-using-visual-state-manager/

You're definitely going to want to use a FlipView control here. I don't know if you're using JavaScript/HTML5 or C#/XAML, but it is available in either case.
There's a great sample on MSDN to show you how to do it, but without more context on your issue, I don't know how much more I can assist.
http://code.msdn.microsoft.com/windowsapps/FlipView-control-sample-18e434b4

You can handle orientation changes in two basic ways...
1) The brute force approach. Wire into the orientationchanged event...
Windows.Graphics.Display.DisplayProperties.OrientationChanged += DisplayProperties_OrientationChanged;
In the event handle, check the orientation and navigate to a page that has been specifically layout out for that orientation...
if (Windows.Graphics.Display.DisplayProperties.CurrentOrientation == DisplayOrientations.Portrait)
this.Frame.Navigate(typeof(PortraitPage));
Pros... easy to design pages optimized for given orientations
Cons... need to handle navigation and state data between pages
2) Create a single page that changes its layout using visual states. You would still wire into the orientationchanged event, but make calls to VisualStateManager.GoToState(this,"Portrait",true).or something similar depending on how you name your visual states.
Pros... change layout without navigation and you can add cool animations easily
Cons... more complex layout could be harder if you are not comfortable with advanced xaml layouts and viewStates
If you look at the sample templates (besides blank) they include a LayoutAwarePage that handles the viewstate transitions for you, simplifying things a bit.

Related

Windows Store WebView Alternative

I am using the WebView extensively in a project but find its shortcomings to be a showstopper for the project. Are there any alternatives that can render HTML in windows store apps?
Edit: As requested, some of the problems we have with this control:
It has no dependency property support, you need to call the methods (workaround needed: wrap it in a custom control, or attached properties...)
It cannot render local html files (workaround with navigatetostring)
If local html files contain extra files, like css or js, you need more workarounds to make it work
It is a IE10 rendered above your application so it covers other controls (again you need that awful - sorry - webbrush workaround)
Animations do not work well when put in a Listview (scrolls faster than other controls, also stretches weird), there is no workaround
Animations do not work at all when put in an animated flyout, there is no workaround
It breaks semantic zooming in portrait mode (besides needing the webbrush workaround for it to work) for unknown reasons if you zoom in. It works in landscape and in portrait as long as you do not navigate anything, but do not never anytime navigate a website and it breaks the zooming.
There are probably more issues we had, these are the ones that made us consider it a showstopper
We had the same problem but solved it with the much more, not "shortcoming" alternative in this XAML Toolkit for WinRT.
There is a WebBrowser control you must have a look at.

How to accomplish different states of view in WPF Apps

I have an idea for a personal project. And I know one way of accomplishing it in Windows Forms (which I no longer wish to use). Basically I could (in WinForms) just draw everything onto the screen (Form) and then when I need to switch views/states of the application, just redraw the new stuff in the old stuff's place.
But how can we have different states in WPF? Is there a "right" or "proper" way of doing this? Is something like this covered somewhere in the docs?
I'd like to do my own searching, but I have no idea what exactly to look for, and current attempts at finding the right information, so far have yielded no helpful (or even relevant) results.
Any help at all will be greatly appreciated. I am new to WPF, but have been making a lot of progress this past week!
Thank you!
P.S.:
I just thouhght of something. If the solution was to draw what is needed for one screen, and when it is time to display the next screen, just dispose of/hide everything and create/display the new stuff, then how would we get around this? Because we can't/shouldn't change XAML markup at runtime, can/should we? :/
Not sure how you drawn your views/states in WinForms (direct painting on a Graphics object?).
The closest to what you're describing is the VisualStateManager. You can use it to statically define several visual states inside a single XAML and transit between them (using a smooth animation if you want).
If what you've done was show different Forms with Show/ShowDialog(), then the equivalent would be to use different Windows and Show/Hide them.
If you just cleared/added Controls to your form, then you can do just the same in WPF. Most Controls in WPF have a Content or Children property instead of Control.Controls in Forms.
I don't know if I understand what you really want. But here are my thoughts:
You can use several Windows and Show/Hide them accordingly
You can use the Frame/Page functionality in WP (MSDN)
if you really need to you could load your XAML and remove the topmost content in your Window and replace it with the loaded content
You could use the VisualStateGroup functionality to change the appearance of your current window
I think you will be happy with the second solution

Handle navigation between several view in a WPF application

I've done several WPF application(not using MVVM) in the past and I had always to implement my own system of navigation between view(instantiate the view once, and then load in a container component, with refreshing required components of my view).
It works, but:
It's always custom, so if a new developer comes he has to learn of it how it works
I'm pretty sure that It's not the most optimized(most of things haven't been done in background worker, ...)
It's a time loss
So I was wondering if there is an official way to handle this ? I don't exactly how, but I was thinking to a navigation component, which can act a little like a tab panel, or a little like the MVC framework in asp.net, we can call a specified controller for an action and some parameters.
Maybe deactiviting bindings when they aren't in the current view
You can use DataTemplates/Styles to customize content of your control ( not only apearance, but data, cause that what you're asking for I presume)
http://msdn.microsoft.com/en-us/library/ms742521.aspx
You can have one Host control and at runtime change its appearance based on events/ states.
Like an example can have a look here:
http://code.google.com/p/svnradar/ how this program manages a appearance of Group and Flat view of repository information.
Another example:
Podder of Josh Smith
http://joshsmithonwpf.wordpress.com/2008/03/05/podder-v2-has-been-released/
Hope this helps.
You may be interested by Lakana, a lightweight (but powerful) framework that can handle for you all the navigation concerns !
Riana

using usercontrols instead of windows

I'm not sure if this is a bad way of building an application but let's say I have 30 WPF Windows for different screens in my application. I want to build them into a DLL so I was wondering if it is bad design to instead of creating each window as a window, if i can have 1 window that hosts whichever screen is open. So the windows will actually be a usercontrol, or at least act like one.
So when you want to go to a different screen, you would just change the content of the 1 window to the content of the "usercontrol" that you want displayed. Does this make sense, or can you see issues with possibly doing this? Thanks.
That may be a good approach but you need to think about whether every screen belongs in the same window. For example is every user control going to use all of the space in the window, or will you have some visual issues? The content of your windows, your data, and how the windows manipulate that data may also have an impact.
You may want to look into design patterns such as MVC and MVVM (more popular with WPF).
This sounds like a much nicer solution than 30 separate windows :) Nothing wrong with it.
You might want to do some reading about presentation patterns to get a good understanding of how to manage applications with multiple screens. Take a look at this excellent (but incomplete) wiki on Presentation Patterns, based on a book in the making by Jeremy Miller with contributions from the great Martin Fowler.
Read through a summary of each of the patterns to get an idea if it applies to your situation, and if it does try Googling around. Many of the patterns in that wiki have evolved fairly recently and the best resources for them so far are disparate blog entries and obscure mailing lists. But it's worth doing the digging because there are some truly inspired gems of information to be found in this arena. Presentation patterns are a very interesting thing!
From what you told I'm thinking that maybe Pages are better for your use than controls. In that case you can user Frame control in main window to support navigation between pages (or hide navigation buttons and navigate from code directly).

Difference between Panorama and Pivot Control

What is the difference between the winphone 7 Panorama and Pivot Controls? To me they seem very similar, apart from the slightly different visual appearance.
In which situations should one or the other be used?
There is a video on Channel 9 with Amy Alberts and Chad Roberts that talks about the differences between the Panorama and Pivot controls and when you should use each.
In my opinion, the Panorama control is for when you need to create a "hub"-type application (like the Games hub) that acts primarily as a jumping point and offers summary information for the rest of the application. The Pivot is used in much the same way that you would use a tab control on other platforms.
As said above, the Panorama control is really meant for rich Hub type look .. smooth multi-screen scrolling with Parallax effect, ideally including images in the views. The Pivot control is more for presenting slices of the related data to the user or categorizing the content .. the in-built emails & calendar are examples. Both controls are very suited for dynamic data-binding.
Jeff Blankenburg, one of the MSFT evangelists wrote two nice posts explaining their use:
http://www.jeffblankenburg.com/post/31-Days-of-Windows-Phone-7.aspx
Hope this helps!
I would use the Panorama control if the content of your application lends itself to being presented in a format where you think of the screen as being a window into a larger page...one that can loop back around to the beginning. Also, consider whether that content needs to support gestures, especially swipes, because those will cause conflicts between some action intended to take place in a control, for example a map with panning, and the "outer" Panorama control's behavior of scrolling.
I'm also reconsidering using the Pivot control. It has a more distinct division between sections of content than Panorama does and I like both the gesture swiping to switch between pivots and the animation. However, it has caused some tombstoning problems and with the advent of copy-and-paste there could be a conflict between the user trying to select content to copy and the triggering of the swipe gesture to switch pivots. Disabling the Pivot Control swipe gesture talks about a possible work-around, although I haven't tried it and see from the comments below that article that there may be some other issues.

Categories

Resources