I'm having a little trouble as I decide how to structure my projects. This question is slightly subjective, but I'm having trouble conceptually.
If I create a wpf blend project (sketchflow right now), it creates two projects, "Project" and "ProjectScreens". Is this the best layout to use?
The issue is, I have classes and code (networking, file i/o, etc.) that I need to reference within the screens (i.e. they click a button, it creates a network connection), and the core code needs to reference the screens. This creates a circular dependency.
I've tried merging them all as a single project, which works, but it stops becoming a sketchflow project at that point.
I guess the big thing, what's the best way to structure this with my core code and my sketchflow prototype?
Check out the Model-View-ViewModel design pattern. You'll find it fits well for WPF (and Sketchflow) projects because it keeps your business logic independent of your UI and supports the binding-oriented development model of WPF.
The SketchFlow project is separated into 2 assemblies so that you can do all of your work in the screens assembly, and then later re-use what is in the screens assembly elsewhere if you want.
The main project is a very simple wrapper that enables the use of the SketchFlow runtime player.
Related
Is it possible to convert wpf desktop application to wpf browser application? I want to make my application run from browser.
According to my experience there is no converter available which converts WPF to XBAP.
But I did work with multiple platforms together several time in my project. I do maintain 3 platforms together WPF, Silverlight and XBAP in a single solution having single code base. I keep a common code-base and share files between 3 platforms. To achieve this I suggest you to create a Hello world XBAP application and run it first. You need to have few basic idea about how an XBAP application works. Initially understanding the entry and exit point of the application will be enough for you. Try adding one button in Page and understand how it works. Once it’s done then try to link the existing project files (XAML and CS) one by one into the XBAP project. Understand what you are adding and why are you adding. Yes it's quite a hard work you need to do. But don’t worry XBAP, WPF XAML & C# codes are almost similar. You need to know that Conditional compilation symbols can be set in project properties. So that you will be allowed to write #if XBAP & #endif statement in your code sometimes, because few classes or features may not be supported in XBAP and you need to write specific code for XBAP. As an example Dropshadow related features are not available in XBAP.
Hope this answers your query!
I have a simple Silverlight app that I want to run on Windows Phone 7 almost exactly as is. I've created a new Windows Phone 7 project and when I reference the Silverlight app I get a warning that says "Adding a reference to a Silverlight project might not work properly. Do you want to continue?".
If I continue and try to run anyway, the WP7 project never starts or sometimes I get "AG_E_PARSER_BAD_TYPE error" and it points to the line in the xaml I used a control from the Silverlight project .
The code between these two projects is about 99% the same. Is there another way to reuse code then what I am trying? Or how can I get this to work?
I'm not that familiar with the difference between the two platforms, but you can link the code files into a different project without duplicating them. Add existing item, and click on the down arrow next to the 'Add' or OK button. Choose Link.
The typical way of achieving this is by using a pattern like MVVM which will allow you to define a common model and viewmodel layer (perhaps in a separate project) the defining a different view layer that references that common project.
You said it yourself, you will only share MOST of the code, not all of it, so you will, at least at some time, need to create device/front-end specific logic and layout.
Rather than add a Silverlight [presumably class library] project to your WP7 app, try creating a WP7 class library and then link the files from the silverlight library. You will still only have one copy of each file but all your libraries will be built appropraitely for the platform they are running on.
This may also help you identify the cause of the problem. The error AG_E_PARSER_BAD_TYPE suggests that you have a type in the XAML in your Silverlight project which isn't supported on the phone.
A while ago, I posted a question regarding switching between a Blend-authored GUI and a Visual Studio-authored one. I got it to work okay by adding my Blend project to my VS2008 project and then changing the Startup Application and recompiling. This would result in two applications that had completely different GUIs, yet used the exact same ViewModel and Model code. I was pretty happy with that.
Now that I've learned about the Laurent Bugnion's MVVM Light Toolkit, I would really like to leverage his efforts to make this process of supporting multiple GUIs for the same backend code possible. The question is, does the toolkit facilate this, or am I stuck doing it my previous way?
I've watched his video from MIX10 and have read some of the articles about it online. However, I've yet to see something that indicates that there is a clean way to allow a user to either dynamically switch GUIs on the fly by loading a different DLL. There are MVVM templates for VS2008 and Blend 3, but am I supposed to create both types of projects for my application and then reference specific files from my VS2008 solution?
UPDATE
I re-read some information on Laurent's site, and seemed to have forgotten that the whole point of the template was to allow the same solution to be opened in VS2008 and Blend. So anyhow, with this new perspective it looks like the templates are actually intended to use a single GUI, most likely designed entirely in Blend (with the convenience of debugging through VS2008), and then be able to use two different ViewModels -- one for design-time, and one for runtime.
So it seems to me like the answer to my question is that I want to use a combination of my previous solution, along with the MVVM Light Toolkit. The former will allow me to make multiple, distinct GUIs around my core code, while the latter will make designing fancy GUIs in Blend easier with the usage of a design-time ViewModel. Can anyone comment on this?
I checked your previous question and this one, and I had never really heard about switching projects to work in Blend and in Studio, and end up with two different UIs. I think this was not the intent of MSFT when they built Blend. Instead, the possibility to open the exact same project and code files in both IDEs (and all the discussions I had with the various teams at MSFT) hints that the intent was in fact to have one application only which can be edited in both environments.
I think that in the end, the goal is to have a variety of tools that you can use to edit your UI - XAML, Visual Studio designer, Blend. Depending on your role in the project (developer, designer, integrator) and depending on your ability with the tools, you can choose one or the other.
This doesn't mean that we never switch templates! Depending on the kind of application (for example between a SL4 desktop application or a WinPhone7 application), we use the same ViewModel (and below) code, but slap a different UI altogether on the files. I demoed how to do that in this video:
http://channel9.msdn.com/posts/kreekman/TechDays-2010-Understanding-the-Model-View-ViewModel-pattern/
This is the same talk I gave at MIX but extended by 15 minutes where I show how to reuse the ViewModel and model files, but use a completely different UI for WinPhone7.
Another application is switching templates when a window is resized (used very often in WPF, but also applicable to Silverlight) in order to show less details or a different layout for different screen sizes.
I hope that this reply doesn't confuse you :) and in fact, I'd love to hear your comments on that before we continue the discussion.
Cheers,
Laurent
I think MEFedMVVM would be a good candidate for this. It is simple and you can combine it with other frameworks.
I have a PRISM based silverlight solution under source control. In regards to theming I have a project for each theme, for example 'Theme_Summer', 'Theme_Winter' projects. In reality there may be over 30 of these theme projects. Each theme project contains a selection of resource dictionaries to hold the styles etc along with the images, sounds etc that are required.
Each of these projects also has a Main.xaml merged resource dictionary that ties together all the resources in that theme project. My main application then just uses the Main.xaml resource dictionary from whatever theme project it needs to use.
The problem I have is I need these 30 or so themes in my solution so they remain under source control and manageable but they all get compiled into the XAP which is obviously not good as the app gets deployed somewhere and only requires 1 theme.
My question is really what do people think would be a suitable approach? Having a seperate solution for each theme so that it gets compiled into a seperate XAP and loaded dynamically seems like a lot of work. Is there a way to externally load these while they are part of the same solution?
Thanks for your time
Disclaimer: What I am recommending may not be the best for you. I only know a tiny bit about your project and know nothing about what you have told the customer (or boss) what you would deliver them.
If you are going to have x (where x is between 2 and 30-ish) themes. You will probably want to spend some time building a framework for supporting x themes. Since you won't want to change this framework every time you add a new theme, PRISM is perfect for you.
I would move everything out into x-ish silverlight class libraries. Obviously you could package similar themes together, like Seasons or Holidays, which would widdle down on the numbers of projects. Now don't forget that your Visual Studio Solution can have more than one project in it (Simply right click on the project and select Add->New Project).
Using PRISM is rather simple and there are a lot of resources to help you dynamically load xap files. It sounds like you may eventually want to rid yourself of problems associated with compiling in a bunch of similar logic.
Is there a way to externally load these while they are part of the same solution?
The answer is yes! You will have to compile your individual silverlight applications into XAP files and load them with PRISM.
It may seem like a lot of work, but when you've created the first few of them, it becomes second nature and really simple to add more XAP's to your list.
http://development-guides.silverbaylabs.org/Video/Silverlight-Prism
http://msdn.microsoft.com/en-us/magazine/dd943055.aspx
http://www.sparklingclient.com/prism-silverlight/
Is it possible to develop against Silverlight and WPF using the same source code? Maybe using some #define blocks where it is necessary.
Theoretically it should be doable. It's not a big problem for the code. However, you'll have to be very careful with XAML and use only the intersecting subset of WPF and SL (1), as there's no #if/#endif for XAML.
(1) Contrary to the common belief, SL is not a proper subset of WPF. It has some features that WPF does not have, though these are being worked on.
Incidentally, PRISM (the composite application block from patterns and practices) now supports Silverlight and there's a C9 video with a quick sample on using code in both WPF and Silverlight.
I think if you stick to MV-V-VM (or something along those lines) then a lot of your backend code will be reusable, but the XAML itself might need to be forked if you want a full on "rich" experience, unless you are willing to use the VSM beta for WPF.
I have no experience on that but I have used a component that targets both WPF and Silverlight environment with the same code (there are only few differences).
The component is Chart from Visifire and it's Open Source
Maybe you can take a look into it
You can use Visual Studio file linking to include classes from WPF projects in Silverlight - but only if they don't do any UI or XAML based stuff (as this is where you will usually find inconsistencies between the two)...
So keep it to business logic etc.
Flashcards.Show application is a great example of this WPF/SL/WP7 code sharing and cross platform possibilities.
http://windowsteamblog.com/windows_phone/b/wpdev/archive/2011/03/03/flashcards-show-planning-a-cross-platform-solution.aspx
Concept of cross platform is pretty simple because everything works on .NET and a similar XAML binding system. My advice here is to invest more time on architecture of the app in terms of MVVM and other abstraction to segregate the platform dependencies. So that a major percentage of the code can be re-used across while some of the XAML might need to rewrite depends on the visual complexity of the app in different platforms.