I recently used Expression Blend and I found that it has something called Visual State Manager, what is the difference between it and the regular event driven model, and which is better?
Events are for instances of "things" happening e.g.:
Was I clicked?
Did my timer fire?
Is my data ready?
The Visual State Manager is used to manage multiple simultaneous states of a control.
Am I pressed?
Is the mouse over me?
Am I checked?
Events are just callbacks to listening objects, while states are visual states, so basically there are used for completely different purposes. Events can trigger state changes, but that is the only overlap.
An object fires an event to indicate that something has occurred. The event carries an arbitrary payload (the event args) plus (by convention) the object which sent the event. Visual states define the different states of a control or user control. A visual state defines how a control looks, how it transitions to that look, and how it transitions away from that look. ("Transition" can involve anything from toggling the visibility all the way though a complicated animation.) Visual states are part of a control, but you can't directly subscribe to them as you can with events.
One model is not better than the other: they're simply different. Think of using events in your view model and model/service layers and visual states in your view layer.
Visual State manager is used for managing state (surprisingly). So for example your button can be in multiple sates:
Mouse over
Mouse down
Disabled
Enabled
You code doesn't really need to know about it, so all visual states of your application should be kept within XAML.
Also Visual state managers helps to reduce your code behind which is more error prone.
And as for events, in fact I tend to use commands more often now, I find them to be more useful than events on its own.
Related
can you tell me how to effectively document analytical events (clicks on buttons, etc. for websites) for further easy updating and easy work of different teams on one product with the ability to change events and so on (because the design of the website changes often).
I currently use excel with event, description, additional parameters, and a screenshot of the place with the button.
I wonder how other people do it, maybe there are already good tools for such tasks. Share your ideas if you don't mind, I would be grateful.
I've found that whilst there are a lot of tutorials on Xamarin Android, there does not seem to be a great deal on how to dispose of resources. More particularly, when they are disposed of.
For example, in the OnCreate handler of an activity, I am making several Rx subscriptions, each of which returns an IDisposable. I have tried to dispose of those in various other handlers (e.g. OnDestroy), but those handlers never get invoked. But the subscriptions seem to pile up because OnCreate runs every time the activity is navigated to.
In addition to those subscriptions, there's all the UI controls (TextViews, Buttons etc.) which I am assigning to class-level variables (fields). And those also implement IDisposable.
For all I know, I've got memory leaks all over the place.
Is there a guidance on this anywhere?
#SushiHangover is correct (thanks Sushi). OnPause and OnResume were the events I was after. I also had a bit of a challenge in that when I clicked my custom "Back to Start" button, I needed to go right back to the start screen (skipping the intermediate screen along the way).
The way to do that is use the ClearTop ActivityFlag (Android.Content.ActivityFlags.ClearTop) when starting the Home screen activity. Raw Android code version of this can be seen here https://stackoverflow.com/a/5794572/540156
When you do that, you can clean things up on the activities which get popped off the back-stack as they get popped (in the OnDestroy handler, from recollection).
I binded property IsBusy="{Binding IsBusy} and label from my page to viewmodel property. I see value changed in label, by i can't see any busy indicator on page on android, is it right?
I think there is some confusion over the IsBusy property. On iOS it shows the indicator in the statusbar which is questionable because the indicator there, according to iOS guidelines is only to be shown for network activity.
On Android it doesn't seem to do anything (visually) at all. Also see this bug on Bugzilla where this discussion is ongoing on what you, as a developer, can expect it to do.
When we read the documentation page for the IsBusy property it says:
Marks the Page as busy. This will cause the platform specific global
activity indicator to show a busy state.
So you should be able to see an activity indicator, also on Android. But in the bug mentioned earlier it is stated that it only appears if certain conditions are met or not at all when using AppCompat.
For now, if you have a requirement for this, I think it would be best to either skip over it for now until this is sorted out or implement your own visual aids.
The activity indicator on Android was removed as part of the transition to material design, as it was no longer inline with the design recommendations.
which of the following styles do you prefer?
An application which to perform tasks opens new forms
An application which keeps the various "forms" in different tabs
An application which is based on a PageControl and shows you the right tab depending on what you want to do.
Something else
Also do you have any good links for gui design?
From a programmers point of view, the PageControl solution quickly gets out of hand. Possibly too much code and certainly to many components on one form. (Originally this question was tagged Delphi, so I go from there.)
From a users point of view, the "opens new window" paradigm often is confusing. We people tend to think that we are able to multitask and handle many open windows and tasks, but we are not (we task switch at a loss of time like computers and add loss of accuracy).
Obviously this really depends on the type of application. But I would tend to a paradigm as Chrome and Firefox show in their latest incarnations:
keep the various forms in different tabs
let the user detach a tab into its own form (dock and undock via drag%drop)
add a good way of navigation
I implement something like an SDI as main screen of an application too. Look at something like "outlook style". Navigation, list of objects, object details in different panes, some additional panes like a cockpit. And then open a new window/form for certain tasks (some modal, some non modal), but short lived. After the email is written, it is sent and closes the window. But I have, if I am capable of doing so, the possibility to work on multiple emails at the time.
Look at the problem. If it has dashboard character, take "outlook style" or so. If the users are a wide spread, heterogeneous, non computer savvy crowd, use SDI or forms on tabs. If you write for programmers, you might go for multiple forms, just because we tend to think that we can handle it. And it works for multiple screens (hopefully).
MDI is the worst choice possible, in my opinion. There's nothing I hate more than having to resize a bunch of windows, or tile them or whatever.
Tabs are bad, too, especially if you have more than one row of them (or if you have one row but still have more tabs than will fit, and have to use some funky scrollbar or "more" button with them).
I would rather see the programmer think about the problem and just show me what I need to see based on what I'm doing as a user. Implementing the different user interfaces in your programs as user controls (as opposed to discrete forms) and then showing them or hiding them based on the current context is the way to go.
The Tabbed form is a good idea if you use a frame for each tab content. This keeps you out of trouble from getting too much code in one single form unit. Try to do the same as Google Chrome. I personally create a menu with the options that are actually frames that loads only when the user asks for it, so there will never be many tabs visible unless the user needs them all opened.
I have a custom control: it's managed code, which subclasses System.Windows.Forms.Control.
I want to add things like edit boxes, selection lists, combo boxes, radio buttons and so on to places on this control. An easy way to do this is to simply add instances of these classes to the Controls collection, so that they become child controls.
Adding them as child controls might create some subtle problems, for example:
IE 6 select controls(Combo Box) over menu
I have scrollbars on my control which appear to scroll the contents of the control (the contents are bigger than the control itself); when a child control is near the edge of the screen then I'd like to half-display (i.e. clip) that child (i.e. to have half of it located off the edge of the physical screen), but a true child control cannot be located outside the border of its parent.
Are there other potential problems?
When I use IE7 to display http://www.tizag.com/htmlT/htmlselect.php (for example), which contains combo boxes etc., and when I then use Spy++ to spy on IE7 when I'm doing that, I see only a single Window/control instance with no children (whose class name is "Internet Explorer_Server").
I'm guessing this means that in IE7, the functionality to render a combo box is built in to the IE7 control itself, and that IE7 does not use standard controls as child controls.
Questions:
Is it better to reuse standard controls as children of a custom control, or, to reimplement the functionality of standard controls within a custom control itself?
Do you have any caveats (warnings) to share, related to either scenario?
If I wanted to reimplement the functionality of standard controls within a custom control, do you know of any existing code (which implements this functionality) that I could re-use?
If such code already exists, I don't know how to search for it (my searches find, for example, owner-draw combo boxes, and extensions to standard combo boxes): perhaps few people reimplement the standard controls from scratch?
Edit
I found a semi-related question: How to render a control to look like ComboBox with Visual Styles enabled?
Yes, Internet Explorer draws the controls using the Windows theming APIs. You can do this too using the types defined in the System.Windows.Forms.VisualStyles namespace.
The IE team did this to avoid performance problems of having so many controls, each receiving window messages, on screen at once. For example, looking at this StackOverflow.com page, I see 30-40 link label controls, 10 buttons or so, 20+ labels, etc.
It should be noted the Zune software, which is .NET managed code, also uses custom controls; if you try to use Spy++ on any of the controls, you'll see they aren't real Win32 controls. You may use Reflector on the Zune software to see exactly what they're doing. If I recall right, they're using a custom managed UI framework that's included in the Zune software.
As far as rewriting these controls from scratch, I think there's a ton of work to be done. It sounds easier than it really would be.