Is there any example of binding any sort of collection to a TableLayout in android? I keep receiving the message/warning that binding failed for attribute ItemSource LocationQuantities. All of the other bindings to the view model work as normal, but the list doesn't bind to the TableLayout. At first I thought my problem was binding to a dictionary but I was able to bind to a dictionary with other Mvx layouts (listview etcs.)
I can't seem to find in any of the N+ code examples or anywhere else on the web where a TableLayout is actually used in an mvvmcross app. I'm sure I'm just doing something stupid simple wrong here.
<Mvx.MvxTableLayout
p1:id="#+id/PartLocationQtyTable"
p1:layout_width="fill_parent"
p1:layout_height="wrap_content"
p1:layout_below="#id/PartDetailPriceLayout"
p1:padding="5.0dp"
local:MvxBind="ItemSource LocationQuantities"
/>
I've tried the above as well as with a custom template. The above example just uses a list of strings.
Any help would be appreciated
The only obvious problem I can see with your code is that it uses ItemSource whereas all the list-based layouts use ItemsSource - see MvxTableLayout.cs#L89
Beyond that, I guess you'll also want to make sure that your templates for TableLayout are TableRows - so that they can be loaded as rows. Obviously we can't see your item templates currently as you've not included them in the question.
I've got to admit TableLayout isn't something I've ever personally used in a production project - just not something I've yet needed to use.
Related
I got a url http://www.asp.net/mvc/overview/views/dynamic-v-strongly-typed-views
they create a not strongly typed view but at they refer #model dynamic at top of the view.
but rest of the code looks like normal strongly typed view. anyone can tell me what is the difference between Dynamic and Strongly Typed Views in MVC.
When one should use dynamic view. discuss with example when dynamic view is required ?
The difference is that a dynamic view won't enforce compile-time type-checking (binding to properties etc). You can name and bind any property you want. At run time, if it can't find it in the model, that's when you'll get an error. It's the same as the dynamic keyword in the language.
As to why or when to use it, generally speaking, don't. It's a workaround. Write a wrapper class, write the DTO, write an adapter, there's plenty of ways to make a strongly typed object to bind to. Implement an interface or something.
Rarely you might come across a situation where it's just not feasible (legacy code, 3rd party libraries?) to do it the "right" way. That's when you might be stuck with it. Run time errors are not fun to try to recover from - try to never use dynamic views.
The only time I personally have used it was to mock up test layouts and I didn't want to actually create full models yet. I'd not use it for production code.
Actually someone asked me this question and I'm also interested to know, that how to bind data to a UI element directly. I know UITableview have Datasource property but it doesn't bind data directly. We have to use its protocol methods to bind data in code.
Is there any other way from which we can bind data to the View or is this possible or not? In .Net gridview we can bind data from database to gridview directly.
Update: If you mean synchronizing backing data with UI elements then read the last paragraph.
It would be against the recommended MVC pattern to bind data directly to the view if I understand your question correctly. Check the below links for more info.
Why MVC?
[Why MVC instead of good old ASP.NET? Still not grasping why I should go this route?][2]
However if you do want to bind data directly, there is nothing stopping you from it, even though it might be a bad idea unless the use case is trivial. For e.g. UITableViews are available with static cells. And if a pre-built UI element doesn't have a provision to bind data (don't know of any) to it directly, you could make a similar UI element that serves the purpose.
However it would take way more effort to build such and element than to supply data to it the existing one through preferred methods.
By binding data directly, if you mean supplying the data through interface builder, then you are out of luck. In Cocoa (for OS X application development), there is something called Bindings that help you synchronize your UI elements with the backing data. However in iOS there isn't such a thing. But you could use Key - Value - Observing to achieve this to some extent.
Also why iOS might not have such bindings may be partially answered here:
Is there any technical/conceptual reason why iOS does not support Cocoa Bindings?.
And check this if you have a need on such functionality: Is there any data binding mechanism available for iOS?
While it isn't exactly binding, I have used didSet property observers to update UI elements like this:
var label: UILabel?
var labelText = "Change me." {
didSet {
label?.text = labelText
}
}
That assumes you have initialized label somewhere appropriately. I believe that is the closest you can get in iOS.
I have a bit of a dilemma, which to be honest is a fringe case but still poses an issue.
Currently I am using Ninject MVC and bind all my controllers like so:
Kernel.Bind<SomeController>.ToSelf();
Which works a treat for 99% of things that I have needed to do, however at the moment I am doing some wacky stuff around dynamic routing and dynamic controllers which require me to manually write a method to get the type of a controller from ninject. Now initially I thought it would be easy, but its not... I was expecting that I could get the controller based on its name, but that didnt work.
Kernel.Get<IController>("SomeController");
That got me thinking that its probably because it only knows about a binding to SomeController, not IController. So I thought, I can just write all my bindings like so:
Kernel.Bind<IController>.To<SomeController>().Named("SomeController");
This way it should be easy to get the type of the controller from the name doing the previous code, however if I were to bind this way, I would have a problem when I come to unbind the controllers (as plugins can be loaded and unloaded at runtime). So the normal:
Kernel.Unbind<SomeController>()
Which was great, will no longer work, and I would have to do:
Kernel.Unbind<IController>();
However then I realised that I need to give it some constraint to tell it which binding for this type I want to unbind, and there seems to be no overloads or DSL available to do this...
So I am trapped between a rock and a hard place, as I need to satisfy the ControllerLookup method, but also need to keep it so I can add and remove bindings easily at runtime.
protected override Type GetControllerType(RequestContext requestContext, string controllerName) {
//... find and return type from ninject
}
Anyone have any ideas?
(Just incase anyone questions why I am doing this, its because of the way I am loading plugins, Ninject knows about the types and the namespaces, but within the context of creating a controller it doesn't know the namespace just the controller name, so I do this to satisfy the isolation of the plugin, and the location of the dynamic controller, it is a roundabout way of doing it, but it is what people have done with AutoFac before Example of similar thing with AutoFac)
In my opinion the bindings should be created once at application startup and not change anymore after the first resolve. Everything else can lead to strange issues. Unless you have proper isolation using an AppDomain for each plugin you can not really unload them anyway. Instead of unloading bindings you can make them conditional and disable them using some configuration.
If you really want to unload bindings then I suggest not to do it for single bindings but take advantage of modules. Load all bindings belonging to one plugin together in one or several modules and unload those modules instead of the single bindings.
I was wondering if someone here could shed some light on some questions I was having lately about Razor.
1) Basically, I wanted to split section definition into multiple parts? Why? Because I wanted to.
Sadly using #section "sectionname" twice threw an exception.
Looking deeper into the Razor source, I saw that Razor checked if a section had already been defined and threw an exception if it was already defined.
As Razor uses delegates to render sections, I changed the code to use Delegate.Combine (if a section had been defined before), and it worked, I was now able to create a Section that was declared twice (or more).
2) When a section is defined in a View but not rendered in the layout page an Exception is thrown. I haven't seen an elegant solution to overcome this. If I want to use a View page with multiple layout pages... This is kind of a problem.
Looking at the source (again) there's just a foreach that checks if every section defined in the view has been rendered, and then it throws an exception if a section hasn't been rendered.
I have thought of some solutions (especially for my second question, inheriting from the view base class and exposing the non-rendered sections to the layout page and doing some handling), but they seem... kind of like hacks. Are there any better solutions then actually changing the source?
Not really important, but if anyone also has any insight on the design decisions that led Razor to be this way, I'd also be grateful, as this seems to be a very restrictive design.
update:
#davidferguson and #takepara you've got it wrong. My problem isn't with defining a section in the layout, and not defining it in the view, but the other way around. Defining it in the View but not defining it in the layout.
1) Unfortunately that was a design decision made early on in the product as there is huge issues around merging sections together and in what order. Not saying that we couldn't do it but with the time frame we had it just wasn't possible to support it as a first class citizen in all scenarios.
2) This is an interesting idea. There really isn't an good solution to this other than changing the source code. However, I have opened an issue for a feature for vNext that would allow for this type of scenario. (No promises that it will make the cut though)
To stop an exception being thrown when a section is not used on a view use the required parameter.
#RenderSection("sectionname", required: false)
using this if any view does not implement this section no exception will be thrown.
Defining Default Content For A Razor Layout Section
This is very nice entry.
I don't really see the need for element to element binding in Silverlight 3 if using MVVM. Won't having one property directly affect another proper cause that property to be untestable?
To me, it makes more sense to do a two way binding to a explicit property defined in the ViewModel.
I agree that the use of MVVM severely deflates the usefulness of element to element binding.
Still, if all you are doing is binding two elements using a ViewModel property... what can you test? You can test that setting a property in the ViewModel sends a PropertyChanged event... but thats about it. Only when something else cares about that value is it useful to test a property like that.
In the simple cases, I can see element2element binding being more efficient and less code.