Xamarin.Forms 2.3.4.270

245

Posts

  • DigilitiDevDigilitiDev USMember ✭✭

    After upgrading but changing no code, my Label styles are now funny. All of my text on both iOS and Android has become the same size. I'm not completely sure, but it's small enough that I think it's just the default text size. I'm doing things like this in my App.xaml:

    <Application xmlns="http://xamarin.com/schemas/2014/forms"
                 xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
                 x:Class="UI.App">
      <Application.Resources>
        <ResourceDictionary> 
          <Color x:Key="baseTextColor">#434340</Color>
          <Color x:Key="errorColor">#ff0000</Color>
    
          <x:Double x:Key="largeTextSize">36</x:Double>
          <x:Double x:Key="mediumTextSize">24</x:Double>
          <x:Double x:Key="smallTextSize">16</x:Double>
          <x:Double x:Key="slightlySmallerTextSize">15</x:Double>
    
          <Style x:Key="largeText" TargetType="Label">
            <Setter Property="FontSize" Value="{DynamicResource largeTextSize}"/>
            <Setter Property="TextColor" Value="{DynamicResource baseTextColor}"/>
          </Style>
          <Style x:Key="mediumText" TargetType="Label">
            <Setter Property="FontSize" Value="{DynamicResource mediumTextSize}"/>
            <Setter Property="TextColor" Value="{DynamicResource baseTextColor}"/>
          </Style>
          <Style x:Key="smallText" TargetType="Label">
            <Setter Property="FontSize" Value="{DynamicResource smallTextSize}"/>
            <Setter Property="TextColor" Value="{DynamicResource baseTextColor}"/>
          </Style>
          <Style x:Key="slightlySmallerText" TargetType="Label">
            <Setter Property="FontSize" Value="{DynamicResource slightlySmallerTextSize}"/>
            <Setter Property="TextColor" Value="{DynamicResource baseTextColor}"/>
          </Style>
    
          <Style x:Key="errorText" TargetType="Label" BaseResourceKey="smallText">
            <Setter Property="TextColor" Value="{DynamicResource errorColor}"/>
          </Style>
        </ResourceDictionary>
      </Application.Resources>
    </Application>
    

    Then I use the styles like this:

              <Label Text="{Binding ContactDetails.Address1}"
                     Style="{DynamicResource mediumText}"/>
    

    The colors all are working great, but the sizes are off. Any ideas?

  • BobbyTablesBobbyTables GBMember ✭✭

    @DavidOrtinau thank you very much for your help. And yes, for the majority of my project I only use ResourceDictionaries in XAML but unfortunately I have one area where I have had to access it in code :)

  • MichaelRumplerMichaelRumpler ATMember ✭✭✭✭

    @MiguelCervantes said:

    @StephaneDelcroix said:
    @MiguelCervantes:

    Why is SetBinding<T> obsolete

    Well, there are multiple reasons...

    1. Because all the BindableProperties.Create<,> were obsoleted (see why in 2.)
    2. Because the Expressions used as arguments are evaluated at runtime, and on runtimes without a JIT, they rely on an IL interpreter which is kinda slow (we shaved a few 100ms of startup time by changing all of our internals BP.Create<,> to the non-generic version.
    3. Because you can achieve the same level of source safety (making sure that a property rename refactoring doesn't break all of your code) by using nameof()

    @StephaneDelcroix and @rogihee

    Ok no that makes a lot of sense to me, and yes indeed I was worried about source safety! but performance enhancements are always welcome!

    So in general getting rid of generics is a boost on performance?

    The generics are not the problem.

    Parsing the System.Linq.Expressions.Expression<Func<TDeclarer, TPropertyType>> is the expensive part when calling BindableProperty.Create<TDeclarer,TPropertyType> or BindableObjectExtensions.SetBinding.

  • ChristianSvrdChristianSvrd SEMember ✭✭✭

    @DavidOrtinau said:

    @ChristianSvrd said:
    what is attached properties? I keep getting XamlC error when trying to build with the latest Xamarin.Forms

    Attached Properties: https://developer.xamarin.com/guides/xamarin-forms/xaml/attached-properties/

    More XAML features are now compiled, so some things like these needing a public getter and setter will be more strictly enforced. That may not be your exact issue, but it is an example that came up during the pre-release process.

    after I updated to the new xamarin.forms version I couldn't build anymore because of XamlC errors and there was no hint at whats wrong with my xaml file at all so after like 6 hours of wrestling with it I just decided to roll back to older version of Forms.

  • EugenRichterEugenRichter DEMember

    @DavidOrtinau said:
    @EugenRichter @BobbyTables We've revisited the design discussion around ResourceDictionary and merged dictionary key lookup behavior. We are going to make an adjustment and will push out a service release that remedies your situation.

    In general, ResourceDictionaries are designed as a XAML feature and we recommend you only use them in code when required. A static variable would be easier and more efficient.

    Yes. We use the resource dictionaries most of the time direct in XAML. For some components (Syncfusion SfDataGrid) it is required to write the Style in code (special class that then can be used in XAM style definitions). In this data grid style we apply the resource values to the overriden methods. Sometimes it is required to read the resources also from code.

    At this time I workaround this issue with own implementation of resource reading (same as the internal implementation of resource dictionary) .

  • kikolopes90kikolopes90 PTMember ✭✭

    @PaulDiPietro said:
    @kikolopes90 can you elaborate on which platform and if this is from a template or an app you're already working on? Have you tried the usual clearing of bin/obj and rebuilding?

    Now it works, erased folder "bin/obj" and rebuild and it works, it's strange because I already did it and it did not work.

  • StephaneDelcroixStephaneDelcroix USInsider, Beta ✭✭✭✭

    @ChristopherEbbert I created a new XF 2.3.4 projects, added your resources to the App.xaml, and your label and a few others in a page, and the size looks right.

    If the problem persists, please file a bug with the smallest possible reproduction case

  • MichaelRumplerMichaelRumpler ATMember ✭✭✭✭

    @DavidOrtinau said:
    @EugenRichter @BobbyTables We've revisited the design discussion around ResourceDictionary and merged dictionary key lookup behavior. We are going to make an adjustment and will push out a service release that remedies your situation.

    Please do this in the same way as WPF.

    Any ResourceDictionary indexer/IEnumerator only returns those resources directly within that ResourceDictionary and no merged or parent resources. For getting these you need to use FrameworkElement.FindResource, FrameworkElement.TryFindResource, Application.FindResource or Application.TryFindResource. You could add those methods to Xamarin.Forms.Element and Xamarin.Forms.Application

  • ClayZuvichClayZuvich USMember ✭✭✭

    How would accomplish the following with the new OnPlatform update in XAML?

    <OnPlatform x:TypeArguments="Color" iOS="{x:Static page:Palette._ListSeparatorColor}" />

  • MartSMartS USMember

    @JimmyGarrido said:
    @MartS You should now be able to update the Android Support packages if your project's Target Framework is set to Android 7.0 or higher.

    If you were using Forms 2.3.3.180, be sure to update the Forms package first before trying to update the other ones. That version still required the hard dependencies for all Android versions and the package manager may be updating the support packages before installing the compatible Forms version.

    @JimmyGarrido, thanks for instructions!

    Here's what happens when you start a new project:

    1. File > New project > Cross Platform App (Xamarin.Forms or Native) > Master Detail > UI Tech: Xamarin Forms > Code Sharing > PCL → this picks up Forms v2.3.4.224 automatically
    2. Right click solution > Manage NuGet packages > Updates (9) > select Xamarin.Android.Support packages, press Update

    Expected: Xamarin.Android packages updated

    Actual: Error: Unable to resolve dependencies. 'Xamarin.Android.Support.Design 25.1.1' is not compatible with 'Xamarin.Forms 2.3.4.224 constraint: Xamarin.Android.Support.Design (= 23.3.0)'.

    When I look at Android project properties, then Target Framework has only single entry, Use Latest Platform (Android 6.0).

    Can you perhaps test yourself and tell if creating a new project and updating the Android support packages as described works for you?
    What else can I try?

    My VS is latest V2 2017, Version 15.1 (26403.0).

  • BradChase.2654BradChase.2654 USMember ✭✭✭

    @StephaneDelcroix OK a bit off topic and wrong place but I love how your XAML editor looks, what settings are those?!?!?

  • JimmyGarridoJimmyGarrido USXamarin Team Xamurai

    @MarketAlly Do a clean and rebuild after updating Forms and that should resolve the errors.

    @MartS Since Use Latest Platform is returning Android 6.0 and there are no other entries, this means you do not have the Android 7.0 platform installed. You can install it via the Android SDK Manager by going to "Tools > Android > Android SDK Manager". Restart Visual Studio after installing the platform.

    Note that due to Google removing the GUI manager in newer versions of Android SDK Tools, make sure to deselect any other updates it automatically selects for you and only install the Android 7.0 platform.

  • MarketAllyMarketAlly USMember ✭✭
    edited April 7

    @JimmyGarrido said:
    @MarketAlly Do a clean and rebuild after updating Forms and that should resolve the errors.

    @JimmyGarrido

    I did and it did not (tried multiple times, including uninstalling and reinstalling the nuget for Xamarin.Forms). I had to rollback to 2.3.3.180 - the last 2 now have broken.

    Trying to view the Xaml in the VS also has been broken for close to 4 builds. This is the error I get: https://www.screencast.com/t/fW6UIXGeX

    I am forced to open the file in an xml file editor which is beyond painful. I have a normal install and until recently things were smooth with releases.

    Note the Xaml error above happens on all pages I have extended your ContentPage - so I can have custom renderers for different pages in my project. I wish you guys would resolve this for us.

  • MartSMartS USMember
    edited April 7

    @JimmyGarrido said:
    @MartS Since Use Latest Platform is returning Android 6.0 and there are no other entries, this means you do not have the Android 7.0 platform installed. You can install it via the Android SDK Manager by going to "Tools > Android > Android SDK Manager". Restart Visual Studio after installing the platform.

    Thanks, update works after installing Android 7.0 via Android SDK Manager (it's automatically selected in project properties).

    Sorry for failing to notice that and for inadvertently casting doubt on Xamarin :blush:!

  • StephaneDelcroixStephaneDelcroix USInsider, Beta ✭✭✭✭

    @BradChase.2654 Solarized light theme. Low contrast theme (http://ethanschoonover.com/solarized). I'm using it in most of my editors, including vim. In this case, it's VS for Mac. The theme is built-in.

  • JimmyGarridoJimmyGarrido USXamarin Team Xamurai

    @MarketAlly Can you create a new project and test if you can open a new xaml page without getting the Xamarin.Forms.Core error?
    For the XamlFilePathAttribute error, try manually clearing the /obj and /bin directories in your project before doing a rebuild.

  • MiguelCervantesMiguelCervantes MXMember ✭✭✭

    @MichaelRumpler said:

    @MiguelCervantes said:

    @StephaneDelcroix said:
    @MiguelCervantes:

    Why is SetBinding<T> obsolete

    Well, there are multiple reasons...

    1. Because all the BindableProperties.Create<,> were obsoleted (see why in 2.)
    2. Because the Expressions used as arguments are evaluated at runtime, and on runtimes without a JIT, they rely on an IL interpreter which is kinda slow (we shaved a few 100ms of startup time by changing all of our internals BP.Create<,> to the non-generic version.
    3. Because you can achieve the same level of source safety (making sure that a property rename refactoring doesn't break all of your code) by using nameof()

    @StephaneDelcroix and @rogihee

    Ok no that makes a lot of sense to me, and yes indeed I was worried about source safety! but performance enhancements are always welcome!

    So in general getting rid of generics is a boost on performance?

    The generics are not the problem.

    Parsing the System.Linq.Expressions.Expression<Func<TDeclarer, TPropertyType>> is the expensive part when calling BindableProperty.Create<TDeclarer,TPropertyType> or BindableObjectExtensions.SetBinding.

    Ok so LINQ is bad for app performance at all, as @TheRealJasonSmith said at Evolve last year. I was starting to worry about generics usage.

  • BrightLeeBrightLee KRMember ✭✭✭

    on XF/iOS

    If I use derived class of ListView, 'tap status bar to scroll top' feature stops working.
    It's very hard to understand.

    public class CustomListView : ListView
    {
    //nothing here
    }

    This class's 'tap to scroll top' is not working.
    What's going on here? How can it have different behavior?

  • MichaelRumplerMichaelRumpler ATMember ✭✭✭✭

    @MiguelCervantes said:
    Ok so LINQ is bad for app performance at all, as @TheRealJasonSmith said at Evolve last year. I was starting to worry about generics usage.

    I wouldn't say "at all". There seems to be a problem that parsing those Expression trees is extremely bad.

    I still use LINQ in the code for my app because it's much shorter and better maintainable than the old foreach loops. But it does cause more memory allocations. So if it's in a loop which runs very often, then it can cause problems. As Xamarin cannot know, which of their code will be called very often, they removed LINQ from their Forms code altogether and also reject PRs with LINQ.

  • EmmanuelVazquezEmmanuelVazquez USMember ✭✭

    Hello, I wanted to ask if this PR was in the stable release of 2.3.4. I know it was not included in -pre6 but maybe it was added. Thanks.

  • MarketAllyMarketAlly USMember ✭✭

    @JimmyGarrido said:
    @MarketAlly Can you create a new project and test if you can open a new xaml page without getting the Xamarin.Forms.Core error?
    For the XamlFilePathAttribute error, try manually clearing the /obj and /bin directories in your project before doing a rebuild.

    I reinstalled everything down to the base machine - complete wipe and I don;t have the type issue any longer - the other issue is still present.

    This is the error I still get: https://www.screencast.com/t/fW6UIXGeX

  • GuyProvostGuyProvost CAMember ✭✭✭
    edited April 10

    @ClayZuvich said:
    Is there any guidance on how to get a reference to the Android MapRenderer NativeMap when the map is ready to consume? It looks like the IOnMapReadyCallback is implemented explicitly and there are not any events nor methods that notify subclasses.

    I am currently drawing routes on the GoogleMap; however, I can't figure out how to get a reference to the NativeMap at the right time.

    You had any info on this ? After updating Forms/Forms.Map we got the compile time error about onElementChanged is not an Override of MapRenderer..... Huh ? How can one does CustomMapRenderers now ?

  • ClayZuvichClayZuvich USMember ✭✭✭

    @GuyProvost I posted my workaround for the map issue on https://forums.xamarin.com/discussion/comment/264923#Comment_264923

    You implement the IOnMapReadyCallback, but call the subclass's implementation via reflection first. It's a hack, but it does work. Without calling the base class, you'd have to implement the base class functionality yourself.

  • GuyProvostGuyProvost CAMember ✭✭✭

    @ClayZuvich said:
    @GuyProvost I posted my workaround for the map issue on https://forums.xamarin.com/discussion/comment/264923#Comment_264923

    You implement the IOnMapReadyCallback, but call the subclass's implementation via reflection first. It's a hack, but it does work. Without calling the base class, you'd have to implement the base class functionality yourself.

    Does this means that this release of Forms/Forms.Map breaks almost everyone's code if one implement a CustomRenderer for the map ?

  • ClayZuvichClayZuvich USMember ✭✭✭

    @GuyProvost On the Android side I think so. iOS caused a few issues since they are caching maps now; however, the Android side in my opinion is broken.

  • GuyProvostGuyProvost CAMember ✭✭✭

    @ClayZuvich said:
    @GuyProvost On the Android side I think so. iOS caused a few issues since they are caching maps now; however, the Android side in my opinion is broken.

    Thanks for the info.

    For the iOS version we ditched Forms and went Xamarin.iOS... And I'm glad we did. Forms really burnt us...

    Not only much of the work in this app was done in Android specific code in the CustomRenderer... When the platform that's meant to help us facilitate the work updates... It broke the code! Wow!

    I guess that few people actually went as far as coding a CustomRenderer for a map... That's why this kind of change that broke code was accepted!

  • TonyDTonyD USMember ✭✭✭

    @GuyProvost how long did it take you to go from Forms to Xamarin.iOS? We've also reached the point where nearly everything is on custom renderers because of perf issues/bugs with Forms, so our codebase now looks like Frankenstein.

  • rogiheerogihee NLMember ✭✭✭

    @GuyProvost @TonyD I'm curious what kind of apps you are building or what requires the extreme amount of customization

    I'm doing a total rewrite of a MonoTouch.Dialog app at the moment, and this is really where Forms excels, I think. Relatively simple forms with buttons and lists, nothing fancy, but easily styleable with Forms into a great looking app that has a distinct look and feel but still feels native. The productivity gains are insane to have just 1 layout/navigation for all platforms, and easily worth any tradeoffs for missing features. If you need so many custom renderers, you are missing features in the basic Forms controls / core. Perhaps it could help to post an idea in the Forms evulution area?

  • GuyProvostGuyProvost CAMember ✭✭✭

    @rogihee said:
    @GuyProvost @TonyD I'm curious what kind of apps you are building or what requires the extreme amount of customization

    I'm doing a total rewrite of a MonoTouch.Dialog app at the moment, and this is really where Forms excels, I think. Relatively simple forms with buttons and lists, nothing fancy, but easily styleable with Forms into a great looking app that has a distinct look and feel but still feels native. The productivity gains are insane to have just 1 layout/navigation for all platforms, and easily worth any tradeoffs for missing features. If you need so many custom renderers, you are missing features in the basic Forms controls / core. Perhaps it could help to post an idea in the Forms evulution area?

    Hey there @rogihee

    I could go on and on about the shortcomings of Forms. Note that it has good use cases. LOB app, forms over data apps and those are really the bread and butter of XF.

    I remember back in the days when Miguel de Icaza told in a podcast (was it dotnetrocks ?) about the use case of XF... Proof of concept or really simple use case. And he was right then and, to my experience, still is. Even if his speech has changed a bit... And I can get it. To Microsoft, Xamarin.Forms can push the use of Windows as a be all end all platform to build for mobile, even without having a proper mobile platform itself. It's the last resort for Microsoft in the Mobile space, at least for the short term!

    But building for XF means learning for an abstract platform... Like a third phone (or a forth if you count Windows Phone) it's not iOS and not Android... It's XF with it's own paradigms! The problem with this is that the lifecycle of stuff in Android nor iOS (activities) aren't fully represented, the same goes for iOS.

    I prefer to have an expertise in a valuable platform with a large exposure (iOS/Android) then on a very narrow... And shallow one, XF! It's personal stuff! True that if your team comes from Desktop Dev, the move to Forms is like almost the only one without a HUGE learning curve. Note that, as soon as the app needs something from the native platform, it will haunt them with vengeance!

    Some stuff are way cool in XF. XAML rocks, MVVM in a box... Name it! But in my case, we do a fairly intensive use of the map (draw on it, calculate distances and showing custom stuff on it...) no way can Forms.Maps can do it. Plus, we have to wait to use what Google develop until Forms.Maps uses it... Always trailing.

    I thought that I was ok with a custom renderer, but in the end I was not able to easily take advantage of the underlying platform, so better go with Xamarin.Android and Xamarin.iOS.

  • GuyProvostGuyProvost CAMember ✭✭✭

    @TonyD said:
    @GuyProvost how long did it take you to go from Forms to Xamarin.iOS? We've also reached the point where nearly everything is on custom renderers because of perf issues/bugs with Forms, so our codebase now looks like Frankenstein.

    Hey there!

    The work is still in progress. I hear your pain comparing the code to Frankenstein. I feel your pain! We can at least use large part of our PCL project, we are rebuilding the UI in iOS. We guess that it will take about 25% - 35% of the time we invested in the Forms Project.

    The workflow is also more fluid. Working the Ui in XCode helps a lot! Sure, we need to now have a team that understands iOS and Android paradigms, but it's more searchable in Google then XF issues!

  • TonyDTonyD USMember ✭✭✭

    @rogihee the main reason has been Android performance for us, not missing features. We've had perf bugs open against the XF team for a year but we have seen zero improvements on their end, even though they've repeatedly promised they were working on it and it was imminent. If you use XF on Android, it generates a ton of useless viewgroups/views that hog down the resources.

    All of our list view cells are rendered with custom renderers. We have a Tinder-like swipe that is also rendered in custom renderers. Everything started as pure XF. Then we moved to custom/absolute layouts. Then we started having custom renderers for parts of the page. Then custom renderers for the majority of the page. Now we want to move everything out of XF but our code is in a weird XF/native/custom renderer state so it's a daunting task. Incidentally our UI render times went from 1,000ms+ to 300ms. XF is OK with one dialog and a handful or labels and buttons.

    Another reason are obvious missing features (e.g. XF Frame had its Radius hardcoded to 5 on Android up until a couple months ago), and bugs.

    @rogihee said:
    If you need so many custom renderers, you are missing features in the basic Forms controls / core. Perhaps it could help to post an idea in the Forms evulution area?

    Maybe but the turn-around time on things like that has been really slow. I think they typically take several months to go from 2.3.x to 2.3.(x+1) so it's not worth waiting.

  • MarkZhukovskyMarkZhukovsky USMember ✭✭
    Is anyone able to do this successfully?

    Set a Detail page = NavigationPage(TabbedPage), where TabbedPage just has one child; a ContentPage with Content set to a StackLayout with a green background (you can pick your favorite color), and have that StackLayout fill the whole ContentPage?

    UWP and Android; no problem...but iOS, can't get it to fully expand (will end up with margin on both right and bottom sides and am unable to fix).

    Am I alone?
  • batmacibatmaci DEMember ✭✭✭✭
    edited April 10

    It promises some enhancement on start up but I am not seeing any big improvement on my app. Can anybody confirm start up performance improvement?

  • batmacibatmaci DEMember ✭✭✭✭

    @NMackay said:
    In XAML you'd do something like this

                <Grid.Padding>
                        <OnPlatform x:TypeArguments="Thickness">
                          <On Platform="iOS">10,5,10,5</On>
                          <On Platform="Android,WinPhone">5,5,5,5</On>
                        </OnPlatform>
                      </Grid.Padding>
    

    @NMackay i tried suggestion in the local resource as below but unfortunately it doesnt work form. Instead of Font as typearguments I tried x:Double as well.

    <Setter Property="FontSize"  >
                        <Setter.Value>
                            <OnIdiom x:TypeArguments="Font">
                                <OnIdiom.Phone>10</OnIdiom.Phone>
                                <OnIdiom.Tablet>15</OnIdiom.Tablet>
                                <OnIdiom.Desktop>5</OnIdiom.Desktop>
                            </OnIdiom>
                        </Setter.Value>
                    </Setter>
    
  • ChaseFlorellChaseFlorell CAInsider, University mod

    @DavidOrtinau your release notes link actually goes to Nuget on the blog post
    https://blog.xamarin.com/announcing-xamarin-forms-stable-release-2-3-4/

  • NMackayNMackay GBInsider, University ✭✭✭✭✭

    2.3.4 has been pushed and actually allows us to have a stable UWP client.

    UWP is and has been unusable. Beta testing will be fun.

  • BrightLeeBrightLee KRMember ✭✭✭

    @DavidOrtinau

    Can you answer my previous question?

    How come 'subclassing Listview' makes different behavior?

    public class MyListView : ListView
    {
    //nothing
    }

    This MyListView's 'tap status bar to scroll top' feature is not working. (XF/iOS)

  • BrightLeeBrightLee KRMember ✭✭✭

    @DavidOrtinau

    Hi David.
    Fortunately, It was my mistake when I use with PulltoRefresh together.
    And it's also OK to use PullToRefresh.

    My mistake.
    I'm sorry.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭
    edited April 18

    Before I log this on Bugzilla, does anyone else see this same issue, or see a flaw in what I'm doing?

    KeyValuePair returns null under new OnPlatform syntax

    As of XF 2.3.4 the OnPlatform syntax has changed.

    This resource lives in my App.xaml to provide platform-specific paths via a FileHelper DependencyService.
    Before:

                <OnPlatform x:Key="LocalStoragePath"
                            x:TypeArguments="x:String"
                            Android="/sdcard"
                            WinPhone="D:\"
                            iOS="" />
    

    After:

                <OnPlatform x:Key="LocalStoragePath"
                            x:TypeArguments="x:String">
                    <On Platform="Android"
                        Value="/sdcard" />
                    <On Platform="WinPhone"
                        Value="D:\" />
                    <On Platform="iOS"
                        Value="" />
                </OnPlatform>
    

    DependencyService C# (droid project)

            public override string GetPublicStorage()
            {
                KeyValuePair<string, object> kvp = Application.Current.Resources.FirstOrDefault(
                    r => r.Key == "LocalStoragePath");
                OnPlatform<string> test = kvp.Value as OnPlatform<string>;
                return test.Android;
            }
    

    When using the new syntax the return is null.
    When using the old syntax the return is "/sdcard" as defined in the xaml resource.

    Update

    Using the new syntax also seems to break all my style definitions and resources for things like font definitions and sizes.

    Old works:

                <OnPlatform x:Key="HeaderFont"
                            x:TypeArguments="Font"
                            Android="Large"
                            WinPhone="Large"
                            iOS="Large" />
                <OnPlatform x:Key="HeaderFontSize"
                            x:TypeArguments="x:Double"
                            Android="60.0"
                            WinPhone="60.0"
                            iOS="64.0" />
    

    New throws exception when the view tries to display:

                <OnPlatform x:Key="HeaderFont"
                            x:TypeArguments="Font">
                    <On Platform="Android"
                        Value="Large" />
                    <On Platform="WinPhone"
                        Value="Large" />
                    <On Platform="iOS"
                        Value="Large" />
                </OnPlatform>
    
                <OnPlatform x:Key="HeaderFontSize"
                            x:TypeArguments="x:Double">
                    <On Platform="Android"
                        Value="60.0" />
                    <On Platform="WinPhone"
                        Value="60.0" />
                    <On Platform="iOS"
                        Value="64.0" />
                </OnPlatform>
    

    Used in DataTemplate. Same template with old syntax works. Changing only the XAML for the OnPlatform crashes when the view is displayed.

                        <controls:BindableWrapLayout.ItemTemplate>
                            <DataTemplate>
                                <Grid HeightRequest="80"
                                      WidthRequest="210"
                                      BackgroundColor="{StaticResource BlueTextColor}"
                                      IsVisible="{Binding IsEnabled}">
    
    <!-- Snip for brevity -->
    
                                    <Label HorizontalOptions="CenterAndExpand"
                                           VerticalOptions="CenterAndExpand"
                                           HorizontalTextAlignment="Center"
                                           VerticalTextAlignment="Center"
                                           BackgroundColor="Transparent"
                                           FontAttributes="Bold"
                                           Text="{Binding FriendlyName,
                                                          Mode=OneWay}"
                                           TextColor="{StaticResource TagForegroundColor}"
                                           Style="{StaticResource LabelStyleMed}" />
    
                                </Grid>
                            </DataTemplate>
                        </controls:BindableWrapLayout.ItemTemplate>
    

    Again, the only difference here is which group of XAML I block-comment.

Sign In or Register to comment.