Changes in MvvmCross bindings - xamarin

Hi Xamarin/MvvmCross devs,
This is just a question out of curiosity. In one of the apps I'm developing some behaviour changed. Specifically on iOS when binding the UISwitch "On" value to a boolean in the ViewModel. The getter on the property fires when the binding is applied as well as the setter when the switch is flipped, but the UI does not reflect it. Forcing me to go from just
var set = this.CreateBindingSet<SettingsView, SettingsViewModel>();
set.Bind(PushNotificationSwitch).For(s => s.On)
.To(vm => vm.ReceivePushNotifications);
set.Apply();
To having to also add the following below that (to get the UI of the switch to reflect the value)
var settingsViewModel = ((SettingsViewModel)ViewModel);
PushNotificationSwitch.On = settingsViewModel.ReceivePushNotifications;
I left the binding, as well as the new code to reflect UI state, because in addition to the UI just reflecting the correct state, I also want it to change the state in my settingsService when the user changes it.
I recently upgraded through Xamarin Studio on Mac and my iOS Xam version is Version: 10.0.0.6. Unfortunately I didn't check what version I upgraded from, but I always upgrade as soon as I see there's one available, so it should be the previous stable version.
My questions are:
Has any of you experienced similar issues where bindings changed in this way?
Since the Android binding still works fine, do you think it's an issue in MvvmCross, or iOS Xamarin Changes
Any speculations as to what could be causing this? And other parts that you think this might affect, so I won't have to go scour for bugs if none exists. Commands, text and custom control bindings are working fine (as far as I've tested)
If this question would be better suited somewhere else please let me know, I'm just curious about this behaviour.
Thanks

As we worked out in the comments of the OP the event of the switch was linked out. Hence, the binding did nothing.
Easiest way to remedy this is to add the following code to your LinkerPleaseInclude.cs file, which MvvmCross provides in the Startup NuGet and through the templates available for Visual Studio and Xamarin Studio:
public void Include(UISwitch sw)
{
sw.On = !sw.On;
sw.ValueChanged += (sender, args) =>
{
sw.On = false;
};
}
This will tell the Linker that there is a direct usage of both the ValueChanged event and the On property, since the LinkerPleaseInclude class uses the Preserve attribute.

Related

Create a size changing Editor in Xamarin

I want to create a Xamarin Forms Editor Control that changes its height when it gets filled(Adds a new line when space in previous line finished). I'm only interested in WinPhone and Android Platfroms.
The Editor itself doesn't support such property.
I know that the Android native control (EditText) supports it (Not sure about the WinPhone variant, TextBox). But I'm not sure how to implement it.
It will be very helpful if someone can explain me how to create the renderers for these platforms.
Edit
I found this partial solution, it kind of works fine but it is not so natural(as for example EditText in Android).
class RoundedEditor : Editor
{
public RoundedEditor()
{
this.TextChanged += (sender, e) => { this.InvalidateMeasure(); };
}
}
I'll be glad if someone will provide a better solution.
Edit 2
Here are the results of how it works now:
UWP
Writing first line:
pressing enter:
The previous line is not showed completely as I would like.
Android
In android it actually works great:
You will have to implement a custom Android EditText, and then use it for your XamarinForms control (by implementing a custom renderer for it)
Take a look at this implementation of resizable EditText:
https://github.com/ViksaaSkool/AutoFitEditText
You'd have to translate it to C# obviously, but its a great start point.

Conditional Compilation seems to be not working in Xamarin Studio

I created a Xamarin Forms app.
And inside a new page with a label named "MyLabel".
In the code behind for my page I have
private void SetUpUI()
{
#if __IOS__
this.MyLabel.BackgroundColor = Color.Navy;
#endif
}
In my iOS project options I can see symbol __IOS__ in the "Compiler" tab. (please see screenshot)
When I run in iOS it doesn't make the label blue:
But if I remove #if __IOS__ block it makes the label blue:
So it seems conditional compilation is not working.
I'm on a Mac. So couldn't test on Visual Studio.
Stuck with it for a long time but cannot figure out what I missed.
The answer of SushiHangover is correct: your PCL project won't have the compiler definitions for the platforms.
However, the solution he provides has become obsolete since Xamarin Forms 2.3.4 was released. Device.OnPlatform has been redesigned as discussed in this discussion and implemented in this Pull Request.
The correct way to do this in Xamarin Forms 2.3.4 and onwards is by using Device.RuntimePlatform. Use a switch or conditional to suit your needs like so:
if(Device.RuntimePlatform == Device.iOS)
{
// iOS
}
else if(Device.RuntimePlatform == Device.Android)
{
// Android
}
It would be possible to do it like you asked, if you were to use a shared project instead of a PCL. Because when you use a shared project, you have access to the compiler directives of your platform projects.
You are using the conditionals in your PCL project which would not contain those compiler defines, thus why your conditional code is greyed out.
In your PCL project you can use Device.OnPlatform to perform platform based processing:
Device.OnPlatform (iOS: () => this.MyLabel.BackgroundColor = Color.Navy; );
re: https://developer.xamarin.com/api/member/Xamarin.Forms.Device.OnPlatform/

Vaadin ckEditor addon has two panels

