@TheRealJasonSmith Has Implicit styling on custom controls been fixed yet? So In App.xaml or root layout control of the app, can we do an implicit style on our own controls in a separate library? Currently we cannot do that but with the new control templates I think it would be very important.
@BradChase.2654 you mean application to subclasses? Implicit styles are explicitly defined as not apply to a subclass, though there are thoughts going around about how me might improve your selector support for what an implicit style applies to. Its not so much broken as its specced to work in a way you dont want like. There are solid reasons for the default being to not go to subclasses which I wrote down in OneNote somewhere but I'll be fucked if I can find it now (I cant, its lost to the OneNote gods).
@TheRealJasonSmith hah yea thats exactly what I meant. When we use the TemplatedView will we be able to? So say we inherit from ContentView, implicit styling wont work, right I get that limitation right now, BUT. If we inherit from the TemplatedView, can we now? Or might we be able to in the future?
EDIT: The functionality that I really need only applies to TemplatedView's not any "inherited" class really. If that makes sense.
Only issue I have run into so far is Element.Effects.Clear() will not work. You have to explicitly remove that Effect using Element.Effects.Remove or RemoveAt. Also, looks like you can only have one effect instance attached to one view.
Just a quick update on the non-showing up WP lists. Those will be fixed soon, we have discovered the root of the issue (an event wasn't properly tracked).
I think AppCompat made a buggy navigation bar even worse. I see multiple bugs on it in addition to the styling issues. Would really like to see some exclusive Android love. considering WP got lots of attention in this release.
The Navigation with AppCompat is completely broken...Xamarin where are you? This bug is not a minor thing, we can't release app for Android if you don't fix it. Don't you think we deserve a reply?
I am still getting a nullref exception when opening some views on WP (sometimes the first time I open it, usually the second time I open it).
It never happened before 2.0 and never happens on any other platform.
No stacktrace from the Unhandled exception. I do not even know where to begin.
If I debug step by step it does not crash. Something must be called before it is assigned somewhere, but I have absolutely no clue on how to deal with this…
Did something happen to the myView.RotateTo(); api?
When I run 2.0.1, it runs as expected, when I update to this pre release, it crashes stating that animations must be run on the UI thread.
I've got the source at work, but just remembered about it now and thought I'd ask before spending time wiring up a repro.
@TheRealJasonSmith have you been able to fix the UWP empty lists bug? I'm really waiting for this so I can implement the new features (Effects, ControlTemplate)
We have identified the problem yes. In general right now so long as you set your ListView.ItemsSource before the renderer is created you wont have an issue, obviously this is a blocker for release.
I need to change the items multiple times during the app lifecycle, so this is not a usable workaround for me. When can I expect a fix for this issue? (I can't imagine this bug being too hard to fix)
@TheRealJasonSmith Unfortunately I get nothing more, except that it comes from Xamarin.Forms.Platform.WP8.dll
Full informations:
System.NullReferenceException occurred
Message: Exception thrown: 'System.NullReferenceException' in Xamarin.Forms.Platform.WP8.DLL
Message: Exception thrown: 'System.NullReferenceException' in System.Windows.ni.dll
Additional information: Object reference not set to an instance of an object.
@TheRealJasonSmith - I couldn't see it in the list of bug fixes here but a regression in 2.0.1 where an IsPassword=True on an Entry and the Keyboard="Numeric" only shows the default keyboard on WinRT. Will repro and file that tomorrow morning.
Also I have another PITA bug that I am still tracking down, same code works in iOS but not WinRT. Where I switch MainPage to another NavigationPage, pop, then push another page and it just turns to a black screen. No issue in iOS though.
The interesting thing I found is for some reason it was adding it on the ModalStack as well as the NavigationStack (completely bizarre because I don't use the Modal Stack at all anywhere in my project) and I only push to the navigation stack. This issue seems to be with this release and previous ones, so it doesn't look like a regression.
But its only occurring my larger project and having trouble replicating it with a smaller project. But just thought I would mention it in case it springs something to mind.
They are not going away anytime soon, we deprecated them because their use should be heavily discouraged. That said I would be curious to know in what fashion they are essential to you as they literally just call the other API anyway.
The more I think about it, I'd be surprised to see it go away. Maybe we are talking about different things.
I use Bindable Properties when creating reusable controls that need to have bindable hook points to the outside world, ie the consumer of the control. If there is a different preferred way to create a property on a class which is bindable, that would likely work as well.
As an example, in my app I have created a reusable TypedPicker < T >
public class TypedPicker<T> : cPicker
{
#region Bindable Property SelectedItem
public T SelectedItem
{
get { return (T) GetValue(SelectedItemProperty); }
set { SetValue(SelectedItemProperty, value); }
}
public static readonly BindableProperty SelectedItemProperty =
BindableProperty.Create<TypedPicker<T>, T>(
p => p.SelectedItem, default(T), propertyChanged: SelectedItemChanged);
// Omitted SelectedItemChanged method to update internal values
#endregion
#region Bindable Property TypedItems
public IList<T> TypedItems
{
get { return (IList<T>) GetValue(TypedItemsProperty); }
set { SetValue(TypedItemsProperty, value); }
}
public static readonly BindableProperty TypedItemsProperty =
BindableProperty.Create<TypedPicker<T>, IList<T>>(
p => p.TypedItems, default(IList<T>), propertyChanged: TypedItemsChanged);
// Omitted TypedItemsChanged method to update internal values
#endregion
public IValueConverter ValueConverter { get; set; }
// Omitted code, responsible for updating values and keeping everything in sync.
}
This control can then be consumed in the following manner
It looks like I just need to update the way I call Create(). I do lose the typed propertyChanged method, but if it's for the better then I'm ok with that.
Does this mean that I stand to have a performance gain by refactoring them?
Posts
@TheRealJasonSmith Has Implicit styling on custom controls been fixed yet? So In App.xaml or root layout control of the app, can we do an implicit style on our own controls in a separate library? Currently we cannot do that but with the new control templates I think it would be very important.
@BradChase.2654 you mean application to subclasses? Implicit styles are explicitly defined as not apply to a subclass, though there are thoughts going around about how me might improve your selector support for what an implicit style applies to. Its not so much broken as its specced to work in a way you dont want like. There are solid reasons for the default being to not go to subclasses which I wrote down in OneNote somewhere but I'll be fucked if I can find it now (I cant, its lost to the OneNote gods).
@TheRealJasonSmith hah yea thats exactly what I meant. When we use the TemplatedView will we be able to? So say we inherit from ContentView, implicit styling wont work, right I get that limitation right now, BUT. If we inherit from the TemplatedView, can we now? Or might we be able to in the future?
EDIT: The functionality that I really need only applies to TemplatedView's not any "inherited" class really. If that makes sense.
we are evaluating options for the future
On Windows UWP all my ListViews are empty
This is my XAML:
<ListView ItemsSource="{Binding Items}" ItemTapped="ListView_ItemTapped"> <ListView.ItemTemplate> <DataTemplate> <ViewCell> <Label Text="Test" /> </ViewCell> </DataTemplate> </ListView.ItemTemplate> </ListView>This is awesome!
Only issue I have run into so far is Element.Effects.Clear() will not work. You have to explicitly remove that Effect using Element.Effects.Remove or RemoveAt. Also, looks like you can only have one effect instance attached to one view.
@DominikWeber we're seeing this too in some other test apps, trying to work out the conditions that trigger it
Quick question, if
BindableProperty.Create<TDeclarer, TPropertyType>is deprecated, what is it being replaced with?@ChaseFlorell just use the non-generic version.
Just a quick update on the non-showing up WP lists. Those will be fixed soon, we have discovered the root of the issue (an event wasn't properly tracked).
@TheRealJasonSmith is that simply for performance reasons?
anybody else getting consistent crashes when ListView.IsGroupingEnabled="true" bound to an observable collection?
Have a bug filed here
https://bugzilla.xamarin.com/show_bug.cgi?id=38067
@TheRealJasonSmith @BryanHunter.xam
There are multiple reported bugs with regards to Android navigation bar. It's really difficult to theme it without running into styling bugs.
Can these be given attention in the next release?
https://bugzilla.xamarin.com/show_bug.cgi?id=38019
https://bugzilla.xamarin.com/show_bug.cgi?id=26247
https://bugzilla.xamarin.com/show_bug.cgi?id=22237
https://bugzilla.xamarin.com/show_bug.cgi?id=38019
I think AppCompat made a buggy navigation bar even worse. I see multiple bugs on it in addition to the styling issues. Would really like to see some exclusive Android love.
considering WP got lots of attention in this release.
Found this one in AppCompat a while back. Can't really look it until it becomes more stable.
https://bugzilla.xamarin.com/show_bug.cgi?id=36907
The Navigation with AppCompat is completely broken...Xamarin where are you? This bug is not a minor thing, we can't release app for Android if you don't fix it. Don't you think we deserve a reply?
I am still getting a nullref exception when opening some views on WP (sometimes the first time I open it, usually the second time I open it).
It never happened before 2.0 and never happens on any other platform.
No stacktrace from the Unhandled exception. I do not even know where to begin.
If I debug step by step it does not crash. Something must be called before it is assigned somewhere, but I have absolutely no clue on how to deal with this…
Guess I am back on 1.5… again.
I discoverd that when using a stacklayout inside a grid on Windows Phone the ColumnDefinition
is ignored. I found the reason / workaround for it:
using Orientation = StackOrientation.Horizontal triggers the behavior -> result is XF is ignoring the sizes of the grid
CreateGrid(); Label _Label1 = CreateListViewDeviceNameLabel(); Label _Label2 = CreateListViewDeviceNameLabel(); StackLayout _placeHolderStackLayout = new StackLayout { // using StackLayout.Orientation propertie on XF 2.1.0 pre2 result in ignoring size definitions of the grid Orientation = StackOrientation.Horizontal, Children = { _Label2 } }; _gridMainLayout.Children.Add(_Label1, 1, 0); _gridMainLayout.Children.Add(_placeHolderStackLayout, 1, 1); private void CreateGrid() { _gridMainLayout = new Grid(); _gridMainLayout.RowDefinitions.Add(new RowDefinition { Height= new GridLength(45,GridUnitType.Absolute) }); // _gridMainLayout.RowDefinitions.Add(new RowDefinition { Height= new GridLength(45,GridUnitType.Absolute) }); // _gridMainLayout.ColumnDefinitions.Add(new ColumnDefinition { Width = new GridLength(90, GridUnitType.Absolute) }); // _gridMainLayout.ColumnDefinitions.Add(new ColumnDefinition { Width = new GridLength(100, GridUnitType.Absolute) }); _gridMainLayout.ColumnDefinitions.Add(new ColumnDefinition { Width = new GridLength(80, GridUnitType.Absolute) }); // } public Label CreateListViewDeviceNameLabel() { Label deviceNameLabel = new Label { Text = "This Text should be cut off at the end of the 2 Column", TextColor = Color.White, LineBreakMode = LineBreakMode.NoWrap, }; return deviceNameLabel; }`
@MarcoT We are aware of the issue and it is being worked on.
Did something happen to the
myView.RotateTo();api?When I run 2.0.1, it runs as expected, when I update to this pre release, it crashes stating that animations must be run on the UI thread.
I've got the source at work, but just remembered about it now and thought I'd ask before spending time wiring up a repro.
@Paul_Roy turn on break on throw in your exception settings so you can capture the stack trace and we will track down the issue.
@ChaseFlorell nope, what platform? Trace would be nice too
@MarcoT it is fixed in the next pre-release
@TheRealJasonSmith have you been able to fix the UWP empty lists bug? I'm really waiting for this so I can implement the new features (Effects, ControlTemplate)
We have identified the problem yes. In general right now so long as you set your ListView.ItemsSource before the renderer is created you wont have an issue, obviously this is a blocker for release.
I need to change the items multiple times during the app lifecycle, so this is not a usable workaround for me. When can I expect a fix for this issue? (I can't imagine this bug being too hard to fix)
Its already fixed, we're putting together the next pre soon.
great, thanks!
@TheRealJasonSmith Unfortunately I get nothing more, except that it comes from
Xamarin.Forms.Platform.WP8.dllFull informations:
If only I had a line on my code to help you…
@TheRealJasonSmith But I have a dump if this helps.
@TheRealJasonSmith - I couldn't see it in the list of bug fixes here but a regression in 2.0.1 where an IsPassword=True on an Entry and the Keyboard="Numeric" only shows the default keyboard on WinRT. Will repro and file that tomorrow morning.
Also I have another PITA bug that I am still tracking down, same code works in iOS but not WinRT. Where I switch MainPage to another NavigationPage, pop, then push another page and it just turns to a black screen. No issue in iOS though.
The interesting thing I found is for some reason it was adding it on the ModalStack as well as the NavigationStack (completely bizarre because I don't use the Modal Stack at all anywhere in my project) and I only push to the navigation stack. This issue seems to be with this release and previous ones, so it doesn't look like a regression.
But its only occurring my larger project and having trouble replicating it with a smaller project. But just thought I would mention it in case it springs something to mind.
@TheRealJasonSmith Sorry, third post…
I was able to get a stacktrace with the .NET reflector (http://forums.xamarin.com/discussion/comment/177455#Comment_177455)
The additional features sound great, thanks for that!
But why did you deprecate
BindableProperty.Create<TDeclarer, TPropertyType>? I found those quite convenient. Is there any downside I'm not aware of?@MichaelRumpler they come with a large performance and app size penalty on iOS
Hi @TheRealJasonSmith @MichaelRumpler
Regarding Generic versions of Create () BindableProperty are no longer supported and deprecated;
Is this referring to this?
http://developer.xamarin.com/guides/xamarin-forms/custom-renderer/view/#Creating_the_Custom_Control
AND
https://developer.xamarin.com/api/type/Xamarin.Forms.BindableProperty/
If so, this is essential to my custom controls.
Thanks
They are not going away anytime soon, we deprecated them because their use should be heavily discouraged. That said I would be curious to know in what fashion they are essential to you as they literally just call the other API anyway.
Thanks for the quick reply @TheRealJasonSmith
The more I think about it, I'd be surprised to see it go away. Maybe we are talking about different things.
I use Bindable Properties when creating reusable controls that need to have bindable hook points to the outside world, ie the consumer of the control. If there is a different preferred way to create a property on a class which is bindable, that would likely work as well.
As an example, in my app I have created a reusable TypedPicker < T >
public class TypedPicker<T> : cPicker { #region Bindable Property SelectedItem public T SelectedItem { get { return (T) GetValue(SelectedItemProperty); } set { SetValue(SelectedItemProperty, value); } } public static readonly BindableProperty SelectedItemProperty = BindableProperty.Create<TypedPicker<T>, T>( p => p.SelectedItem, default(T), propertyChanged: SelectedItemChanged); // Omitted SelectedItemChanged method to update internal values #endregion #region Bindable Property TypedItems public IList<T> TypedItems { get { return (IList<T>) GetValue(TypedItemsProperty); } set { SetValue(TypedItemsProperty, value); } } public static readonly BindableProperty TypedItemsProperty = BindableProperty.Create<TypedPicker<T>, IList<T>>( p => p.TypedItems, default(IList<T>), propertyChanged: TypedItemsChanged); // Omitted TypedItemsChanged method to update internal values #endregion public IValueConverter ValueConverter { get; set; } // Omitted code, responsible for updating values and keeping everything in sync.}
This control can then be consumed in the following manner
<cc:TypedPicker x:TypeArguments="reportingEnum:DateRangeEnum" TypedItems="{Binding AvailableDateRanges}" SelectedItem="{Binding SelectedDateRange, Mode=TwoWay}" ValueConverter="{StaticResource DateRangeEnumToStringConverter}" />Please let me know if you'd like any more info.
Thanks again!
Ant
BindableProperties are not going away, you should just be using the non-generic version of BindableProperty.Create
Ok now I understand.
It looks like I just need to update the way I call Create(). I do lose the typed propertyChanged method, but if it's for the better then I'm ok with that.
Does this mean that I stand to have a performance gain by refactoring them?
Thanks
PS: Very happy to hear BPs are not going away.
Yes there will be a slight performance boost from it. Mostly in startup time.
Thanks @TheRealJasonSmith !
I appreciate the clarification
I have 84 Bindable Properties in my app, so I'll work on getting them refactored.