I am new at Xamarin but have some experience on WPF and MVVM.
When building a Xamarin project I create the Views and Bind my ViewModels(Inheriting from INotifyPropertyChanged) to the Views.
But I have noticed that several (more than I wish) samples I have seen on the net create and attach the views elements (ListView etcetera) within the code behind.
My question is. Building the Views from code behind will accelerate the rendering?. Have somebody researched on the speed from one method to the other one?
I think it's a religious question. Some prefer this, others that.
XAML is never required in a Xamarin.Forms program, but it is often more succinct and more visually coherent than equivalent code, and potentially toolable. XAML is well suited for use with the popular MVVM (Model-View-ViewModel) application architecture: XAML defines the View that is linked to ViewModel code through XAML-based data bindings.
XAML has several advantages over equivalent code:
XAML is often more succinct and readable than equivalent code.
The parent-child hierarchy inherent in XML allows XAML to mimic with
greater visual clarity the parent-child hierarchy of user-interface
objects.
XAML can be easily hand-written by programmers, but also lends itself
to be toolable and generated by visual design tools.
There are also disadvantages, mostly related to limitations that are intrinsic to markup languages:
XAML cannot contain code. All event handlers must be defined in a
code file.
XAML cannot contain loops for repetitive processing. (However,
several Xamarin.Forms visual objects—most notably ListView —can
generate multiple children based on the objects in its ItemsSource
collection.)
XAML cannot contain conditional processing (However, a data-binding
can reference a code-based binding converter that effectively allows
some conditional processing.)
XAML generally cannot instantiate classes that do not define a
parameterless constructor. (However, there is sometimes a way
around this restriction.)
XAML generally cannot call methods. (Again, this restriction can
sometimes be overcome.)
and now XAML can be optionally compiled directly into intermediate language (IL) with the XAML compiler (XAMLC).
XAML compilation offers a number of a benefits:
It performs compile-time checking of XAML, notifying the user of any
errors.
It removes some of the load and instantiation time for XAML elements.
It helps to reduce the file size of the final assembly by no longer
including .xaml files.
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 am quite amused by the MVP Pattern http://webformsmvp.com/
How ever I have certain doubts on the implementation part.
Is it necessary that to use this pattern, I have to implement user controls?
I always thought that user controls are created if we need reuse of controls across pages.
Say if I want to implement and test MVP pattern,I should break my simple page with controls to a lot of user controls so that I can apply the MVP pattern?
What if I have quite a lot of standalone components in my webpage?
Is there any gap in my understanding of MVP?
Help.
It is not necessary to implement user controls to use this pattern, in short. Very briefly, you need a view (could be aspx or wpf or winform or console, etc.), a presenter that'll read from/listen to events from the view, make a call to the model and finally populate view with the right data, that's what MVP pattern is.
edit: this example is simple enough.
You don't have to use user control to use MVP pattern. MVP is GUI pattern that helps you to separate your concern.
For example, You write ASP.NET web page to calculate two numbers, with out MVP or MVC or any other GUI pattern, you would write all this logic in your code behind file which is very hard to test. If you want to test it, then you are bringing lot of extra baggages like ASP.NET framework.
In other hand, you write this app using MVP, you would do this.
View => Dumbest in all three. Doesnt have any or minimun logic. So you dont have to unit test it. It simply "tells" the presenter something happened and does what presenter asks.
Presenter => Controls the flow
Model => Business Logic/persistent logic.
I'm the author of the Web Forms MVP project you mention. This answer is specific to that library (which is just one implementation of the MVP pattern).
No, you do not need to use user controls. If you want, you can make your page inherit from MvpPage and it will then work with a presenter itself.
We recommend that you do use user controls though, even if you aren't using the control multiple times in your site. This lets you keep the view, view model and presenter logic nice and bundled as a logical unit for a particular feature. Pages are then used purely for laying out controls.
I'm working on a heavily data driven ASP.NET web forms application. We're using the Entity Framework 4.1 and I'm normally used to going around databinding all of my controls in the code behind. I've been coming across a lot of examples using the EntityDataSource ASP.NET control and am wondering if there is any advantage to using this control as opposed to binding the data on the code behind?
Thanks, J
I always considered "specialized" data sources risky and against properly layered applications. EntityDataSource, SqlDataSource, LinqDataSource, name it, you provide low-level access details in your declarative code. It feels great for a demo website but could potentially raise severe issues in a large one.
Have you instead considered using the ObjectDataSource? It could provide the best of the two - you provide a clean, declarative binding so there's no binding code required yet the DataProvider (or Repository) class which ultimately provides the data has to be written in C#. From such class you can use any data access technology, EF, Linq, SQL, anything.
See the discussion of EntityDataSource vs. ObjectDataSource in
http://www.asp.net/entity-framework/tutorials/using-the-entity-framework-and-the-objectdatasource-control,-part-1-getting-started
I'm quite new to the MVC design-pattern, and I'm translating all of my old code.
I want to move to this pattern because I can change my views according to my needs, but I'm finding difficult to do it at runtime.
I found an excellent example of MVC, and all that I do is the following:
<mx:ViewStack xmlns:mx="http://www.adobe.com/2006/mxml" resizeToContent="true" xmlns:views="MVC.views.*">
<views:HomeView id="Home"/>
<views:SecondPage id="SecondPage "/>
</mx:ViewStack>
what if I wanted to change (whenever the Controller says so) one of the views, for example the SecondPage view?
(Hope I made my point clear)
In Flex it is generally considered good practice to avoid holding direct references to your view components in your controller layer. The most common way to update views is by data binding. MATE is, in my opinion, the best Flex framework for this because it makes it very easy to inject data into views in a loosely coupled way.
However, if you actually bind to a variable holding a selectedIndex for your view stack, you are putting presentational knowledge into your model, which is also undesirable. An alternative solution is to set-up event handlers in your views that respond to events occurring elsewhere in your application and update themselves. MATE has ListenerInjectors which you can use in an event map to wire the view to the event.
Use some MVC framework like Cairngorm or Mate to begin with
Besides that you can have a model which maintains state of the application and bind selected index of ViewStack to it.
In traditional ASP.NET Web Form applications, UserControls are a great way to encapsulate functionality so that it can be reused. However, UserControls don't fit well into the MVC model. They often make heavy use of ViewState and they blur the seperation of concerns that MVC promotes.
My question is, how do you best bundle a piece of functionality so it can be shared across MVC applications?
As an example, consider a from/to date-selector UserControl that:
allows a user to select two dates, either using a javascript overlay or by typing in day, month and year into seperate fields
can be configured to default to either today and tomorrow's dates or to dates of the developer's choosing
validates the dates that comes back from the user to ensure the from date is before the to date
exposes From and To properties that can be accessed by code-behind
How would I best build something like this in .NET MVC so that I can easily reuse it?
Note that to fully emulate User Control's functionality the MVC component would have to manage the submitted form data and validation - not just the presentation.
In general I would agree that user controls are nice in terms of encapsulating UI stuff, but I don't think too much has really changed in MVC. If I remember right re-using user controls across classic Asp.net projects was a pain and was never really the best way to truly create reusable components. Most UI toolkits that you bought for classic ASP.net didn't give you user controls, they gave you essentially server controls and javascript controls.
In your example, I would probably create or find a jquery (or ur framework of choice) plugin that did what you wanted on the client side. You could also build a C# wrapper around it similar to what Telerik did with some of the jquery UI controls. I do think that the word code-behind and even viewstate will disappear from your vocabulary the more you get into MVC.
If you look at what open source projects are out there for MVC you will get your answer in terms of what you should be doing.
The MVC Contrib app adds a lot of features by creating extension methods and helpers. Their grid control is a typical way to create a reusable component that you could use across projects
Telerik, created some extensions that wrap jquery controls and do asset management.
Finally I think if you look to the future, MVC has areas, which if I interpret it right will give you the ability to break your project apart into multiple smaller projects.
Besides what is already suggested, ASP.NET MVC v2 will have generic templated input controls, see here. You can read how other people do similar techniques, for example, here:
We have
exactly 1 method call for generating a
form element, “Html.InputFor”. As
part of that “InputFor”, it examines
an input specification, that collects
the PropertyInfo, any attributes, the
type, any modifiers called, and
selects an appropriate InputBuilder.
Call InputFor(p => p.Id) and Id is a
GUID? That creates a hidden input
element. Call InputFor(p =>
p.Customer.Address) and Address is a
complex type? That looks for a
partial with the same name of the type
Having considered the helpful answers from others, I will have a go at answering my own question.
It seems to me that the key difficulty with emulating UserControls in MVC is that they crosscut the concerns that MVC aims to seperate. The from/to date selector UserControl in my example incorporates elements of Model, View, Control and interation. UserControls' ability to bundle all this together is exactly the reason that they don't fit well into MVC.
That means that to create a psuedo-UserControl in MVC requires four seperate pieces:
A Model class - in this case an Interval class or similar
A PartialView that knows how to render the Model to HTML
A jQuery script to layer interactivity on top of the PartialView's HTML
A ModelBinder that can deserialise postdata into an instance of the Model class.
The ModelBinder is important because it deals with data coming back from the user. Without it, every Controller that wanted to display a to/from date selector in any of its Views would have to know how to assemble the six postdata fields - and how to cope if they were invalid or some were missing.
Two ways that I can think of. A partial view though this doesn't really transfer well from app to app because you are moving around ascx files. Not a big pain but not my flavour.
I prefer to use WebControls. They are super easy in mvc and all you need to do is reference the library in the project and possibly in your config file and there you go.
I think some of the answers have missed out on the postback functionality of controls. One way you could handle that is to pass any generic information via ViewData when rendering your partial view. That could then post back to its own control, which in turn could redirect to the UrlReferrer.
Its a little messy and use of UrlReferrer poses a security risk. But it is one way around the problem
You can create a jQuery plugin.
As user-controls provided in ASP.NET Webforms, MVC provide a lot of ways to make the controls and code that can be reused in other app.
Using Partials If your partial code have some C# logic and render the html using Razor/aspx code then it's bst to maintain them in razor file.
Write JavaScript Functionality as plugin If you maintain your code and write it as better as it can be used in other app then it would be a huge advantage for you. Next time when you work on other app just open this solution copy it and modify it. Write JavaScript code that can be used as plugin maybe take some more brainstorming.
Write Code As a Separate C# library If some code is too common for every app you make.for example you write a member authentication system or some global function (C#) that are used in every app you made then maintain them in a separate solution so it can be used in other app you made whenever you trying to make a new app in future.