Is it possible to have a part of UI like a Fragment that has search functionality and be reusable? Meaning that I have the logic of the Fragment in one place and use it in other Activities without having to implement that logic in all of the Activities. I looked at Fragments and it seems that the logic is implemented in the Activity.
If not, is there a way to do this, or do i have to implement it in all Activities?
Yes. One of the great advantages of fragment is code reuse.
You can write all the search code on the fragment and load it from different activities. From the activity side you only have to set the fragment and handle logic specific to that view.
Related
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.
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
Is it my understanding that Helper methods are really the place where you can do the hard core logic that we would have done in lets say custom controls in ASP.NET? For instance I work for a .com which uses classic ASP.NET. The nature of our site is VERY complex, so we reuse and render different forms for thousands of products. Every product could have a different configuration form. We have a very complext RenderForm.cs custom server control that performs all the logic. Based on some configuration settings from a table in the DB, it says ok, for Product 1123 it reads the setup (that our users confugure form our internal admin system) and takes that and spits out the dynamic form (using literal controls and what not) to the p age.
So I'm thinking MVC now. Yea yea, it's all done in the View. Well partially. You're still going to have a need to have some custom logic in some .cs where it's not all embeded in your view. That would be foolish to think you're not going to have some class that will spit out some HTML..like some very hard core extensive helper methods.
So my question is, are helper methods or class where you now do your custom server control type of logic? it's basically kind of the same concept in that you need a place to put your "hard core" HTML rendering logic in some class other than a controller. Your controller is not responsible for rendering. So helper methods I guess are the so-called custom server controls in a way that I have in classic ASP.NET, figuratively speaking. I just need a yes or now on is the consensus that helper methods is the place to do all my hard core reusable logic that spits out html to the page and where I can embed custom controls into my view? Looks like it.
"Helpers are essentially static classes, designed to contain the UI logic that otherwise clutters up your UI. Think of these as UI utilities." link text
Yes, that is right on. If you do it right, you will start with the HTML helpers that MVC gives you, and you will gradually build up your own set of helpers that do even more and more for your specific project. You can get to the point where your view has only a few lines of code, which say something like, "Render entire view for Product 1123". The helpers will become your own "language" of renderers specific to your project, and you will be applying configuration, validation and everything else in a very DRY (Don-t Repeat Yourself) manner. It's phenomenal.
Update: Of course, only presentation stuff should go in your helpers. The goal is to stay DRY in your views. You still need to be careful to put into your ViewModels the things that belong in the ViewModels.
I would say "no"... or rather "only where you have to". More often than not, you can instead do the logic in the Controller (or a Service) and end up passing all the data required back to the View in ViewData. Somtimes this will mean multiple Views from one ControllerAction, less often it will mean logic in your View, and occasionally it means HtmlHelpers.
When you decide to use Helpers, it should be with the consideration that this means generated markup that won't be... well, in your markup. If you have (or later hire) a designer, that can be a problem. Or if you need to make a minor change to your layout, where do you go first? Your View or your Helpers?
[Edit] Also should ask yourself this: where is my code more easily unit tested? In a Service class which is just handing back View Data, or in a class that builds entire chunks of HTML and returns them as a String? If you're using TagBuilder, as you probably should be, then any change in the implementation of TagBuilder (even a change of whitespace handling) will break tests on a Helper without your code changing.
I'm not saying "don't use Helpers", I'm saying "don't abuse Helpers".
I am getting confused between domain/application logic and User Interface logic. To illustrate what I am trying to nail down, I will describe an imaginary program below for illustration purposes:
(1)
Imagine a small application with a set of 3 cascading drop-downs. As you select one dropdown it triggers a jQuery Ajax GET which ends up hitting a MVC controller, supplying the selected value of the previously selected drop-down. The controller returns the allowable choices for the next drop-down. The javacript (in the view) arranges these results into a drop-down. and so on. So each time you select a drop-down, the next one gets populated.
(2)
Now throwing in a wrench.. There are some exceptions. Lets say if the user selects "FOO" or "BAR" in the first dropdown, then the behavor changes, so that the second dropdown is disabled, and the thrid dropdown will show a texbox instead.
My questions is, in the context of MVC, what is the appropriate place for this "decision" logic? Such as the code that is responsible for making these decisions like I explained in (2). The most convenient place that I have been putting this was right in the javascript of the view. I simply wrote javascript to test if the first box is "FOO" or "BAR" then, disable the second dropwdown, and swap out the third dropdown for a textbox. But this does not feel quite right to me. Because It seems like it should be business logic therefore the code should belong in a domain layer some place. But that does not feel quite right either.
And so I feel like I am going in circles. Can some one shed some light on this little design?
Let's start at the Domain Model. A Domain Model is an API the models the Domain in technology-neutral ways. It knows nothing about View technologies such as JQuery, HTML or (for that matter) XAML or Windows Forms.
The Domain Model contains classes and interfaces that describe the Domain and lets you model the Domain Concepts in a rich and expressive way - no matter what type of application you are developing.
With that in mind, it's fairly easy to see that the display logic you describe doesn't belong in the Domain Model. It must, therefore, belong in a UI-specific layer.
You can put that in a separate UI Logic module or together with your UI application - in your case an ASP.NET MVC application. Whether you express the desired UI logic in JavaScript or server-side is less important.
Personally, I would define this logic server-side in Partial Views, but that's because I care a lot about testability, and I know how I would unit test such behavior (I've been told it's possible to unit test JQuery code as well, but I have no idea whether that's true or not).
If you ever end up writing another application based on the same Domain Model, it is very likely that the display logic turns out to be very different, because different technologies imply different paradigms.
Without splitting too many hairs or getting too fanatical on WHAT MUST BE DONE TO KEEP THE PATTERN PURE...
Obviously the Controller knows that this change must occur, as it will be handling both resulting cases (drop down selections or text entry). So putting logic relating to this in the Controller is not a sin.
It is also equally as obvious that the View must change how it displays depending on the contents of the first dropdown. While this mixing of behaviors isn't exactly the best UI experience I could imagine, if requirements must, then the logic for this must exist to some extent in the UI. But, jeez guys, this is a website we're talking about here. Do you really want to remove all logic from javascript and move it into a controller method? The View is deciding on how to display data, which is its job, and so cannot be a sin.
The real way to avoid getting burnt at the stake is to redesign to avoid the controversy in the first place. Or, just code it and bitch about your lousy design requirements over a beer.
In that situation where you have very specialized actions happening you need to put it in the logic in the js like you have been doing in your drop down example. You will also always want to put the validation on the server side as well to ensure your data is clean.
With the MVC 2 stuff coming out they have some really great validation server/client side validation going on. Check out Scott Gu's post more insight on this: MVC 2 Blog Post
Given your example I wouldn't mind this logic in the controller, it definitly doesn't belong in the domain model. I would personally feel better grabbing the ajax GET request in the controller and deciding what to output from there with JSON instead of doing all that logic in jQuery (I just feel more comfortable in C# then in javascript). With that being said, I like to keep my action methods skinny so what I would do is put the logic involved with figuring out what to populate the dropdowns in a method on the conroller and decorate it with [NonAction].
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.