This video defines what is a behavior is and how to implement it.
- [Narrator] What are behaviors? Behaviors are ways for you to interact with your controls in your app without cluttering your code. This is normative code that you would put in your code behind files. Behaviors also allow you to add this functionality without subclassing the visual element you're using. Now code behind files are traditional bulky, making them really hard to work with. Behaviors helps you clean up that code and make it easier to read and understand. It can be either be added in XAML files, code behind files, or in plain C# code. Behaviors are meant to deal with general patterns of functionality that you would give a visual element.
For example, you may want to format dates, or make sure that only positive numbers are entered on an entry field. There are four different types of behaviors, but for this series we'll be focusing on forms and attached behaviors. Why use behaviors and what can they do for you in your app? The first thing is that your code is completely reusable. Without behaviors, you'd be sticking a lot of this code in your code behind files, and it would have to be duplicated for every new file that you make. Adding behaviors can help you build reusable functionality across multiple projects, making your XAML and code behind files much easier to follow.
This brings me to another point. The size of your XAML and code behind files. Remember those days where you had to put any and everything in your view files, making it difficult to understand? Behaviors help put those days away by aiming to make your XAML and code behind files as bite-sized as possible, keeping only the view logic and separating functionality. Finally, many of you are probably working with a team. It is impossible to handle version control when everyone is working on the same file.
Behaviors remove this stress by isolating the code you're working on in different files, easing the version control process. When do you want to use a behavior? When I use behaviors, I try to think about a specific functionality that I want to achieve for a certain control. Let's take an entry view and think about the kind of functionality you may want it to perform. You may want it to only have uppercase letters, or you may want it to only show numbers, or you may want to format date entries a certain way. These are all candidates for behavior.
The behavior should be as generalized as possible. The more generalized, the more likely it will be reusable for other parts of your app. If there's any logic related to your controls that are not data related, with the exception of formatting that functionality should live in a behavior. Things like date formatting, phone number formatting, or validating email addresses. What you should not use as a behavior is manipulating custom data models in your app, as well as modifying other visual controls that the behavior isn't attached to.
- Creating and implementing behaviors
- Stacking behaviors
- Adding behaviors to styles
- Creating commands
- Setting up and implementing triggers
- Tying it all together in a Xamarin app