What's the purpose of having behaviors in Xamarin.Forms? Isn't it possible to add new functionality to UI elements through event handlers? I am confused about when to use an event handler and when to use behaviors.
This is a very simple answer and is only intended to start your research. Undoubtedly a better answer will come along. I am still working through this and will keep an eye on it because I too would like an answer that is more thorough than mine.
With proper separation of your View and ViewModel, Events aren't really the way to go. Behaviors allow you to maintain a proper MVVM approach (for example, when calling a Command from an Entry's Completed event) by using an EventToCommandBehavior system.
Additionally, Behaviors allow you to create prepackaged, well, behaviors that can be applied to multiple controls' events without having to reuse code.
Related
I've developed an ASP.NET user control, instances of which may appear several times on a single page. Without getting into too much application detail, when the value of any one of the instances changes, all of the other instances need to be refreshed. Currently, in order to accomplish this, I'm requiring that the consuming page implement a couple of methods which iterate through each control on the form, find all the instances of my user control, and call a Refresh method in each one.
Functionally, it's working perfectly. However, I'd like to force the developer of the consuming page to implement these two methods exactly as per my requirements. I could have them implement an interface, but that doesn't provide the functionality in each method. Or I could have them extend an abstract class, but in either case (interface or abstract class) how can I force them to inherit? I need something that will trigger a compiler error if the necessary abstract class is not extended by the consuming page. Any ideas?
Thanks.
You can enforce implementation by using 'abstract methods' in C# or using the 'MustInherit' keyword in VB.NET.
In your particular case, you're expecting the developer to essentially implement 'your' code to force the refreshing and this is something I wouldn't want delegate. Without knowing too many details I would be tempted to utilise the 'Observer' design pattern or possibly the 'Mediator' using either a separate object as a controller or even applying the controlling / publishing code to the webpage. Here's a practical example of the 'Observer' in ASP.NET.
HTH
I've been learning some new features of ASP.NET beyond my current level of comfort, and I'm trying to figure out exactly how custom events can fit in, from a design standpoint. I know how they work, and the observer/subscriber pattern, but it seems that custom events aren't talked about much. It seems like an entire app could be built from registering events and responses all over the place, and yet, we see more controller-type classes that fire bits of code off in a predetermined pattern...it's OOP, and yet still sort of procedural.
So speaking from a design standpoint, when is it best to use events? Are there certain scenarios that they are very handy for, but not much else? Or is it possible to create an app that relies heavily on them, and a programmer can use them as much or as little as they want?
Mostly I'm just curious as to where they fall into "proper" design, as I can easily re-imagine an app or two of mine leaning on them much more as opposed to just firing off controller class logic when a button is clicked.
You don't see as many custom events in asp.net code mostly because the things that can trigger an "event" tend to be things the user did on the client via one of the built-in controls like a button or what-not. The server itself doesn't really "interact" with the code as it executes in an event-driven way though.
One you get a postback goind via one of the regular controls. The execution on the server tends to be very procedural in nature... that is just the pattern that makes the most sense in a stateless request/response environment like the web.
The asp.net page life-cycle and server controls all have lots of events they expose and may fire those OO like aspects are really just supporting what is by its very nature a highly procedural and linear execution path.
Custom Server controls expose custom events just like the built-in controls do so that page developers have a mechanism by which they can interact with the control without tight coupling... so that is where you'll find most custom events. But the cost of making a custom server control is really only worth it if you really do have a lot of different pages where the control might be used.
I often use events in user controls too. while you can treat a user control very similarly to a server control, generally user controls tend to be weak in terms of OO design principals. With user controls, you are usually just trying to gain a little bit of a separation of concern and some encapsulation, but you'll tend to still have a fairly tight coupling between the hosting page and the user control. but still, sometimes a user control may need to signal to the hosting page that some condition has been met, and in those cases a custom event is a good way to handle that signaling with less coupling than directly calling a method on the hosting page.
Mostly I use custom events when building custom controls.
In ASP.Net I don't use custom events much at all, since even with the custom controls I try to rely more on the existing page life-cycle.
In Windows forms almost everything I do is abstracted into a control somewhere, and so I use them quite a bit.
I've done a lot of custom events in ActionScript 3.0. I mention this because its delegate system is fairly similar to .NET.
I was creating an SWF player that could queue up multiple clips at a time. My custom Timeline control would fire ClipEnd events, which my main application would listen for and advance the Playlist. My Playlist would fire NewClip events if either the user advanced to a new clip, or the app automatically did. My app would listen for these and tell the Timeline to start playing the next clip. So my Timeline and Playlist were symbiotically linked via custom events.
I am creating a completely custom (only inherits from WebControl) combobox/dropdownlist search control with autoComplete capabilities.
JQuery handles assigning the onhover and onclick events for list items (divs with strings in them) and handles the web service call for getting the list of items for the matching text.
The server handles the custom attributes and control rendering.
The issue is that I need to implement a property that is similar to SelectedValue so that when a user selects an item from the search results, the value can be used on the server for other processing. I have done days of research but have not found a clear, concise way of handling the post back data.
I did read a blog that mentioned implementing the IPostBackDataHandler interface, but the implementation of RaisePostDataChangeEvent() calls for calling a server method (like SelectedIndexChange) that I am not implementing at the moment.
public void RaisePostDataChangedEvent()
{
this.SelectedIndexChanged(EventArgs.Empty);
}
Now for the question: Does anyone have advice for handling this? Or am I better off simply inheriting from the dropdownlist control and overriding the existing functionality?
I feel like I'm missing a very small piece that will fit this all together.
Have you considered pulling down the source code from Microsoft's source server and taking a look at how they implemented DropDownList? This would allow you so see how they solved the binding and events part of the problem and give you a good idea what it does otherwise. This way you can decide if you want to inherit from it, or if you can just borrow some ideas for how they implemented IPostBackDataHandler.
Since I have no idea what specifically you are doing, I couldn't advise you if you should inherit from dropdown as it is, but based on my impressions of what you are doing I'd say you probably don't.
Also you might look at source from the AjaxControlToolkit as it has a similar component. Again, you can get ideas for how these specific things are handled and adapt them to your own needs.
I have an ASP.NET page that is interacting with a business class. I want to continuously update controls on my page based on user entered values, e.g. update totals. The calculations are embedded in business logic but they're simple enough to reproduce elsewhere. I've thought of three ways to accomplish this:
Dynamically update the page using JavaScript. I don't want to do this because I don't want to risk floating point math problems where the values on the page don't match the values calculated by the business class (those properties are decimals).
Clear calculated fields on changes and force the user to click a re-calculate button. This is a poor user experience and wiring up JavaScript to ASP.NET controls is tedious.
Use an AJAX UpdatePanel, set data entry controls to autopostback, and handle the "changed" event for the control, e.g. TextChanged for TextBox.
The third method seems cleanest to me, provides a nice user experience, and allows me to interact directly with my business class that I've stored in session state.
My question is: Is this a good idea and/or a common practice? Are there better ways to accomplish this?
I haven't done ASP.NET work for a few years and I have a prejudice against autopostback[1]. I've looked at the size of the request and it's currently negligible at 1.5kB. The site will be low use but we may have a small number of users with dial-up connections.
And ASP.NET in general but times are tough.
Personally, I think UpdatePanel is too heavy. You could use jQuery along with an ASP.NET Web service function that outputs JSON.
You're correct in thinking the third option is your best. This is the kind of thing that AJAX is made for. Go for it.
OK, I am not sure if the title it completely accurate, open to suggestions!
I am in the process of creating an ASP.NET custom control, this is something that is still relatively new to me, so please bear with me.
I am thinking about the event model. Since we are not using Web Controls there are no events being fired from buttons, rather I am manually calling __doPostBack with the appropriate arguments. However this can obviously mean that there are a lot of postbacks occuring when say, selecting options (which render differently when selected).
In time, I will need to make this more Ajax-y and responsive, so I will need to change the event binding to call local Javascript.
So, I was thinking I should be able to toggle the "mode" of the control, it can either use postback and handlle itself, or you can specify the Javascript function names to call instead of the doPostBack.
What are your thoughts on this?
Am I approaching the raising of the events from the control in the wrong way? (totally open to suggestions here!)
How would you approach a similar problem?
Edit - To Clarify
I am creating a custom rendered control (i.e. inherits from WebControl).
We are not using existnig Web Controls since we want complete control over the rendered output.
AFAIK the only way to get a server side event to occur from a custom rendered control is to call doPostBack from the rendered elements (please correct if wrong!).
ASP.NET MVC is not an option.
Very odd. You're using ASP.NET server controls and custom controls, but you're not using web controls? And you're calling __doPostBack manually?
Do you like to do things the hard way?
If I was still using the server control model rather than MVC, I would slap ASP.NET Ajax controls on that sucker and call it a day. What you're doing is like putting a blower on a model T. It may be fun and interesting, but after you're done with all the hard work, what do you really have?
I have been doing some more digging on this, and came across how to inject Javascript in to the client when required. This will obviously play a huge part in making the controls more responsive and less round-trips to the server.
For example: RegisterClientScriptBlock.
Look forward to playing with this more, feel free to get invovled people!