No matter what I do when I run the latest version of ckEditor I have two panels on my screen. Both are populated with data. Although you can only see one editor in full on the screenshot if I increase the height you can see both editors. I've brought the code down to the bare minimum. It use to work but in the latest version I always have two editors no matter what I do, and no matter what browser I use.
Also when I call getValue() on the editor it always brings back the value of the bottom editor. I've confirmed this by putting different values in the different editors.
My code is:
protected void init(VaadinRequest request) {
{
CKEditorTextField ckEditorTextField = new CKEditorTextField();
ckEditorTextField.setValue("hello world");
ckEditorTextField.setHeight("500px");
ckEditorTextField.setWidth("500px");
setContent(ckEditorTextField);
}
And yes I know I should use CKEditorConfig but I've tried to minimize all code to the bare minimum. I've also tried with layouts and it makes no difference. The reason I put the height and width is to make it more visible, but it's not required. Also this code is called on the main UI class.
The issue was that an upgrade to Vaadin hadn't properly taken, there were still some caching issues. The way to resolve it can be found here: https://vaadin.com/forum/#!/thread/2963857/2963856
The steps are:
Ivy-> Clean all caches
Ivy -> Resolve
Reboot Eclipse
Compile Vaadin widgets

Cordova AngularJS Windows 8 App Fails on ui-bootstrap Templates with "directive must have exactly one root element"

I am using Cordova 4.0.0 with AngularJS 1.2.26, Angular-Bootstrap 0.11.2, and UI Router 0.2.11 to create apps for Android and Windows (8.0 and 8.1). I am having an issue only when running the application in Windows with ui-bootstrap templates. The same error keeps popping up for standard templates for typeahead, datepicker, and the modal dialog, "Template for directive { whatever } must have exactly one root element."
Looking at the DOM inspector within Visual Studio, it seems that every node that has the ui-view directive is getting populated with its own set of head and body tags (which wraps around the template in question). I'm guessing that this is the issue, but am having trouble pinning down where these extra nodes are being inserted, and thus, having trouble proving out the theory.
The same code works as desired in the latest Chrome, FireFox, and IE desktop browsers, as well as within Android.
Does anyone have any insight on this behavior? It might also be worthwhile to note that ngCsp is being used to alleviate dyanmic content insertion restrictions on Metro applications.
Thanks in advance!
I found that the problem was in the shim winstore-jscompat.js
The method used to add the new tags has a bug.
My version of that method is:
cleansePropertySetter("innerHTML", function (propertyDescriptor, target, elements) {
empty(target);
for (var elementIndex = 0, elementsLength = elements.length; elementIndex < elementsLength; elementIndex++) {
if (elements[elementIndex].nodeName == 'BODY') {
for (var childIndex = 0, amountOfChildren = elements[elementIndex].childNodes.length; childIndex < amountOfChildren; childIndex++) {
target.appendChild(elements[elementIndex].childNodes[0]);
}
}
}
});
This did the trick for me. I have not yet tested all variations of directives.
The fix above didn't work for me, but I found a Fork that fixes the issue:
https://github.com/ClemMakesApps/winstore-jscompat/blob/master/winstore-jscompat.js
Note that this will probably be pulled into the main project at some point so this issue should go away "soon".
Also here is the original issue:
https://github.com/MSOpenTech/winstore-jscompat/issues/8

MvvmCross, Xamarin Studio and ICommands

My issue was born in Does MvvmCross work in Xamarin Studio?. MvvmCross works fine in Visual Studio. However, I've been mandated to deploy this corporately using Xamarin Studio which is what their build server uses. I ran into the issue with System.Windows.Input.ICommand not being found by the compiler during my Xamarin Studio build. ICommands appear to be used quite extensively throughout MvvmCross for user commands (MvxCommand, which implements System.Windows.Input.ICommand). I've tried creating my own version of ICommand via the following code:
using System;
namespace Something.Common
{
public interface ICommand
{
event EventHandler CanExecuteChanged;
bool CanExecute(object parameter);
void Execute(object parameter);
}
}
All good, but still doesn't fix MvxCommand, because it implements the interface System.Windows.Input.ICommand. So I created my own version, MvxCommandEx, which is basically copied from Stuart's MvxCommand and implements my own ICommand (Something.Common.ICommand).
Lo and behold, it builds. It deploys. It got me all excited. But.... it didn't work. Any place I've bound a UI element to my custom ICommand just doesn't do anything. It's as if the binding from the Click event of the control to the view model's command is just not there anymore, whether I bind it in the .axml layout file... or use the CreateBindingSet method built-in to the view.
Now... I can get around this for some things... for instance, if I use a standard android Button, and invoke the view model's command manually from the built-in Click event, like:
btnAddScope.Click += (o, i) => { _ViewModel.RequestAddScope.Execute(null); };
it works, and I'm okay doing it this way in the interim until Xamarin releases their PCL support. But I'm using an MvxListView in another section of the app that was bound the old way using a syntax like:
lst.ItemClick = _ViewModel.RequestViewScope;
where lst is a MvxListView.
This won't work, however, because lst.ItemClick expects a System.Windows.Input.ICommand, and my ICommand isn't in that namespace.
Stuart provided explanations for this that supposedly are supposed to work. However, I'm feeling stupid for not being able to implement the ICommand in a way that actually works, when it feels like it should work... so before I go down a different avenue to address this, I wanted to see if anyone could shed light on what I'm doing wrong.
The easy solutions are:
either to provide your own implementation for the Xamarin version of System.Windows.Input.ICommand and to use this implementation
or to use the mvvmcross binaries which are built on the mac.
I'd recommend the first.
If you delete your Something.Common.ICommand code abd then put your MyCommand class implementation in the same project/assembly as your viewmodels, then they should build and run fine on both windows and on mac.

Resources