I come from mainly a web development background (ASP.NET, ASP.NET MVC, XHTML, CSS etc) but have been tasked with creating/designing a Silverlight application. The application is utilising Bing Maps control for Silverlight, this will be contained in a user control and will be the 'main' screen in the system.
There will be numerous other user controls on the form that will be used to choose/filter/sort/order the data on the map. I think of it like Visual Studio: the Bing Maps will be like the code editor window and the other controls will be like Solutions Explorer, Find Results etc. (although a lot less of them!)
I have read up and I'm comfortable with the data side (RIA-Services) of the application. I've (kinda) got my head around databinding and using a view model to present data and keep the code behind file lite.
What I do need some help on is UI design/navigation framework, specifically 2 aspects:
How do I best implement a fluid design so that the various user controls which filter the map data can be resized/pinned/unpinned (for example, like the Solution Explorer in VS)? I made a test using a Grid with a GridSplitter control, is this the best way? Would it be best to create a Grid/Gridsplitter with Navigation Frames inside the grid to load the content?
Since I have multiple user controls that basically use the same set of data, should I set the dataContext at the highest possible level (e.g. if using a grid with multiple frames, at the Grid level?).
Any help, tips, links etc. will be very much appreciated!
Microsoft has created a great community site for helping people get started with both design and Silverlight here: http://www.microsoft.com/design/toolbox/
It may be far more than what you need for your current project, but it definitely will give you the training you need to master Design with Silverlight.
Related
I have an application (a medical therapy kind of) in which there are more than 500 pages to navigate through and some processing is done in some of the pages. How should i design such an application.
Currently I have a main window on which there is a frame and inside the frame I am embedding these pages, but for each page I have to create that much number of xaml pages ( I feel its bulky creating such huge number of xaml pages).
Can anyone suggest a better design or approach.
There is a framework designed specifically for this type of large composite applications.
The framework is PRISM 4, see: http://compositewpf.codeplex.com/
Prism provides guidance designed to help you more easily design and
build rich, flexible, and easy-to-maintain Windows Presentation
Foundation (WPF) desktop applications, Silverlight Rich Internet
Applications (RIAs), and Windows Phone 7 applications. Using design
patterns that embody important architectural design principles, such
as separation of concerns and loose coupling, Prism helps you to
design and build applications using loosely coupled components that
can evolve independently but that can be easily and seamlessly
integrated into the overall application. These types of applications
are known as composite applications.
It sounds as if the application is mainly a document viewer. If that is true then the document could be stored in some sort of markup with some sort of special trigger for active content that includes processing.
When displaying a page the application would process the markup and convert it to WPF display format and when active processing requirement is detected the program could insert specialized user controls or use some other system for interacting with the page.
Taking a cue from #Doug, it appears you are looking for a document viewer. In that case, I think what you really want is just a "virtualized document", where only the page currently presented instantiated (somewhat similar to Virtualized Stack Panel, which is what ListBox is using).
In recent year I became a great fan of the MVVM design pattern. In your case, I think in your View Model you should have a currentPage property (a sub view model), and a view (i.e. XAML) that knows how to render this page using Binding - probably a Data Template.
As you move between pages, you'll just change the currentPage property in your ViewModel. Everything should update automatically (once INotifyPropertyChanged is implemented correctly). If rendering the View is too slow, consider adding a cache mechanism.
I am building a rather large WP7 application and having a lot of fun with it. It is Pivot based and has quite a lot of pivot pages. I dynamically add and remove pivot pages based on what "mode" of the application the user has selected to keep the application look and feel as simple as possible. All is going quite well so far my app is fast responsive, not a memory or resource hog and performs background loading on demand when needed.
The Model layer contains all my business logic that represents what the application is all about. It is clean and separate from the the view-model and view layers.
The View-Model layer is an abstraction of the model to the extent that it needs to interact with the view and also contains the session-ness and workflow aspects of the application in general. It contains objects which represent the Model in a way the View needs to interact with. The view model persists the state of the application in isolated storage and supports tomb-stoning.
The View layer contains a lot of elements pivots, user controls, styles, resources etc in both xaml and the corresponding code behind. I do like Blend and the Xaml designer within visual studio 2010 however I find myself still coding/configuring the view objects within the code behind due to the nature in which they interact with each other. The code behind of the view objects is becoming quite large but still only reflects the state of the view and not the state of the application. I have made use of user controls quite a lot as this lets me build reusable components across many pivot pages however the user controls are not Blend friendly. What I am worried about is that my view might becoming more complex than it needs to be and losing the ability to coordinate the user interface design with tools like expression blend.
By customising the view this way and making use of reusable controls I have reduced my Xaml considerably and don't suffer from bloated Xaml files that other developers have mentioned but lost ability to co-ordinate with Blend. Is there are happy medium to be found? Should I be looking at designing custom controls?
[Edit]
Thanks for your reply. I think it boils down to either a lot of Xaml with a designer or break it down into user controls with more code behind. Since I moved into user controls my mindset has moved back to doing things by hand rather than with a designer (better the devil you know right!). My thoughts are should I make my user controls into skin-able custom controls or just keep going how I am and avoid using the designer. Its a bit of potato-potardo but I don't want to get into bad habits.
Custom Controls (or Templated Controls) are not directly related to your question as far as I can see. Custom controls are just controls that add new properties, events and methods to an existing control and are still capable of being 'templated' by a designer.
Creating UI in code does make it harder to design the application using Blend (and even the VS designer) because the only way to see the interface is by running the application.
A lot of the logic that creates the UI could possibly be replaced by using the Visual State Manager. Use states of the controls to design them for specific modes of the view. Only when you need extra/new states you will have to create a Custom Control.
As your question is a bit wide, feel free to add comments or extend your question so I can add more details or remove this answer when it is utter nonsense :)
I am starting on a silverlight application and my MainPage is getting to be fairly large. I am not sure how to properly make a silverlight app in terms of object orientation or separating things into multiple xaml pages. Is it normal to have all of your application in the MainPage? For large elements such as a drawing tool, do people make custom controls and then add them in the main page?
I'm not really sure how to set this up and was hoping someone would shed some light on what the normal architecture of a silverlight app is.
As Steve B suggested you should look into MVVM and use that basic pattern to separate your application into views, models and view-models which bridge the gap between the view and the underlying models. The pattern is not difficult and works very well for data binding in WPF and SilverLight.
To manage the complexity of your main page use multiple UserControls to keep different parts of the UI in different files.
I apologize for my newbie question by why do WPF apps look like web pages?
I am new to gui and still shopping for a book to learn gui programming. The push seems to be in the direction of WPF but all the screenshots of WPF applications that I've seen look like cheap web pages. Frankly I'd be ashamed to sell an app that looked like a web page.
I realize that WPF is built on XML technology but can you not build normal looking WPF apps in Visual Studio (via button("widget")) drag-n-drop? In other words an app that does not look like a web page?
How can WPF be a replacement for WinForms or the like when it doesn't provide the same standard application look?
The default look of WPF applications is admittedly rather simple, but WPF allows unprecedented control over how your application looks.
Here are some examples, all of them WPF applications.
If you are to deveop an application under .net and are able to target .net 3.5 or above, you will want to use wpf. If you don't know much about ui technology and want to work with .net, understanding windows forms is useful but not necessary. You should learn wpf regardless.
2 perks that I have found while using the framework:
- it is very easy to inject branding and custom interactivity into your app. It is then very easy to change these when your sales guy decides the want it blue, not red.
- the way components are organized on screen is relational like a webpage, not coordinate based like windows forms. This is ideal for scenarios when translated strings will change length (English to German for example). Under usual circumstances the ui will resize itself automatically at runtime to make it all fit.
If you just throw in controls and don't change the style of anything, your first wpf applications will look almost identical to native win32 applications. It is very easy to change this, but you will achieve great results regardless of the "look" you choose. Microsoft also provide the tools to create new ui components that look like native buttons. There are a host of other features that will make you grin while learning!
This is not a technical note, but at the moment wpf is a highly sellable skill and looks great on a cv! Companies want great branding in their apps. Wpf helps that happen.
WPF does provide the same appication look wich is the default look. When you drag and drop your controls onto the design surface (just like in windows forms, MFC ...) the controls look as you would expect them to look under the current theme. Chances are that you have seen quite some WPF applications without noticing. Just because they look like any other app.
The reason you might see more WPF based applications that have some sort of custom look and feel to them is simple because it is so much easier to do what ever you like to your GUI than in any other GUI framework on any platform. This is both blessing and curse. While you being absolutely flexible it is easy to do absolutely horrible stuff.
user440267, I believe that the most application in WPF are built using normal Windows. But there is an option which we don't create a window, instead we create a page, which behave like you think.
I am developing a WPF desktop app for a small business. It will have a dashboard with 4 buttons that should show a corresponding window/form.
Examples -
Manage Entries
Admin
Reports
Help
Each of these has a separate form with lots of controls and stuff.
Is it best to have each of these as a separate window (including dashboard) and show them when a button is clicked in the dashboard?
Or is it possible to have just one window with these 4 buttons on top, and swap the contents below depending on the button?
I am kind of new to WPF apps so I don't know whats possible and what is the best-practice.
What you will find with WPF is nearly anything is possible from a UI perspective.
It is definitely possible having one window and swapping the contents below depending on the button. A pattern I like is PRISM which has some interesting patterns and best practices on achieving composite windows in both WPF and Silverlight.
You could also look at the MVVM pattern, which is becoming really popular with WPF. Josh Smith has many great articles for this.
Also, if you are really new, have a look as User Controls, as this allows you to easily modularize certain sections.
What I found with myself was with my first few WPF applications, I approached it from a Winform's mindset - but then after really getting a second look at Binding, these other patterns really began to shine.
One best-practice approach is to use Composite Application Guidance. Basically it is an application design approach which contains a shell and multiple views which are arranged inside it. Microsoft has released a CAG library called Prism through CodePlex, and has provided tutorials and documentation for it on MSDN.
CodePlex Link: Composite WPF and Silverlight
MSDN Link: Composite Client Application Guidance