I'm writing my first WinRT app for Windows 8 in C#/XAML managed code and I obviously have to handle the UI in the different sizes and orientations that could occur (FullScreenLandscape, FullScreenPortrait, Filled and Snapped).
Most people seem to suggest handling the UI changes through the Visual State Manager in XAML, however me being more comfortable with writing the code-behind rather than XAML, I thought I would simply handle the Current_SizeChanged event with a switch statement for each of the states.
I tried both ways and both seem to work for me (though the VSM was decidedly more work - at least for me).
Can someone tell me why I should use the VSM over code, or what benefits I would receive?
It's a good question, and certainly one that entered my head when starting WPF & WinRT development. Having coded C# projects for years, it seemed a strange concept to start building UI logic in the Xaml (which is usually more lines than C#, but also more declarative).
In actual fact (if you don't mind me saying) I think we can abstract your question out to 'Is there any benefit to writing UI code in Xaml over C#/VB.net?'.
Let me give you an example, in work I'm on a project team with several developers, and several graphic designers. The designers are pretty awesome at laying out that Xaml, and creating a consistent feel for the application (something I can't say I would be that good at) - but will have little idea when it comes to writing web-services and Data Access layers - which is our job as developers. And that's how it should be right?
Well whenever you start writing a lot of View/UI related logic in C#.net, this can lead to all sorts of problems. The designers all of a sudden can't focus on the Xaml at hand, and must get up to speed with OO programming. In our project this isn't that much of a concern, as the designers are actually pretty competent developers (must have been all that UI code I forced them to understand last year :)) But what I think it boils down to is a 'Separation of Concerns' at a job description level. If we take the paradigms associated to WPF I think things like Databinding 'guides' developers down a road where they create separated, testable UI and Business layers - the same way that the nature of Xaml allows for a very declarative approach to writing UI where the View Logic is created and maintained in a very readable manner without getting too much into the nature of OO programming.
So, coming back to your question - No, I don't think there any immediate benefits, and if you come from a mainly .Net background to write a lot of these things is Xaml can be little tricky. However, if you are in a team of people - or if you find best-practices a very important factor in development, then writing View related code such as Visual State manager configuration in Xaml is the way to go.
One last point - you'll notice I used the terminology 'View related logic' a lot. This is because it's widly viewed that writing UI related code in code-behind is acceptable (if not best-practice) but sometimes due to the nature of the WPF or WinRT framework you are dragged down this route for some functionality. However, if you are writing business logic in the UI files codebehind this is viewed a particular no-no. This breaks the 'seperation of concerns' and can make testing very difficult. If you are following the MVVM pattern (as many WPF or WinRT projects do) then this is what the ViewModel is responsible for.
Related
I needed to get the root item of a TreeView. The obvious way to get it is to use the getRoot() on the TreeView. Which I use.
I like to experiment, and was wondering if I can get same root, buy climbing up the tree from a leaf item (a TreeItem), using recursively getParent() until the result is NULL.
It is working as well, and, in my custom TreeItem, I added a public method 'getRoot()' to play around with it. Thus finding out this method does already exist in parent TreeItem, but is not exposed.
My question : Why would it not be exposed ? Is is a bad practice regarding OOP / MVC architecture ?
The reason for the design is summed up by kleopatra's comment:
Why would it not be exposed I would pose it the other way round: why should it? It's convenience api at best, easy to implement by clients, not really needed - adding such to a framework/toolkit tends to exploding api/implementation to maintain.
JavaFX is filled with decisions like this on purpose. A lot of the reasoning is based on experience (good and bad) from AWT/Spring. Just some examples:
For specifying execution on the UI thread, there is a runLater API, but no invokeAndWait API like Swing, even though it would be easy for the framework to provide such an API and it has been requested.
Providing an invokeAndWait API means that naive (and experienced :-) developers could use it incorrectly to accidentally deadlock threads.
Lots of classes are final and not extensible.
Sometimes developers want to extend classes, but can't because they are final. This means that they can't over-ride a lot of the built-in tested functionality of the framework and accidentally break it that way. Instead they can usually use aggregation over inheritance to do what they need. The framework forces them to do so in order to protect itself and them.
Color objects are immutable.
Immutable objects in general make stuff easier to maintain.
Native look and feels aren't part of the framework.
You can still create them if you want, and there are 3rd party libraries that do that, but it doesn't need to be in the core framework.
The application programming interface is single threaded not multi-threaded.
Because the developers of the framework realized that multi-threaded UI frameworks are a failed dream.
The philosophy was to code to make the 80% use case easier and the the 20% use case (usually) possible, using additional user or 3rd party code, while making it difficult for the user code to accidentally (or intentionally) break the framework. You just stumbled upon one instance of an application of this philosophy.
There are a whole host of catch-phrases that you could use to describe the reason for this design approach. None of them are OOP or MVC specific. The underlying principles have been around far longer than software engineering, they are just approaches towards work and engineering in general. Here are some links if interested:
You ain't going to need it YAGNI
Minimal viable product MVP
Worse-is-better
Muntzing
Feature creep prevention
Keep it simple stupid KISS
Occam's razor
My team is currently working on windows forms project using VB.NET. We are curently focused on functionality and the UI seems to very basic (if you drag and drop from the toolbox to your windows forms)
Is there any recommendations or standards when it comes to UI for windows forms development? I want to ensure that the client gets a great UI.
I appreciate your support.
Yes, it's a simple standard: make sure that you follow the Windows User Experience Interaction Guidelines.
There's absolutely nothing wrong with "simple". In fact, in many cases, simple is good!
Your focus should be on making things easy, intuitive, and conform to user's expectations. Modeling your app after other applications, particularly those included with Windows, is a good way to make sure that you're on the right path.
Breaking new ground is dangerous territory; leave that to the big shops like Microsoft. Even new UI concepts that have panels of user interface/experience experts behind them like the Ribbon are slow to be accepted and even slower to be adopted. This isn't where a small software shop wants to be. There's no advantage in being out on the leading edge here.
The recommendations you'll inevitably get to use third-party controls are well-meaning, but ultimately misplaced. There's nothing wrong with the built-in controls and a lot of reasons to prefer them.
Once you've got a functional UI that conforms to the standard guidelines for your platform, the next step is real-world testing with actual human users who have never worked on any aspect of your application.
If they like it and they find it easy to use, then you know you're on the right path. I've never heard a user complain that something looks "too simple". Google Chrome is a huge hit precisely because it's simple. Remember that you're not designing a web page here. Desktop applications are very different.
In fact, it blows my mind how often questions like this one get asked here. Why do desktop app programmers spend so much time wishing that their app looked "cooler"? These are often the same developers who complained loudly because Visual Studio 2010 switched to WPF, broke a lot of their standard expectations, and got a lot slower, with little noticeable benefit. Sure, it looked cooler (unless you didn't like the color blue), but there was little in the way of functionality that the UI change alone was responsible for. Look at the apps you use every day. Do you really pine for a more whiz-bang UI? Or do you appreciate them and integrate them into your workflow because of how they workâbecause they conform to your hard-learned expectations of how a standard Windows application should work?
Make your app work like that.
Believe it or not, UI is very important to the end user. Its good you focus on functionality first, but when its done, make sure the user will have a good experience with your system. Make it as easier as you can, keep in mind that every user does not know everything about softwares, dont let him/her make a mistake, the look and feel must be very nice from the user's point of view, its not important to the system but it is to the user.
I use to use third party controls that manage the look and feel (DevExpress) you can try but if you are going to try some third party controls, you will have to do it at beginning of development, because the functionality may change.
I hope it can help you some.
Regards.
We are migrating our applications to VB.Net 2008 from Classic VB and I need to create a base namespace and business layer. My method of approach is going to be to visit our top BA and identify the common areas of our (Fixed Income) company and try to form a decent inheritence model with as much of the code in generics as possible.
What's everyone's experience of doing this and also as a second part of the question, we are looking at incorporating Web Focus into the OLAP side, how would this affect the design of the corporate namespace and it's derivatives?
I think the best way to begin to create a corporate .NET framework is to begin by harvesting existing code out of current corporate projects. Building a framework from scratch by talking to a BA without writing code for a specific, concrete project might lead you to over design the framework in some areas and totally miss some necessary features in others (as well, it might place artificial constraints on your framework clients for no good reason).
See Fowler's entry on Harvested Framework and this blog post for a more complete explanation.
I'm not familiar with Web Focus but I'm guessing it would affect it in some way, however, if you go with a Harvested Framework, your usage of it in the first few applications you build will shape how you use Web Focus within the framework.
Jereme has it right on the framework. I'll briefly mention something obvious about namespaces.
Always remember what a namespace is for - it's to provide a "space" in which names will live. In particular, it's meant to provide a space small enough that the people creating names within that space will be less likely to produce duplicate or confusing names.
This can only work if the namespaces are organized along patterns of organization, or of domain knowledge. A simple example often used is a pattern of Company.BusinessUnit.Application. The theory is that within the set of developers working on a given application, there is less chance for name duplication. This will not be true for a large application, where you would want to break it further based on layer or area. Similarly, of the business unit is too large, you'll want to break that down.
But in all cases, you're really trying to partition sets of brains, as it's the brains that create the names.
If your application is under VB6 (not VB3) then I strongly recommend that do the redesign to a class hierarchy in VB6 first. The reason for this is that in any conversion you try to preserve the behavior of the old application. Is stretches out the project time to do this and do a redesign at the same time.
By making the design changes in the applications original language first then you are assured that any bugs that result are due to the design not the conversion.
I done three major conversions of our software in the past 20 years; (DOS to VB3) (VB3 to object oriented design in VB6) and (VB6 to VB.NET).
Finally it is straight forward to make a design in VB6 that is ports over to VB.NET readily. The trick is to hide the specific VB6 APIs and constructs behind a interface (graphics, printing, etc)>
When do the conversion I recommend working from the top down. Change over your forms first to .NET which calls the VB6 COM DLLs. Then convert each layer over until you reach the bottom DLLs.
Again, if you try to change the design AND convert to another language for any complex application you will double the conversion time.
To me it seems the main point of Seaside is that it is more like normal "desktop" programming.
The control flow looks much more like "traditional" programming instead of
"web" programming. Is that a correct impression?
I know it's about Web programming but it's does not looks like it from the programmers side. It looks much more than driving "desktop" applications. Does this clarify the question a bit?
The point of Seaside is not really to be like desktop programming, though it does try to take much of the pain out of web development. Seaside is known for two things which you might consider "desktop-application-like":
using continuations to allow you to write multi-step processes that prompt the user for information
using blocks (closures) to provide event-handler-like "callbacks" into your code whenever links are clicked, forms submitted, etc.
These things vastly simplify certain web development tasks, though the first ends up being used fairly infrequently in practice.
Seaside provides many other things, though:
The ability to write web applications in Smalltalk (very productive and pleasant)
Composable, reusable "components"
Components can delegate to other components, which replaces just that part of the page
Easy management of session state and certain state can be marked to be rolled back whenever the user uses the Back button so it always has the correct value when callbacks are executed
A very nice Canvas API for programatically generating HTML, JQuery, Scriptaculous
The ability to debug and fix errors live on a running site
Most of these are not unique to Seaside but they are somewhat unusual. So how is it different from other web programming? You get to write in Smalltalk. You don't have to mentally context-shift back and forth between code and a templating language. You don't have to worry about form field names, URLs, etc. unless/until you want to. You probably won't hate web programming as much if you use Seaside.
People may discover Seaside because of its "desktop programming features" but they usually hang around for all the other stuff.
Your impression is correct. Seaside is designed for what I call a tree-like control flow, as desktop GUI apps have. Comparing to the Aida/Web, another Smalltalk web framework, which is meant for graph-like control flow, and that is actually what you have on the web.
But tree-like control flow is very useful in such cases like confirmation dialogs, or for popups like those very frequent on Facebook these days. That's why we are introducing the tree-like control flow in Aida/Web too, that is, we are combining both control flows together.
Seaside is an app framework for developing web apps written in smalltalk. What do you mean by it looks like "traditional" programming
Edit-
Seaside architecture is different from in which its web pages are built as trees of individual, stateful components, each encapsulating a small portion of a page
As I get myself ready to move my Winform applications to XAML, I was wondering what are the must-have third party XAML controls that will save me developing time and will make my app look shiny with little work?
Thanks,
Nestor
XAML is markup language rather than a platform. In fact, you don't even have to use XAML to write WPF applications if you really don't want to. Since you're talking about converting from WinForms I believe that the question you're asking is more one of which third-party WPF control kits exist, so I'll answer on that assumption.
There are a few companies that have pretty extensive suites. As Shoban mentioned above, Telerik is one. You also have Infragistics, Actipro, Component One, to name just a few.
There are also quite a few specialty libraries to aid in Business Intelligence, Graphics Processing and more.
In other words, it's not possibility to make a good recommendation as to specific control libraries, but I can point you in a couple of directions.
WindowsClient.Net attempts to maintain a control gallery (not just for WPF, either). That's a good place to start. There are also software sales companies such as ComponentSource which can also set you in a direction or two.
I tried to link the other companies, but SO apparently thinks I'm too much of a noob to be trusted with high-security stuff such as multiple hyperlinks. :)
Check out Telerik. They have some nice controls.