locked
Xamarin.Forms 2.3.3.193 RRS feed

  • Question

  • User173875 posted

    Important notes

    • Xamarin.Forms 2.3.3 depends on a Xamarin installation of Cycle 8. Users upgrading from Xamarin.Forms 2.3.2 (or earlier) will experience numerous compile errors if they attempt to build without first upgrading their Xamarin installation.
    • When upgrading Xamarin.Forms take care not to simply "update all" as that will update the Xamarin.Android.Support packages to an incompatible version. More info here.
    • In 2.3.3 we are deprecating Classic support (More info here).

    Breaking changes

    • [UWP] TabbedPage ContentPresenter is now of type FormsPresenter instead of TabbedPagePresenter. This is an internal change only that will only affect users explicitly targeting TabbedPagePresenter in the UWP project.

    2.3.3.193

    Nuget package here.

    Release Notes

    Nuspec change to Android dependencies. When targeting framework 7.0 or greater you many use Android support libraries with API 23 or greater, and Maps with API 29 or greater. No other changes.

    2.3.3.180

    Nuget package here.

    Release Notes

    Add authenticode signing. No other changes.

    2.3.3 sr1

    Nuget package here.

    Bug Fixes

    • 47707 - "47707 – Page.Toolbar is covering page.content with XF.UWP on Windows 10 phone" (PR)
    • 47295 - "[UWP] Toolbar is Clipped When Using a NavigationPage" (PR)
    • 47950 - "2.3.3 Regression: XAML compilation fails with behavior property and StaticResource" (PR)
    • 47971 - "XF UWP ListView Items no longer display" (PR)
    • 48105 - "Xamarin.Forms.Theme ResourceDictionary MergedWith fails in current build" (PR)
    • 48158 - "Hidden controls become transparent, static property does not bind" (PR)
    • 48242 - "Binding to constants not working any more in Xamarin Forms 2.3.3" (PR)
    • 48554 - "Bound static property does not call setter in custom view" (PR)
    • 48726 - "[UWP] Toolbar Covering Page Content" (PR)
    • [XamlC] assigned derived type to generic BP (PR)
    • [Xaml] support non-int enums (PR)

    2.3.3 stable

    Nuget package here.

    Bug Fixes

    • 46195 - "Navigation Stack Errors in Xamarin.Forms.2.3.3.163-pre3" (PR)

    2.3.3-pre4

    Nuget package here.

    Bug Fixes

    • 44338 - "Displaying context action causes ArgumentNullException when another item's context actions are already displayed on iOS10." (PR)
    • "[Win] Toolbar placement works with initial value" (PR)
    • "[Android] SoftInputMode works with initial value" (PR)

    2.3.3-pre3

    Nuget package here.

    Bug Fixes

    • 44129 - "[Forms Android] Removing and adding items to TabbedPage BindingContext crashes the app when VM uses MvvmLight property Set()-method" (PR)
    • 44166 - "41166 - Fix MasterDetailPage/NavigationPage leaks on iPad" (PR)
    • 44596 - "Grey/Blank Screen when switching MainPage to MasterDetail with TabbedPage" (PR)
    • 45010 - "[2.3.3] 45010 – Forms Sample "WorkingWithListview" throw exception with WinPhone8.1" (PR)
    • 44166 - "MasterDetailPage instances do not get disposed upon GC; instance accumulation crashes app with OOM error using Forms 2.3.2.118-pre1 and AppCompat" (PR)
    • Don't unsubscribe/resubscribe the listener to the same INPC (PR)
    • 44886 - "UWP Listview ItemSelected event triggered twice for each selection" (PR)
    • [iOS] Fixes KVO native binding (PR)
    • Make CreateNativeControl virtual instead of abstract (PR)
    • 43993 - "iOS: ListView size does not return to normal after keyboard disappears" ([PR](https://github.com/xamarin/Xamarin.Forms/pull/333 ))
    • 39768 - "PanGestureRecognizer sometimes won't fire completed event when dragging very slowly" (PR)
    • 42602 - "Custom BoxView Renderer Does Not Render All Its Children Elements" (PR)
    • [Xaml] Xaml native views and bindings for WP8.1 (PR)
    • [XamlC] Compiled converters (PR)
    • [Xaml] allow compatible arguments for x:Factory (PR)
    • [XAMLC] specify type and default value for native bindings (PR)
    • [2.3.3-pre2] [XamlC] supports enum and consts in x:Static (PR)
    • Reuse Handler when invoking on main thread (PR)

    2.3.3-pre2

    Nuget package here.

    New Features

    Support native view declaration in Xaml, and native Bindings

    The following Xaml is valid, and works as expected:

    <?xml version="1.0" encoding="UTF-8"?> <ContentPage xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" xmlns:ios="clr-namespace:UIKit;assembly=Xamarin.iOS;targetPlatform=iOS" xmlns:androidWidget="clr-namespace:Android.Widget;assembly=Mono.Android;targetPlatform=Android" xmlns:formsandroid="clr-namespace:Xamarin.Forms;assembly=Xamarin.Forms.Platform.Android;targetPlatform=Android" xmlns:win="clr-namespace:Windows.UI.Xaml.Controls;assembly=Windows, Version=255.255.255.255, Culture=neutral, PublicKeyToken=null, ContentType=WindowsRuntime;targetPlatform=Windows" x:Class="Xamarin.Forms.Controls.XamlNativeViews"> <ContentPage.Content> <ios:UILabel Text="{Binding NativeText}" View.HorizontalOptions="Start"/> <androidWidget:TextView Text="{Binding NativeText}" x:Arguments="{x:Static formsandroid:Forms.Context}" /> <win:TextBlock Text="Foo"/> </ContentPage.Content> </ContentPage>

    • native views are automagically wrapped into the appropriate wrapper
    • xmlns defined on a non-matching targetPlatform (see TargetPlatform enumeration) are ignored
    • you can bind to property of native views. A proxy is created on the fly for supporting 2-Way bindings if possible. If the native property doesn't implements INPC, or support Observable (on iOS), or is a DependencyProperty (on UWP), you can pass an UpdateSourceEventName parameter to the binding expression.
    • if you set, or bind to, attached BindableProperty to a native view that will be wrapped in a X.F.View, those property values and binding are transferred to the wrapper. See HorizontalOptions in the sample above.

    Platform Specifics

    Introducing Platform Specifics! Features or behaviors that apply to one platform only can now be implemented without requiring custom renderers. These new features/behaviors can then be accessed easily via a fluent code API or XAML.

    Vendors can easily add their own Platform Specifics by attaching Effects to them (see 63a924d and 1f9482e for complete example).

    This feature implements the framework that enables the new API and also includes several examples of platform specific features, which can be previewed using the Platform Specifics gallery page:

    • Blur support for any VisualElement on iOS
    • Translucent navigation bar on iOS
    • Partially collapsed navigation bar (with icons!) on MasterDetailPage on Windows
    • Toolbar placement options on Windows
    • AdjustResize/AdjustPan on Android (known issue: AdjustResize disables status bar color)

    Bug Fixes

    • 32733 - "32733 – Switching Activity crash in 1.4.4.6392" (PR)
    • 35132 - "35132 – Pages are not collected when using a Navigationpage"
    • 39768 - "PanGestureRecognizer sometimes won't fire completed event when dragging very slowly" (PR)
    • 39908 - "Back button hit quickly results in jumbled pages" (PR)
    • 41463 - "CarouselView Crashes with "Sequence Does not Contain a Matching Element""
    • 42061 - "App crashes when registering an app link entry with invalid thumbnail url" (PR)
    • 42112 - "42112 - CarouselView throws error on Android while moving"
    • 42341 - "Page not removed from NavigationStack when hit Back quickly on iOS" (PR)
    • 42519 - "Text Truncation in UWP"
    • 42697 - "Slow swipe - System.InvalidOperationException: Sequence contains more than one element [CarouselView]"
    • 43230 - "DisplayAlert returns unexpected value when Escape key hit on UWP" (PR)
    • 43328 - "DisplayActionSheet() double-tap NullReferenceException crash Win8.1" (PR)
    • 43354 - "Button IsEnabled binding is position dependent" (PR)
    • 43450 - "Faulty syntax of Grid.RowDefinition wasn't caught with XamlC"
    • 43516 - "[UWP] Changing FontAttribute on a label to NONE changes font size as well" (PR)
    • 43530 - "[Android] Resuming app throws IllegalStateException from fragment manager"
    • 43726 - "Setting TabbedPage.ItemsSource to Null Causes Crash" (PR)
    • 43774 - "Appearing does not trigger for the first time for Tabpages in Android" (PR)
    • 43892 - "Xamarin.Forms.TabbedPage with FormsAppCompatActivity OnAppearing Troubles"
    • 44056 - "Picker Focused/Unfocused events not fired on iOS 10 preview" (PR)

    Other fixes

    • iOS10 fixes

    2.3.3-pre1

    Only internal. There were no public artifacts/nuget packages for pre1.

    Friday, September 16, 2016 5:03 PM

All replies

  • User2148 posted

    @BryanHunterXam does Native view declaration work only on Shared Projects?

    Friday, September 16, 2016 5:25 PM
  • User1004 posted

    @AlessandroCaliaro no, it works in PCL too, but only with XamlC off

    Friday, September 16, 2016 6:28 PM
  • User1004 posted

    @NMackay the OnIdiom<> in StaticResource with XamlC is fixed in this release

    Friday, September 16, 2016 6:33 PM
  • User2148 posted

    @StephaneDelcroix are you saying that we have Native Controls in PCL? Do we have it also in Code or only in XAML?

    Friday, September 16, 2016 6:43 PM
  • User1004 posted

    @AllessandroCaliaro: that's what I'm saying, yes. You can declare native controls in PCL, and native bindings to them. As the xaml is inflated at runtime, all the native stuffs are resolved by that time.

    Do not try your luck and add x:Name to Native Views in a PCL. That will create a variable of the native type and will cause a compilation error. The Force is strong, but not that strong.

    Friday, September 16, 2016 6:48 PM
  • User181025 posted

    @BryanHunterXam Thanks for another update.

    • Can you create a developer guide for platform specifics for those who won't see this announcement?
    • Can you create a developer guide explaining conventions you use for unit / ui testing? I see a lot of classes named Bugzilla[BugID] that derive from ContentPage. Are these for playground while fixing bugs? What are those gallery pages? I noticed most people submit PRs without tests which makes me believe regression bugs are inevitable. An end-to-end walkthorough would be great.
    • Also, I'd love to see feature requests being upvoted / discussed by the community. I know there is a UserVoice page somewhere that nobody looks at. Can you permanently pin it to the forum for everybody to see and use?
    • Any way these bugs can be looked at? 43108, 43867, 43706, 42651
    Friday, September 16, 2016 7:04 PM
  • User140202 posted

    @AdrianKnight: I have a PR up for 43108.

    Friday, September 16, 2016 11:02 PM
  • User258 posted

    Love the new features.

    Saturday, September 17, 2016 7:03 AM
  • User2148 posted

    @StephaneDelcroix can I use Native Controls in Code (C#) in PCL?

    Saturday, September 17, 2016 7:44 AM
  • User181025 posted

    @BryanHunterXam

    Also, I saw that you made changes to CarouselView. Shouldn't those fixes be listed on https://forums.xamarin.com/discussion/69120/carouselview-2-3-0-pre2/p1 and require a nuget update?

    Sunday, September 18, 2016 3:36 PM
  • User76049 posted

    @StephaneDelcroix

    Thanks for sorting that and letting me know.

    If you use platform specific native view feature will XamlC always be switched of or is it for this beta? I'm just trying to get my head around if we can use this feature in complex views that rely on XamlC for performance.

    Monday, September 19, 2016 7:49 AM
  • User1004 posted

    @NMackay XamlC won't be switched off. But you have to switch it off for views using native views (you can turn it on or off at the Class level)

    Monday, September 19, 2016 7:50 AM
  • User2148 posted

    @AlessandroCaliaro said: @StephaneDelcroix can I use Native Controls in Code (C#) in PCL?

    An answer?

    Monday, September 19, 2016 7:54 AM
  • User57869 posted

    @BryanHunterXam said: xmlns:win="clr-namespace:Windows.UI.Xaml.Controls;assembly=Windows, ..., ContentType=WindowsRuntime;targetPlatform=Windows"

    @StephaneDelcroix , how can you differentiate

    • Windows Phone 8.0 Silverlight
    • Windows RT
    • Windows UWP

    @TheRealJasonSmith said long ago, that OnPlatform doesn't work for those cases and that you think about a better solution. Have you found one? - Or will Silverlight just be deprecated and RT assumed to be the same as UWP?

    Monday, September 19, 2016 8:00 AM
  • User76049 posted

    @StephaneDelcroix

    Just for clarity, if I have a tabbed page/view with 5 tabs and say I wanted to surface a native control in tab 5 I'd have to disable XamlC for the entire view?

    I'm guessing the ability to change the toolbar will be popular so can the toolbar features be used with XamlC without exposing native views or does using any platform specific feature disable XamlC?

    I'm just trying to think ahead where we can use these features.....which are great btw!

    Monday, September 19, 2016 8:00 AM
  • User1004 posted

    @NMackay if you define your tabbed page and all the content in a single xaml file, then yes. If you can isolate the the view containing the native part to a single file, only disable XamlC on that one.

    We are working on making this feature works with XamlC on, but we don't know yet when it'll be released

    Monday, September 19, 2016 8:11 AM
  • User76049 posted

    @StephaneDelcroix

    Thanks for clarifying. Once this feature is working sweetly it will be really popular.

    Monday, September 19, 2016 8:14 AM
  • User1004 posted

    @MichaelRumpler

    It's quite easy: WP8 and WinRT are the ones no one uses, UWP is the other :grin: :grin: :grin:

    More seriously: just like OnPlatform, this feature uses the TargetPaltform which doesn't differentiate between the different windows flavors :(

    Monday, September 19, 2016 8:15 AM
  • User1004 posted

    @AlessandroCaliaro : no, that would not compile.

    Monday, September 19, 2016 8:22 AM
  • User2148 posted

    @StephaneDelcroix thanks. Maybe in an other release??

    Monday, September 19, 2016 8:25 AM
  • User1004 posted

    @AlessandroCaliaro: no, never

    Monday, September 19, 2016 8:31 AM
  • User1004 posted

    @NMackay sorry for the confusion, but the fix for the issue about resources/onplatform/xamlc is not included in this release. that'll be for the next one

    Monday, September 19, 2016 9:27 AM
  • User7593 posted

    please checkout this issue: https://github.com/luberda-molinet/FFImageLoading/issues/313

    Xamarin.Forms 2.3.3.152-pre2 Could not load type 'FFImageLoading.Forms.Droid.CachedImageRenderer'

    QUOTE: "I can be wrong but this seems to be a problem with every library that implement a custom Renderer and not with Prism. The latest (2.3.3.152-pre2) XF exposes an abstract CreateNativeControl that needs to be implemented on the renderers and all previous UI libraries stopped working for me."

    Monday, September 19, 2016 11:06 AM
  • User2148 posted

    @StephaneDelcroix said: @AlessandroCaliaro : no, that would not compile.

    Sorry for my question but usually I don't use xaml. Now native controls can exist in Pcl using xaml; can I access these native controls in code behind? How? @StephaneDelcroix ?

    Monday, September 19, 2016 11:11 AM
  • User196244 posted

    Why is XF not sticking to semantic versioning? 2.3.3-pre2 is introducing new features? How is that possible? I'd prefer a 2.3.3-whatever concentrating on fixing the various and annoying reported bugs under iOS 10 (crashes).

    Monday, September 19, 2016 3:52 PM
  • User81057 posted

    using x:static for an enumeration value in a datatrigger no longer works in 2.3.3 with XamlC (works fine in 2.3.2.127), e.g.

    <Label VerticalOptions="Center" HorizontalOptions="Center">
        <Label.Triggers>
          <DataTrigger TargetType="Label"
                       Binding="{Binding EnumTestValue}"
                       Value="{x:Static local:EnumTest.One}">
            <Setter Property="Text" Value="Hello1" />
          </DataTrigger>
          <DataTrigger TargetType="Label"
                       Binding="{Binding EnumTestValue}"
                       Value="{x:Static local:EnumTest.Two}">
            <Setter Property="Text" Value="Hello2" />
          </DataTrigger>
        </Label.Triggers>
      </Label>
    

    results in MissingFieldException

    Monday, September 19, 2016 6:40 PM
  • User1004 posted

    @DavidDunscombe Thanks for spotting this. See https://github.com/xamarin/Xamarin.Forms/pull/369 for an explanation and a fix that should be included in 1.3.3 final.

    In the meantime, you can disable XamlC for that View and everything should be back to working.

    Wednesday, September 21, 2016 11:34 AM
  • User2773 posted

    FFImageLoading.Forms.Droid/CachedImageRenderer.cs(15,15): Error CS0534: FFImageLoading.Forms.Droid.CachedImageRenderer' does not implement inherited abstract memberXamarin.Forms.Platform.Android.ViewRenderer.CreateNativeControl()' (CS0534) (FFImageLoading.Forms.Droid)

    It breaks compatibility with all custom renderers. IMO, CreateNativeControl method should be defined as virtual, not abstract.

    Wednesday, September 21, 2016 3:24 PM
  • User125713 posted

    @BryanHunterXam when can we expect the fix for XF Android perf? https://bugzilla.xamarin.com/show_bug.cgi?id=42335

    Can you please commit to an ETA or otherwise update the bug if your team doesn't believe it is able to improve perf?

    Thursday, September 22, 2016 9:15 PM
  • User113114 posted

    @TonyD said: @BryanHunterXam when can we expect the fix for XF Android perf? https://bugzilla.xamarin.com/show_bug.cgi?id=42335

    Can you please commit to an ETA or otherwise update the bug if your team doesn't believe it is able to improve perf?

    , + 1

    Friday, September 23, 2016 2:49 PM
  • User66766 posted

    @TonyD said: @BryanHunterXam when can we expect the fix for XF Android perf? https://bugzilla.xamarin.com/show_bug.cgi?id=42335

    Can you please commit to an ETA or otherwise update the bug if your team doesn't believe it is able to improve perf?

    +1 @BryanHunterXam

    Friday, September 23, 2016 3:12 PM
  • User44073 posted

    @TonyD said: @BryanHunterXam when can we expect the fix for XF Android perf? https://bugzilla.xamarin.com/show_bug.cgi?id=42335

    Can you please commit to an ETA or otherwise update the bug if your team doesn't believe it is able to improve perf?

    +1 @BryanHunterXam

    Friday, September 23, 2016 3:21 PM
  • User84530 posted

    @TonyD said: @BryanHunterXam when can we expect the fix for XF Android perf? https://bugzilla.xamarin.com/show_bug.cgi?id=42335

    Can you please commit to an ETA or otherwise update the bug if your team doesn't believe it is able to improve perf? +1 @BryanHunterXam

    Sunday, September 25, 2016 12:08 AM
  • User65389 posted

    @TonyD said: @BryanHunterXam when can we expect the fix for XF Android perf? https://bugzilla.xamarin.com/show_bug.cgi?id=42335

    Can you please commit to an ETA or otherwise update the bug if your team doesn't believe it is able to improve perf?

    , + 2

    Sunday, September 25, 2016 3:01 PM
  • User65827 posted

    @TonyD said: @BryanHunterXam when can we expect the fix for XF Android perf? https://bugzilla.xamarin.com/show_bug.cgi?id=42335

    Can you please commit to an ETA or otherwise update the bug if your team doesn't believe it is able to improve perf? +1 @BryanHunterXam

    Sunday, September 25, 2016 3:11 PM
  • User6753 posted

    @TonyD said: @BryanHunterXam when can we expect the fix for XF Android perf? https://bugzilla.xamarin.com/show_bug.cgi?id=42335

    Can you please commit to an ETA or otherwise update the bug if your team doesn't believe it is able to improve perf?

    This +1 !

    Sunday, September 25, 2016 8:44 PM
  • User193082 posted

    Will this issue be resolved anytime soon?

    https://bugzilla.xamarin.com/show_bug.cgi?id=41426

    Or anyone who knows a workaround for this? :tired_face:

    Monday, September 26, 2016 2:29 AM
  • User67129 posted

    @TonyD said: @BryanHunterXam when can we expect the fix for XF Android perf? https://bugzilla.xamarin.com/show_bug.cgi?id=42335

    Can you please commit to an ETA or otherwise update the bug if your team doesn't believe it is able to improve perf?

    +1

    Monday, September 26, 2016 7:36 AM
  • User130379 posted

    @TonyD said: @BryanHunterXam when can we expect the fix for XF Android perf? https://bugzilla.xamarin.com/show_bug.cgi?id=42335

    Can you please commit to an ETA or otherwise update the bug if your team doesn't believe it is able to improve perf?

    I really like all those +1s so will add one for myself

    Monday, September 26, 2016 8:54 AM
  • User78605 posted

    I get the following error with the latest Xamarin.Forms and CarouselView pre packages:

    System.TypeLoadException: Could not load type 'Xamarin.Forms.Platform.CarouselViewRenderer' from assembly 'Xamarin.Forms.CarouselView, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
    

    Is someone else seeing this as well and are there any workarounds? The app works on UWP ... couldn't test iOS yet.

    Monday, September 26, 2016 12:57 PM
  • User218505 posted

    @Thomas.Goerlich said: I get the following error with the latest Xamarin.Forms and CarouselView pre packages:

    System.TypeLoadException: Could not load type 'Xamarin.Forms.Platform.CarouselViewRenderer' from assembly 'Xamarin.Forms.CarouselView, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

    Is someone else seeing this as well and are there any workarounds? The app works on UWP ... couldn't test iOS yet.

    I had the same problem with XF 2.3.3 using carousel. Downgrading solved it.

    Monday, September 26, 2016 1:13 PM
  • User78605 posted

    @Bellju said:

    @Thomas.Goerlich said: I get the following error with the latest Xamarin.Forms and CarouselView pre packages:

    System.TypeLoadException: Could not load type 'Xamarin.Forms.Platform.CarouselViewRenderer' from assembly 'Xamarin.Forms.CarouselView, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
    

    Is someone else seeing this as well and are there any workarounds? The app works on UWP ... couldn't test iOS yet.

    I had the same problem with XF 2.3.3 using carousel. Downgrading solved it.

    Thanks, i tested that as well but that is not what i had in mind :wink: i was hoping that i could use the latest pre AND the carousel view ... especially because there should have been bugfixes for the carousel view in the latest version.

    Monday, September 26, 2016 1:39 PM
  • User89714 posted

    @BryanHunterXam @StephaneDelcroix - Are there any plans to add support for IsPullToRefreshEnabled on UWP? If so, is there any indication of when this might happen?

    Monday, September 26, 2016 1:56 PM
  • User21224 posted

    This pre2 release breaks F# compatibility in a severe way:

    error FS0443: This type implements or inherits the same interface at different generic instantiations 'IElementConfiguration' and 'IElementConfiguration'. This is not permitted in this version of F#. [C:\Sandbox\XXX\XXX.Mobile.Core\XXX.Mobile.Core.fsproj]

    Monday, September 26, 2016 1:58 PM
  • User102173 posted

    Why does it take months to develop a flippin' carousel view? You're not inventing a spaceship. We expected Microsoft to fix things - not be the same crap Xamarin was. Sometimes my breakpoints don't get hit in VisualStudio when I'm debugging iOS. Rebuilding iOS is extremely slow compared to Android, and debugging is often not a good experience because the error messages are cryptic.

    Monday, September 26, 2016 2:00 PM
  • User60257 posted

    Tip for all those developers getting p1ssed off by the hard work the Forms team are doing not satisfying your exact requirements - head over to https://github.com/xamarin/Xamarin.Forms, make the fix and raise a pull request. That's the beauty of open source.

    Tuesday, September 27, 2016 12:23 AM
  • User130379 posted

    @JimBennett said: Tip for all those developers getting p1ssed off by the hard work the Forms team are doing not satisfying your exact requirements - head over to https://github.com/xamarin/Xamarin.Forms, make the fix and raise a pull request. That's the beauty of open source.

    Performance is not "your exact requirements". It's everyone basic requirement. Xamarin applications get trashed in android store reviews. That's a deal breaker for any developer. You also forgot that Xamarin transitioned not so long ago and those forums are still filled with people who paid quite a bunch of $$$ for using it.

    Tuesday, September 27, 2016 6:38 AM
  • User60257 posted

    @WiktorKoncki - not true - plenty of Xamarin applications get fantastic reviews in the Google Play store. If your app is too slow then maybe you should have evaluated Forms for your requirements before using it. I also used to pay a lot for Xamarin so did not forget this point, but I made sure the tools fit my purpose. Xamarin Forms has in the past been pitched at scenarios where flashy UI is not needed, and for those tasks it works very well. If you want more control then don't use forms.

    As for 'performance being everyones basic requirement' - Forms gives you a certain level of performance. Native Android can give you better performance but you can still write really slow apps. These are tools, they have their upsides and their downsides, you can write fast Xamarin Forms apps and slow native apps.

    If you've written your app well and you are getting bad reviews due to performance then it should be simple to replace your UI layer with native for your Android app.

    Tuesday, September 27, 2016 6:49 AM
  • User65389 posted

    @JimBennett
    We don't want to develop Xamarin.Forms, we want to develop WITH Xamarin.Forms. It's not a playground for us (it seems as it is just this for some users), it should be a stable platform for stable app's (what is not true SINCE YEARS now)!

    Tuesday, September 27, 2016 8:03 AM
  • User76049 posted

    @JimBennett said: Tip for all those developers getting p1ssed off by the hard work the Forms team are doing not satisfying your exact requirements - head over to https://github.com/xamarin/Xamarin.Forms, make the fix and raise a pull request. That's the beauty of open source.

    That's a bit harsh Jim, we pay for multiple MLS licences and are an enterprise customer so expect a certain level of stability from the platform. As far as I'm aware, they are working on trying to improve Android performance and I'm well aware of how hard the team works (they deserve more resource allocated IMO), I think a lot of this frustration is down to a lack of communication.

    Tuesday, September 27, 2016 8:43 AM
  • User130379 posted

    @JimBennett said: @WiktorKoncki - not true - plenty of Xamarin applications get fantastic reviews in the Google Play store.

    I will respond with a joke: Programmer goes to a doctor and says: - Doctor, my liver hurts. - Strange - responded the doctor - it works for me.

    Tuesday, September 27, 2016 9:22 AM
  • User89714 posted

    @BryanHunterXam @StephaneDelcroix - I have a pile of outstanding bugs in bugzilla. I've listed just 7 below. For those 7, is there any chance of getting the two CONF ones fixed, the one with a PR fixed, and the other four at least triaged please.

    Of the ones needing triage, 44773 is the most important. There are various issues around ListViewCachingStrategy, so at least having RetainElement work as expected across the platforms would provide a base from which to start then investigating bugs relating to RecycleElement.

    44773 - ListViewCachingStrategy.RetainElement on UWP is constructing multiple instances of cells as the user scrolls up and down (NEW - repro code provided) 44738 - MinimumHeightRequest ignored in ListView Header and Footer templates (NEW - repro code provided + Adrian Knight has done a PR at https://github.com/xamarin/Xamarin.Forms/pull/386) 36670 - ScrollView on WinPhone 8.1 RT calculates height incorrectly if word wrap used in nested views (CONF) 40817 - AutomationId may only be set one time exception (CONF) 43716 - Height = GridLength.Auto in RowDefinition does not handle content of word-wrapped Label on UWP and WinRT (NEW - repro code provided) 44680 - On UWP and WinRT 8.1, Image with IsVisible=false obscures what is beneath it (NEW - repro code provided) 43832 - Using a ListView with a DataTemplateSelector and RecycleElement results in wrong behavior on cells (NEW)

    Tuesday, September 27, 2016 11:01 PM
  • User181025 posted

    @JohnHardman

    As you can see, my PR was rejected. If fixing a bug creates a breaking change for apps that worked around a bug, then what we are saying is it is OK to not fix bugs even though you know you can. I'm more curious now to see how XF team will release a functioning MinimumWidth/HeightRequest.

    Maybe, I'm not thinking this straight, but I see several ways to address this issue:

    • Don't worry about breaking changes (Developers will need to fix their code if they update to a new version of XF. Not fun for developers)
    • Use conditionals in XF source code based on assembly versioning (Increases clutter, potentially maintenance hell. Not fun for XF team)
    • Release two versions of XF each release cycle so that one includes breaking changes (Gives enough time to devs while they pull in non-breaking changes.)

    As frustrating as it sounds, I'd be comfortable with the first option.

    Wednesday, September 28, 2016 1:12 AM
  • User311 posted

    @AdrianKnight I completely agree, breaking changes are fine as long as it improves the code, fixes bugs etc. They must be well documented, so I wouldn't add the PR in a point release but in this case in a 2.4 branch, that could be pre-released so users can check their app.

    Have you emailed Jason Smith, or maybe start a discussion on the Forms dev list about breaking changes? Might be a bit better suited than the forum.

    Thanks for all your PR's BTW!

    Wednesday, September 28, 2016 5:17 AM
  • User181025 posted

    @rogihee No, never got involved in a discussion about breaking changes. The only communication I had was in that PR. I'm hoping we can see a discussion there for the time being. I think it needs to be re-opened and sit in the queue until perhaps 2.4-pre1.

    Welcome.

    Wednesday, September 28, 2016 5:32 AM
  • User130379 posted

    @AdrianKnight One solution would be also to follow sane versioning model where minor releases are not introducing breaking changes. It should be safe to upgrade from 2.2.1 to 2.2.2 without worrying about breaking changes. We can then introduce breaking changes in 2.3.0. That would make it much safer and cleaner for everybody involved.

    Wednesday, September 28, 2016 7:50 AM
  • User60257 posted

    @AdrianKnight - if it's a breaking change then maybe it'll have to wait for 3.x? I assume they're using SemVer so breaking changes need a major release bump, so maybe they'd prefer to batch up a few breaking changes into one big release.

    @NMackay, @FredyWenger - I know where you are coming from, just trying to offer a counter to the negativity as that seems to be predominately what is appearing on this thread. As I've already said elsewhere I have a hell of a lot of respect for your views on this @FredyWenger as you've dealt with a lot of issues and been very candid with talking about what has caused your problems, I just wanted to pop my head up and offer some positivity.

    Forms is awesome - it allows you to write one app and create native apps on multiple platforms, you can avoid the complexities of the iOS autolayout, have a consistently laid out UI on multiple platforms and can easily drop into native where required. It's not perfect, and every time a new OS is released in iOS and Android they have a lot of work to do to ensure it still works and supports any changes, but what it does it does pretty well, and I know a fair few people who are happy with it in production apps. It has it's limitations and Xamarin have never been shy about mentioning them - it was pushed for prototypes and LOB at the start, now its anything without a flashy UI. The team has done a superb job getting where they have, and it's certainly getting better and better all the time. The teams communication could be better, but sometimes it is hard in a commercial environment as they don't want to give away confidential plans.

    Forms team - keep up the good work!

    Wednesday, September 28, 2016 7:53 AM
  • User1786 posted

    @TonyD said: @BryanHunterXam when can we expect the fix for XF Android perf? https://bugzilla.xamarin.com/show_bug.cgi?id=42335

    Can you please commit to an ETA or otherwise update the bug if your team doesn't believe it is able to improve perf?

    +1

    Wednesday, September 28, 2016 11:47 AM
  • User1786 posted

    Microsoft needs to hire more people for fixing bugs in Xamarin.Forms. Bug fixing is not like developing new features, where the man-month idea is just a myth. Bug fixing is scalable because each bug has a very defined area of intervention, and usually require one programmer assigned to fix each bug. The resource/speed ratio for bug fixing is linear: if you increase the staff by n times, the bug fixing speed is also increased by n.

    Wednesday, September 28, 2016 12:01 PM
  • User181025 posted

    @WiktorKoncki @JimBennett I'm okay with breaking changes waiting till a bigger release. I just don't understand why they would reject a PR because it's breaking. It should stay in the PR queue and NOT be rejected. Maybe @JohnHardman needs to push back on 386.

    Wednesday, September 28, 2016 2:42 PM
  • User89714 posted

    @AdrianKnight - does it somehow break functionality, or does it make unit tests fail that should fail (and hence be re-written)?

    Wednesday, September 28, 2016 3:13 PM
  • User181025 posted

    @JohnHardman At the time I submitted the PR, all unit tests passed. I'm having difficulty running UI Tests due to environment setup issues. Surely, it will break existing functionality when minimum values start working, but it's up to devs to fix their own code. For example, if you were doing calculations based off of Width/HeightRequest of one element to position another element, then these calculations will be incorrect when minimum values come into play because Width/HeightRequest doesn't represent the actual size anymore.

    Another scenario (I'll confirm this):

    You had a button with 30 units of width. Platform renderer returned 33 as default minimum width. XF originally overwrote default values with yours (you wrote UI/Unit tests expecting 30). If you hadn't indicated a width, then you'd get 33 (this is fine).

    Now you should get the maximum of the two (breaking change). If you typed MinimumWidthRequest=44, then you should get 44 (this is fine).

    Again, I'll confirm the above scenario and update this post. In all seriousness, I'd have expected a review of the changes instead of a simple close of the PR.

    Wednesday, September 28, 2016 4:03 PM
  • User89714 posted

    @AdrianKnight - Not one of my classier repro samples, but it does the job ;-)

    Many thanks for your help on this. As you say, it would be good to have useful feedback where a PR is rejected.

    With my old SET/SDT/SDET hat on (which abbreviation to use depends on where you've worked :-) ) ...

    With a default of 33, and neither WidthRequest nor MinimumWidthRequest, I would expect Width to be 33.

    With a default of 33, and a MinimumWidthRequest of 44, I would expect Width to be 44.

    Whilst I was reporting issues around Minimum values, rather than WidthRequest and HeightRequest, with a default of 33 and a WidthRequest of 30, I would expect Width to be 30.

    With a default of 33, a WidthRequest of 44 and a MinimumWidthRequest of 30, I'd expect Width to be 44.

    With a default of 33, a WidthRequest of 30 and a MinimumWidthRequest of 44, I'd hope the renderer wouldn't throw an exception (because renderer exceptions can be a nightmare to investigate) and would hope the property setters wouldn't throw an exception (because Slider used to do so on WinPhone and/or Windows, and it was also a nightmare), but I don't know what I would expect the result to be - perhaps 33 as what the caller specified did not make sense.

    Wednesday, September 28, 2016 4:27 PM
  • User89714 posted

    @BryanHunterXam @StephaneDelcroix - It turns out that 44773 is apparently intentional behavior - it's just NOT what the documentation explicitly says it will do. Can somebody confirm please on UWP, when using ListView with RetainElement, whether it's necessary to implement OnBindingContextChanged.

    If not explicitly using RecycleElement, I wouldn't expect to need to implement OnBindingContextChanged, but if UWP is doing virtualisation even when not explicitly using RecycleElement, does it magically handle changes of BindingContext, or does the user have to implement it even when not using RecycleElement?

    If the user has to implement it, and if I understand OnBindingContextChanged correctly (the documentation is woefully lacking), the idea of having one set of code to work cross-platform for ListView is rather dubious - RetainElement doesn't actually retain an element on UWP, and RecycleElement behaves so differently between platforms (watching the pattern of ViewCell construction on different platforms is somewhat surprising) that it's no wonder there are different issues on different platforms.

    Wednesday, September 28, 2016 7:24 PM
  • User181025 posted

    @JohnHardman I tested all your scenarios. I even found an edge case. See my latest comment here: https://github.com/xamarin/Xamarin.Forms/pull/386

    In my case, Android button renders 88x48 units by default. If you explicitly give it 60 width and 120 minimum width, then GetSizeRequest will create a size request object with 60x55.5 (measures button on 60 width hence the wrapping of the text and increased height) and update minimum to 120 but it does not know what height to give so it gives minimum 55.5 (should be 48). Even if this is fixed, Layout needs to be intelligent and assign the correct size.

    I rewrote GetSizeRequest so that we measure once for request and once for minimum and return the correct SizeRequest object, but this breaks a lot of unit tests. I also worked on Layout and ended up with a lot of if-else conditionals. By default, WidthRequest HeightRequest MinimumWidthRequest and MinimumHeightRequest are set to -1. If the user explicitly sets any to a value, then we are looking at 2^4=16 predicates to understand what the user intends. Maybe there is a better way and I just don't know it.

    That said, you will still get the right width but incorrect height. I don't think most people would run into this issue and even then it's fixable. What's the point of doing 60 width and 120 minimum width? Just remove the first one.

    Still, the changes are an improvement over the current state. All unit tests pass, so I'm not sure what Jason was getting at when he said it would break functionality.

    With a default of 33, a WidthRequest of 30 and a MinimumWidthRequest of 44, I'd hope the renderer wouldn't throw an exception

    In this case, it should render 44 units.

    Feel free to continue the discussion on the GitHub thread. :)

    Thursday, September 29, 2016 4:19 AM
  • User130379 posted

    @AdrianKnight said: I just don't understand why they would reject a PR because it's breaking.

    I actually seen this before in other projects, even big ones like mysql. Unfortunately if you keep bugs for long enough, they become features.

    Thursday, September 29, 2016 6:22 AM
  • User2496 posted

    Hey everyone, just a little feedback.

    Breaking changes is something take serious, we have a lots of enterprise customers and 3rd party libraries that depend on Forms and ABI compatibility, and we don't want to brake everyone. That said we are looking at ways that we can move forward and still don't break people. At the time we are looking at maybe a extra package with the legacy stuff, so one could always opt in.

    We are working on Android performance, we are trying to see where we can shave time on layout , binding system etc.. Take note this is a very complex problem and special making sure we still keep all functionality. We can't give ETA when will it be fixed since this takes a lot of analys and benchmark.... a never ending job of improvement Xamarin Forms performance. But rest assure the team is trying to address this. If you check master you will see a couple of small things getting in.

    It's great to see more involvement of the community, more pr's , bug fixes etc.. Keep it going.

    Thursday, September 29, 2016 9:55 AM
  • User1786 posted

    @rmarinho said:

    Hey everyone, just a little feedback.

    We are working on Android performance, we are trying to see where we can shave time on layout , binding system etc..

    Rui, I don't think the performance issue can be addressed just shaving some time here and there. The problem is architectural. The code doesn't scale, period. Once you reach a certain number of images or elements on screen, the system becomes unusable. GC explicit sweeps become so frequent that you can hardly interact without making everything unresponsive. Even the most basic function of mobile devices, the scrolling of a list, something that the user is used to see always perfectly smooth on browsers, has continuous hiccups. I don't think the issue is XAML, because XAML is conceptually not very different from HTML+CSS. But then why scrolling long web pages with tons of images and elements is always smooth on the browser on the same device, while in Xamarin.Forms (even when compiled) you have continuous hiccups with just a few custom cells with few small images? Something is deeply flawed in the basic architecture of XAML that makes the performances going down quickly as the number of elements on the page increase. Shaving some time here and there will not solve the problem, because the cpu usage grows in a non linear way. The only thing that can solve the problem is changing the current code with something that scales, something that doesn't waste cpu time in doing again and again the same thing for each element. Things like precalculating layouts, pre-rendering, caching, buffering, recycling, singletons and factories, constants and shared elements to avoid allocating, etc. need to be used. If a browser can get 60 fps with HTML, you can do the same with XAML. There are no excuses.

    Thursday, September 29, 2016 1:13 PM
  • User89714 posted

    @rmarinho - Hi Rui. As it relates to virtualisation of ListView, which is a performance matter, I wonder if you could answer the OnBindingContextChanged question I raised above on UWP please?

    Thursday, September 29, 2016 4:31 PM
  • User57869 posted

    @rmarinho said: Breaking changes is something take serious ...

    It's good to see that you take those serious, but fixing a feature which did not work is something different IMHO.

    Yes, the layouts would look different with the fix, but only if users tried (and failed) to use MinimumWidth before and they left it in and worked around it. Making Forms do what it should justifies such a change.

    What's even more important: @AdrianKnight invested a lot of work to write all those PRs - not only this one. His name pops up more often in the list of PRs than any Xamarin employee. If you reject a fix for a bug, then people will be less motivated to do PRs. You'd have to do everything yourself like it was before you open sourced it. And we all know that you lack the time and people to make the great product XF should be.

    Thursday, September 29, 2016 4:47 PM
  • User57869 posted

    I posted this about a month ago:

    Here is a sample from my output window:

    [0:] 11:14:50.770: DocNavigationViewModel.NavigateProperties[197]: Navigated 08-18 11:14:51.702 I/art ( 4427): Explicit concurrent mark sweep GC freed 5041(231KB) AllocSpace objects, 2(348KB) LOS objects, 40% free, 10MB/17MB, paused 448us total 18.938ms 08-18 11:14:51.706 D/Mono ( 4427): GCOLDBRIDGE num-objects 295 numhashentries 47142 sccs size 25747 init 0.00ms df1 148.88ms sort 30.32ms dfs2 396.90ms setup-cb 3.47ms free-data 175.82ms links 181377/181377/2912009/115 dfs passes 228814/207124 08-18 11:14:51.706 D/Mono ( 4427): GC_MINOR: (Nursery full) pause 155.65ms, total 155.80ms, bridge 0.00ms promoted 224K major 4816K los 783K [0:] 11:14:51.812: DocNavigationViewModel.OnItemTapped[188]: End of OnItemTapped. IsNavigating set to False

    The first and last lines are from my code. Between those I just return from a method and set a bool flag. The rest of those 1.042 seconds between those lines the GC blocked the app.

    As you can see it mentioned GCOLDBRIDGE. It was using the old GC although the GC documentation states that Tarjan should be the default. I didn't know about that before and I didn't choose a different GC on purpose.

    However, now my Android app does use the Tarjan GC and it seems to be better than before. I don't know if it was Cycle 8 or a new XF version which changed it. I did not.

    Thursday, September 29, 2016 5:07 PM
  • User2496 posted

    @MichaelRumpler we sure appreciate all the hard work of the community , but i personally don't agree that just because you open a a lot of PR's it would be a indication they have to be merged. There's a process of review, testing, ui test and manual review. For example sometimes we have asked to add a couple of UITests, because if we are fixing a bug we want to make sure it doesn't regress in the future. Others we review changes made to existing code without a proper explanation, we can't just add something because it fixes only 1 case and might brake another. And it's true some issues do make that Forms doesn't behave exactly how it's supposed, but there's lot's of apps and 3rd party libraries already relying on some of those behaviours so we need to be smart and don't brake everyone when we change something. This is just hard and we are figuring the best way to do it more globally and not just for particular issues.

    @JohnHardman i don't se why you have to implement OnBindingContextChanged, we actually say to people don't use that.. lot's of people use it as a "hack" to get to the VM and to get notified when changes.

    Thursday, September 29, 2016 5:13 PM
  • User92610 posted

    @MichaelRumpler Where did you find it set to Old? I read Tarjan was default but want to make sure mine isn't set to Old somewhere.

    Thursday, September 29, 2016 5:14 PM
  • User166975 posted

    @JohnHardman It should not be necessary to implement OnBindingContextChanged on your Cells. As you scroll through the List, UWP will automatically replace the contents of the ItemContainers for you, regardless of the CachingStrategy you have selected.

    Thursday, September 29, 2016 5:21 PM
  • User89714 posted

    @SamanthaHouts - Great to know that OnBindingContextChanged isn't expected to be required on UWP.

    @rmarinho - That's interesting. I actually went through my code a while back and removed all of the OnBindingContextChanged stuff, other than to leave some diagnostics there to see what is going on. However, the documentation of OnBindingContextChanged is sadly lacking, and I have whilst searching everywhere for more info about its use found snippets from Xamarin folk showing it being used. Some clear documentation and guidance is definitely required. I did notice it on one of the slides from a Xamarin University deck last night as well, although there was nothing useful on the slide to say why it was there.

    I also suspect that using OnBindingContextChanged will be required in the short term to workaround some of the ListView bugs, particularly relating to RecycleElement. I have one logged where ViewCells are disabled, which I suspect I will need to use OnBindingContextChanged to workaround (still to investigate).

    Thursday, September 29, 2016 5:29 PM
  • User311 posted

    @rmarinho I agree with you that PR's should be good enough before merging but I think you are missing @MichaelRumpler 's point: Forms is still in it's infancy open-source wise and then also the way you accept or close a PR, which somebody did in their spare time, matters also as most as the PR or scope of it itself.

    I think it is good to engage more and discuss more and explain, rather than "just" closing the issue, boom like Jason did in this case.

    Thursday, September 29, 2016 6:35 PM
  • User57869 posted

    @ShanePope There are GC messages in the Output window.

    Old:

    08-18 11:14:51.706 D/Mono ( 4427): GCOLDBRIDGE num-objects 295 numhashentries 47142 sccs size 25747 init 0.00ms df1 148.88ms sort 30.32ms dfs2 396.90ms setup-cb 3.47ms free-data 175.82ms links 181377/181377/2912009/115 dfs passes 228814/207124

    Tarjan:

    09-29 18:18:31.419 D/Mono (14366): GCTARBRIDGE bridges 1918 objects 75550 colors 1945 ignored 148728 sccs 1918 xref 1090 cache 0/26 setup 0.59ms tarjan 62.34ms scc-setup 1.31ms gather-xref 0.17ms xref-setup 0.06ms cleanup 5.35ms

    If you see GCOLDBRIDGE or GCNEWBRIDGE (that would be the obvious name), then you should override it like it is described in https://developer.xamarin.com/guides/android/advancedtopics/garbagecollection/#GCBridgeOptions.

    Thursday, September 29, 2016 8:08 PM
  • User89714 posted

    @rmarinho @SamanthaHouts - Here's one piece of Xamarin documentation saying to use OnBindingContextChanged. Can you confirm whether or not this guidance is still correct based on your comments above please?

    https://developer.xamarin.com/guides/xamarin-forms/user-interface/listview/customizing-cell-appearance/#Custom_Cells

    Saturday, October 1, 2016 9:48 AM
  • User126992 posted

    It's been very strange how Xamarin handles Xamarin Forms.

    Xamarin Forms is a UI framework, something which is not part of Xamarin core business. But Xamarin promoted Xamarin Forms at Evolve 2014, Evolve 2016, on their blog, and now Xamarin University includes it. It's like Xamarin Forms is really mainstream. But surprisingly, the Xamarin Forms team continues to be very small and progress on performance is still slow. Progress was made on new features though (control templates, native views, etc.) which is great, but again, it's confusing to me the direction and future of Xamarin Forms. And now Xamarin part of Microsoft complicates it, I'm not sure. Why would Microsoft want to pay employees to work on Xamarin Forms, a cross platform UI framework? It's even more strange than before.

    Personally I always wanted for Xamarin Forms to become the framework which it should be. Unfortunately, I've seen so little communication from Xamarin and support on their own forum, I have no idea what's going on. Regarding Xamarin Forms, Xamarin decided to look like Microsoft, and it's not in the good ways.

    Sunday, October 2, 2016 11:43 AM
  • User89714 posted

    @BryanHunterXam @StephaneDelcroix - I can see that people have been through some of the bugs I listed above. It seems that 43716 has been missed - could you have somebody take an initial look please? Many thanks.

    Monday, October 3, 2016 4:54 PM
  • User77348 posted

    I've tried this new pre release and have this error with XAMLC Severity Code Description Project Project Rank File Line Suppression State Error Position 20:103. No property, bindable property, or event found for 'AddCommand' Views.Tabs.TodoPage.xaml 20

    i used to have another problem which was that the AddCommand of my CustomControl was not binded correctly and i had to cast the binding context and then cast to the vm type and then just call the command directly.

    Any ideas ?

    It happens only for bindable properties named AddCommand or DeleteCommand and even though i rename them it doesn't seem to fix anything...

    Tuesday, October 18, 2016 2:39 AM
  • User1004 posted

    @ErikRenaud.2326 is this a regression ? In any case, could you please tell me how to reproduce that bug, either here, on bugzilla, or by mail ?

    Thanks a lot

    Tuesday, October 18, 2016 7:14 AM
  • User92610 posted

    Does anyone know when the xamarin.forms on mac is going to be able to become .net core over pcl? Having trouble finding info on that stuff. Seems like a lot of libraries will need to be updated first for many projects.

    Tuesday, October 18, 2016 2:55 PM
  • User181025 posted

    I noticed that soft keyboard display animation isn't smooth on iOS when the app cold starts. This started happening when I switched to iOS 10 & XF latest pre-release. The keyboard shows on the second page of the landing screen on appearing.

    Has anyone come across a similar problem?

    Wednesday, October 19, 2016 6:29 AM
  • User19820 posted

    MajorListView performance issue which also reproduces in 2.3.3-pre3: https://bugzilla.xamarin.com/show_bug.cgi?id=45689

    Wednesday, October 19, 2016 12:07 PM
  • User19820 posted

    Also this bug is still in 2.3.3-pre3 https://bugzilla.xamarin.com/show_bug.cgi?id=45727

    There are other several bugs still present in 2.3.3-pre3....

    Thursday, October 20, 2016 10:28 AM
  • User76049 posted

    This one is a pain, any chance it could get looked at too?

    https://bugzilla.xamarin.com/show_bug.cgi?id=42559

    Thursday, October 20, 2016 11:05 AM
  • User164182 posted

    This bug has already been confirmed but has never been fixed: https://bugzilla.xamarin.com/show_bug.cgi?id=41639 Please fix this..

    Thursday, October 20, 2016 1:02 PM
  • User2496 posted

    @ShanePope why do you ask? Anything special? Aren't you referencing to netstandard ? If so we talked but there aren't plans yet to move our PCL's to netstandard.

    If you have special issues with the Mac backend ping me via pm.

    Thursday, October 20, 2016 1:50 PM
  • User76049 posted

    @rmarinho

    Is there a roadmap for Forms to move to .netstandard or what's the official advice on that one?

    Thursday, October 20, 2016 3:51 PM
  • User92610 posted

    @rmarinho Automapper requires it to update so I wasn't sure how quickly things are moving in general towards it. No need for it I just wanted to be prepared if it was soon on the roadmap.

    Friday, October 21, 2016 2:44 PM
  • User96360 posted

    Regarding Android performance people mentiond Tarjan GC, but not other relevant settings. The following environment.txt improved both app startup and responsiveness:

    MONOGCPARAMS=bridge-implementation=tarjan,nursery-size=128m,soft-heap-limit=256m

    The main idea is to avoid random collections and GC manually at opportune times.

    Sunday, October 23, 2016 3:38 AM
  • User268409 posted

    Can somebody show an example, how to use native views correctly, for example, i want to call Android GridView and make a data template for it?

    Monday, October 24, 2016 2:02 PM
  • User113114 posted

    Can we expect a new update soon? so much good stuff jammed in for the next release :)

    Monday, October 24, 2016 2:53 PM
  • User89714 posted

    @BryanHunterXam @StephaneDelcroix @rmarinho - It's probably a bit late in the day, but is there any chance of getting https://bugzilla.xamarin.com/show_bug.cgi?id=41054 addressed in this release? I've tried all the obvious workarounds but nothing works well enough to release to an end user.

    Monday, October 24, 2016 3:44 PM
  • User113114 posted

    @JohnHardman said: @BryanHunterXam @StephaneDelcroix @rmarinho - It's probably a bit late in the day, but is there any chance of getting https://bugzilla.xamarin.com/show_bug.cgi?id=41054 addressed in this release? I've tried all the obvious workarounds but nothing works well enough to release to an end user.

    what have you tried? I dont want to install windows sdk to test it, but I do know some ways to do this "in a good way" without a behaviour. Is it only the behaviour that it bugged? or is it changing textcolor on uwp in general?

    The most simplest way would be to do it in codebehind like this.

    if (Device.OS == TargetPlatform.Windows) { entry.Style = null; entry.TextChanged += (sender, args) => { double result; bool isValid = double.TryParse(args.NewTextValue, out result); ((Entry)sender).TextColor = isValid ? Color.Default : Color.Red; }; }

    If you dont like coding in codebehind (you shouldnt like that :smile: ) , you could do it against a viewmodel and bind the textcolor and ofc the text, validate it and change the color accordingly. Another approach would be to do it in a converter that returns the textcolor and uses the text as input to validate.

    Monday, October 24, 2016 9:54 PM
  • User89714 posted

    @BjornB - The list of things tried is long :-)

    As an aside, there is a general issue with TextColor on Entry views in UWP, which can be worked around to a certain extent using Windows.UI.Xaml.Style. For more info, see https://forums.xamarin.com/discussion/comment/229383/#Comment_229383 . In the latest stable release, even that is much better than it was previously.

    But, when setting TextColor for an Entry from a Behavior, the issue is much harder to workaround. See https://bugzilla.xamarin.com/show_bug.cgi?id=41054 for the bug report. Basically, although the TextColor property changes, the change is not reflected on screen until the user moves the focus away from the Entry and moves it back again. This can be done programmatically, and with some extra effort to reposition the caret, it might look at first sight as if it works on desktop. However, the move of focus makes the result of typing non-deterministic (keystrokes might not go to the Entry and the focus may never return to the Entry). On phones, the move of focus makes the keyboard disappear and reappear, which is most unpleasant. Even changing the Windows.UI.Xaml.Style does not work at this point.

    As well as moving the focus programmatically, I tried all sorts of other things. Toggling IsVisible twice has a similar result to moving the focus. Nothing else that I tried came close to the desired effect. Normally for things like this, I would invalidate the view, so that it is re-drawn. However, in this particular case, invalidating the view, re-sizing the view, changing the font size, changing opacity, changing the backround color, scaling the view, etc., all had no useful effect.

    Using TextChanged to change TextColor, instead of using a Behavior, similarly makes no difference until the focus is moved elsewhere.

    Monday, October 24, 2016 10:13 PM
  • User268935 posted

    I just tried to update to the pre4 today -- Nuget.org says the package was last updated today, and has "0 downloads", so I might be one of the first to post this issue -- but the package is malformed in some way; -- I tried reinstalling it many times, and always end up with the same errors.

    Friday, October 28, 2016 1:03 AM
  • User221964 posted

    Can't update pre4 from nuget package / Xamarin studio (mac)

    Installing Xamarin.Forms 2.3.3.165-pre4. Error downloading 'Xamarin.Forms.2.3.3.165-pre4' from 'https://www.nuget.org/api/v2/package/Xamarin.Forms/2.3.3.165-pre4'. Nullable object must have a value. Install failed. Rolling back... Package 'Xamarin.Forms.2.3.3.165-pre4' does not exist in project 'allbX'

    Friday, October 28, 2016 5:39 PM
  • User66766 posted

    @TheRealJasonSmith @BryanHunterXam I also cannot install 2.3.3.165-pre4

    Friday, October 28, 2016 7:30 PM
  • User42408 posted

    [Platform Specifics] Xamarin.Forms.PlatformConfiguration.iOSSpecific.NavigationPage and Xamarin.Forms.NavigationPage are conflict when using On<iOS>().SetIsNavigationBarTranslucent() .

    Xamarin.Forms.PlatformConfiguration.iOSSpecific.NavigationPage class should be be renamed.

    Saturday, October 29, 2016 5:22 AM
  • User113114 posted

    Is there any documentation on platformconfiguration?

    Tuesday, November 1, 2016 1:51 PM
  • User139040 posted

    @PhilipGruebele said: Regarding Android performance people mentiond Tarjan GC, but not other relevant settings. The following environment.txt improved both app startup and responsiveness:

    MONOGCPARAMS=bridge-implementation=tarjan,nursery-size=128m,soft-heap-limit=256m

    The main idea is to avoid random collections and GC manually at opportune times.

    Also as far as performance goes, we sped our android side up a TON by doing a bunch of different things buy mainly was fixing a bug in xamarin's code that builds all of the DataTemplates you have in XAML over and over down the tree without ever calling createcontent. If you use alot of DataTemplates like us then you can gain ALOT of speed by fixing that bug and using a custom forms.xaml dll for deployment...

    I outlined it here: https://bugzilla.xamarin.com/show_bug.cgi?id=45179

    Tuesday, November 1, 2016 2:21 PM
  • User66766 posted

    @BradChase.2654 can you share the code you did to fix this? Also the other things you fixed to get Android to perform better

    Tuesday, November 1, 2016 3:02 PM
  • User96360 posted

    @BradChase.2654 I also saw some inefficient happenings with templates and would love to see a pull request with your changes.

    Tuesday, November 1, 2016 4:10 PM
  • User139040 posted

    @PhilipGruebele @DH_HA1 I wouldnt mind putting the code up but unfortunately I have not had to the time to fix it professionally. I made a quick work around for a single deploy for a conference with the hopes Xamarin will make an actual fix. I tried to use their latest code and pulled from github but the code doesnt run at all with our app. To also mention the latest on nuget doesnt either. I went through all the branches just about down to 2.3.2.127 and that was the first build that actually builds for us.

    That said Ill attach the dll if you want to check the speed increases and if its worth while to even bother for your apps. The code is simple for a proof of concept:

    Get the 2.3.2.127 code or branch: Xamarin.Forms-release-2.3.2-hf1

    in CreateValuesVisitor.Visit replace with:

    ` public void Visit(ElementNode node, INode parentNode) { object value = null;

            if (node.SkipPrefix(node.NamespaceResolver.LookupPrefix(node.NamespaceURI)))
                return;
    
            XamlParseException xpe;
            var type = XamlParser.GetElementType(node.XmlType, node, Context.RootElement?.GetType().GetTypeInfo().Assembly,
                out xpe);
            if (xpe != null)
                throw xpe;
    
            Context.Types[node] = type;
            string ctorargname;
            if (IsXaml2009LanguagePrimitive(node))
                value = CreateLanguagePrimitive(type, node);
            else if (node.Properties.ContainsKey(XmlName.xArguments) || node.Properties.ContainsKey(XmlName.xFactoryMethod))
                value = CreateFromFactory(type, node);
            else if (
                type.GetTypeInfo()
                    .DeclaredConstructors.Any(
                        ci =>
                            ci.IsPublic && ci.GetParameters().Length != 0 &&
                            ci.GetParameters().All(pi => pi.CustomAttributes.Any(attr => attr.AttributeType == typeof (ParameterAttribute)))) &&
                ValidateCtorArguments(type, node, out ctorargname))
                value = CreateFromParameterizedConstructor(type, node);
            else if (!type.GetTypeInfo().DeclaredConstructors.Any(ci => ci.IsPublic && ci.GetParameters().Length == 0) &&
                     !ValidateCtorArguments(type, node, out ctorargname))
            {
                throw new XamlParseException(
                    String.Format("The Property {0} is required to create a {1} object.", ctorargname, type.FullName), node);
            }
            else
            {
                //this is a trick as the DataTemplate parameterless ctor is internal, and we can't CreateInstance(..., false) on WP7
                try
                {
                    if (type == typeof (DataTemplate))
                        value = new DataTemplate();
                    if (type == typeof (ControlTemplate))
                        value = new ControlTemplate();
                    if (value == null && node.CollectionItems.Any() && node.CollectionItems.First() is ValueNode)
                    {
                        var serviceProvider = new XamlServiceProvider(node, Context);
                        var converted = ((ValueNode)node.CollectionItems.First()).Value.ConvertTo(type, () => type.GetTypeInfo(),
                            serviceProvider);
                        if (converted != null && converted.GetType() == type)
                            value = converted;
                    }
    
                    if (ElementNode.IsDataTemplateTest(parentNode))
                    {
                        System.Diagnostics.Debug.WriteLine("IN DATATEMPLATE TEST!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");
                        value = new View();
                        //return;
                    }
                    else
                    {
                        if (value == null)
                            value = Activator.CreateInstance(type);
                    }
                }
                catch (TargetInvocationException e)
                {
                    if (e.InnerException is XamlParseException || e.InnerException is XmlException)
                        throw e.InnerException;
                    throw;
                }
            }
    
            Values[node] = value;
    
            var typeExtension = value as TypeExtension;
            if (typeExtension != null)
            {
                var serviceProvider = new XamlServiceProvider(node, Context);
    
                var visitor = new ApplyPropertiesVisitor(Context);
                foreach (var cnode in node.Properties.Values.ToList())
                    cnode.Accept(visitor, node);
                foreach (var cnode in node.CollectionItems)
                    cnode.Accept(visitor, node);
    
                value = typeExtension.ProvideValue(serviceProvider);
    
                node.Properties.Clear();
                node.CollectionItems.Clear();
    
                Values[node] = value;
            }
    
            if (value is BindableObject)
                NameScope.SetNameScope(value as BindableObject, node.Namescope);
        }
    

    `

    in XamlNode.cs add:

    internal static bool IsDataTemplateTest(INode parentNode) { var parentElement = parentNode as IElementNode; INode createContent; if (parentElement != null && parentElement.Properties.TryGetValue(XmlName._CreateContent, out createContent) ) return true; return false; }

    Again this is JUST TEST CODE. I wanted to narrow down where it was and test the speed. I had a much more final change done but I could not get it running for one reason or another(read latest github code wouldnt work for us). The value = new View(); is in there because some other code somewhere requires it not be null and must be a view, so got me there. You should prolly change the IsDataTemplateTest to just use internal static bool IsDataTemplate(INode node, INode parentNode) function. Also this code is used to compile the xaml at build time using Xamarin.Forms.Build.Tasks.. So the code has to work in use and in build.

    OK all that said, here is the simpliest way to test it... goto 2.3.2.127 and take the Xamarin.Forms.Xaml.dll I am attaching and place it in your packages->Xamarin.Forms.2.3.2.127->lib->(MonoAndroid10, portable..., Xamarin.iOS10) directories.

    Damn, DLL's arent allowed, try this:

    https://github.com/BradChase2011/SavedPackages and grab the Xamarin.Forms.Xaml.dll and overwrite your dlls outlined above.

    Tuesday, November 1, 2016 5:22 PM
  • User139040 posted

    @DH_HA1 We funny enough moved to alot of data templates so that we werent loading up a ton of views that the user might not ever visit. Second we temporarily bumped the rendering to the next frame for each template create content. That allowed for the user to know 100% they tapped or interacted with the app while we were busy loading the content. Its not as pretty as a load everything at the start design but when users are upset that it takes 30 seconds to load a view or they hit something 10 times because they dont know something as actually happening, then thats a big deal.

    Use: [assembly: XamlCompilation(XamlCompilationOptions.Compile)]

    Grids are very slow when using Auto. So try to eliminate all of those that you can.

    We have alot of custom controls. That said, we were adding and removing alot of columns and rows in those custom controls. We overtook the grid and ignored rendering while adding columns and rows, ITS VERY SLOW!! VERY VERY! This way we can pack up say 10 rows and push them all at once. This gave massive increases.

    Deployment... Get AOT working! GET IT WORKING! Seriously if it has failed for anyone and you gave up on it, revisit it. It was another large increase for us. It may not be for you but for some apps it is. Also LLVM.

    We changed the settings on garbage collection. We found it was recycling wayyyyyyyyyyy too often. We switched to tarjan and a nursery of 128m. We also bumped the Java max heap up to 1G, we have a big app and one view with all the faults in Xamarin were causing a bunch of collections when loading a view.

    The largest increases came from organizing the views and how they load. You need to manage when and how the views will load if they arent in view. Some views might be fine loading the entire thing at once while others might need to be put off a frame or delay load when visible....

    Ughhh soo many more, if I think of them Ill post more, I prolly should have wrote an article on all the things we had to do. Sorry :(.

    EDIT: To add, its very expensive to add and remove controls as well as create controls. If you can do more control reuse, the better you will be.

    For instance if you have a details view or something editable try to not make that view a 100 times as a child of say a data grid row... Make one panel and rebind the BindingContext. You may need to change designs... but you do what ya have to do. In our custom controls we just put elements to sleep and when they are rebound we just rebind them and wake them up rather than removing them completely or destroying them... Just be careful for memory leaks when doing that.

    EDIT2: Pickers. Pickers will kill your app on android. In Xamarin's code they set the selected item to every single item in the ItemSource. We made a customizable picker instead for anything larger than 5 or so items in the list. We found this out ages ago but i remember it being minutes for a view that would have pickers bound to a list with 100s or 1000s of items in it.

    Tuesday, November 1, 2016 5:39 PM
  • User67129 posted

    @BradChase.2654 Nice tips. I see you mention changing the garbage collection settings. do you have any notes on how you did this?

    Wednesday, November 2, 2016 10:09 AM
  • User139040 posted

    @JKay We have an environment.txt file we keep in our main droid project, go to the bottom of this link: https://developer.xamarin.com/guides/android/advancedtopics/garbagecollection/

    this is the line we use: MONOGCPARAMS=nursery-size=128m,bridge-implementation=tarjan

    also go to your project settings->Android Options->Advanced tab -> Java Max Heap Size. We set this to "1G" without the quotes. That may be too high for most people for us its just right. Of course now with the datatemplate fix we might be able to lower it quite a bit.

    I forgot to mention we also do caching at the beginning of our app start and we clear the gc after each cache load. This helps by the time they start a view that they are not waiting for the collection at that point...

    Wednesday, November 2, 2016 2:21 PM
  • User96360 posted

    The only thing I would add to @BradChase.2654's list is to use the FFImageLoading nuget in order to resize images. CachedImage is a drop-in replacement for Image and has nice functionality. For example I have a background image which I adapt to the native resolution using

                            DownsampleUseDipUnits = true,
                            DownsampleWidth = screenDipWidth / 3,
    

    Large image assets can really slow Android down. The library also supports delayed loading and other means of speeding things up.

    Wednesday, November 2, 2016 8:12 PM
  • User139040 posted

    @PhilipGruebele good catch on that. We only use svgs so I haven't experienced any slow downs yet there.

    Wednesday, November 2, 2016 10:50 PM
  • User67129 posted

    @BradChase.2654 What do you use for your SVGs? This is something I have been wanting to use in my project for a while but never found a good package

    Thursday, November 3, 2016 8:38 AM
  • User139040 posted

    @JKay We use this one:

    https://github.com/paulpatarinski/Xamarin.Forms.Plugins

    We actually forked it quite a long time ago to add color changing on the fly at:

    https://github.com/BradChase2011/Xamarin.Forms.Plugins

    Its old code though and hasnt been updated from master in quite awhile. I also have not added UWP support which I will need to do when we target desktop platforms. So if you dont need to change colors on the fly then go with paulpatarinskis libary. I will need to update my code at some point as I have modified the one we use in our control library.

    Sorry I couldnt be more help on it. If I had more time in the day I would update the github repository and get it running with all the new bells and whistles.

    Thursday, November 3, 2016 12:42 PM
  • User221964 posted

    Thanks Xamarin. This update solved many problems of mine.

    Saturday, November 5, 2016 4:11 PM
  • User2496 posted

    Hi everyone we just pushed stable packages of 2.3.3, only change from 2.3.3-pre4 is a fix related with a exception when popping pages.

    Wednesday, November 23, 2016 9:51 AM
  • User132171 posted

    Just tried the new 2.3.3.168 stable, and it still completely breaks us on iOS. Visibility changes sometimes don't happen, content views with a different background color and a bit of padding to make a border around other views don't draw if they weren't visible when the page is created, and the worst issue is we're getting null reference exceptions reporting "Error: An error occurred while executing MTouch" when navigating around (we use prism and it's all modal navigation). So far those exceptions seem to occur randomly, and I've yet to find steps that duplicate it.

    All of those issues go away by simply reverting to 2.3.2.127.

    On the plus side it seems the issue with keyboards overlaying listviews breaking their ability to scroll seems to be fixed.

    Wednesday, November 23, 2016 6:10 PM
  • User221964 posted

    2.3.3-pre4 was working fine. but 2.3.3-stable ruins many ui of our app especially on ListView. (tested on iOS 9) Don't know why this happens if only change was popping page.

    Thursday, November 24, 2016 1:56 AM
  • User183635 posted

    https://forums.xamarin.com/discussion/83213/xamarin-2-3-3-my-converter-isnt-working-due-to-a-sealed-class#latest

    Why adding a sealed keyword ?

    Thursday, November 24, 2016 9:11 AM
  • User132973 posted

    I have updated to version 2.3.3.168 and the BackgroundColor property is not working for elements which are inside .......

    What is happening?

    Thursday, November 24, 2016 10:57 AM
  • User3516 posted

    What happened to the thread about the new 2.3.4-pre1? There was one yesterday, now it is gone?

    Thursday, November 24, 2016 12:18 PM
  • User245309 posted

    Master Detail Page is displayed incorrectly after update to 2.3.3.168.

    Thursday, November 24, 2016 12:50 PM
  • User258 posted

    @DirkWilhelm said: What happened to the thread about the new 2.3.4-pre1? There was one yesterday, now it is gone?

    I would like to know as well.

    Thursday, November 24, 2016 3:24 PM
  • User2496 posted

    We had some issues and looking at that release again. We will try to put it up again soon next week. Sorry by the inconvenience.

    Thursday, November 24, 2016 4:00 PM
  • User210933 posted

    And so the red underlined InitializeComponent() bug is back. UNBELIEVABLE!

    Thursday, November 24, 2016 6:39 PM
  • User2022 posted

    @JeffDalby said: Just tried the new 2.3.3.168 stable, and it still completely breaks us on iOS. Visibility changes sometimes don't happen, content views with a different background color and a bit of padding to make a border around other views don't draw if they weren't visible when the page is created,

    I'm having issues as well with the background color of elements. Some elements are 'losing' the background color when they are binded with the IsVisibleProperty which then changed from false to true. So after becoming visible from non-visible, they have lost their background color.

    edit: after going back to 2.3.2.127 these problems disappeared. Will stay on 2.3.2.127 for now.

    Friday, November 25, 2016 10:17 AM
  • User130379 posted

    Is there a reason why android dependencies for forms are kept on such old versions? This makes installing any other libraries a bit of a pain.

    Friday, November 25, 2016 11:40 AM
  • User243927 posted

    @WiktorKoncki said: Is there a reason why android dependencies for forms are kept on such old versions? This makes installing any other libraries a bit of a pain.

    +1

    Saturday, November 26, 2016 5:35 PM
  • User181025 posted

    @StephaneDelcroix FYI: 47805

    Saturday, November 26, 2016 7:56 PM
  • User279043 posted

    @ErikRenaud.2326 @StephaneDelcroix did you resolve the issue? I'm having similar problems when a) using a bindable property with generic return type, eg Layout b) setting an attached property using markup extension, eg local:Page2.AttachedProperty="{local:ToUpper foo}"

    I have attached a test project to reproduce the issue. Tested with Xamarin.Forms 2.3.3.168. This DID work with XF 2.3.2

    Saturday, November 26, 2016 8:45 PM
  • User1004 posted

    @DominikWeber.1641: - see https://forums.xamarin.com/discussion/comment/235953 for a workaround. Well, not really a workaround, that's how you should implement you markup extensions so XamlC can generate better IL for it. - see also https://github.com/xamarin/Xamarin.Forms/pull/562 for the fix

    If this does not solve the issue in your case, please say so

    Saturday, November 26, 2016 9:04 PM
  • User279043 posted

    @StephaneDelcroix Interesting, I was under the impression that we should use the non-generic version like with BindableProperty.Create. I did change my code and it indeed solves the issue, thank you! However generic bindable properties still do not work (see updated sample project). Any advice for this? Is this no longer supported/recommended?

    Saturday, November 26, 2016 10:20 PM
  • User210933 posted

    @Maamoun said:

    @WiktorKoncki said: Is there a reason why android dependencies for forms are kept on such old versions? This makes installing any other libraries a bit of a pain.

    +1

    +1

    Sunday, November 27, 2016 4:03 AM
  • User1004 posted

    @DominikWeber.1641: The generic version of BP.Create and SetBinding are frowned upon not because of the generics, but because they use an Expression that need to be parsed at startup of the app, and that is really expensive on iOS and android.

    Regarding your issue: I have no workaround in mind at this moment, except declaring your BP to be of type StackLayout, but I have a fix https://github.com/xamarin/Xamarin.Forms/pull/566

    Sunday, November 27, 2016 1:30 PM
  • User139568 posted

    @MichaelRumpler said:

    What's even more important: @AdrianKnight invested a lot of work to write all those PRs - not only this one. His name pops up more often in the list of PRs than any Xamarin employee.

    I actually got to a point that i thought @AdrianKnight was the new hire on the Xamarin.Forms team to Squish all those bugs, i was really happy; then i found him confronting the @TheRealJasonSmith on rejecting a PR with a not so acceptable reason.

    True talk now: I really think Xamarin.Forms should be re-written just like Angular 2 was after some years of realizing it was worth it. I really think the Xamarin.Forms are doing this(a re-write) privately and maybe the reason they don´t seem to give enough attention to software and tool stability.

    Sunday, November 27, 2016 11:55 PM
  • User279043 posted

    @StephaneDelcroix awesome, thanks! :)

    Monday, November 28, 2016 12:45 AM
  • User225119 posted

    @AhmedAlejo said:

    @MichaelRumpler said:

    What's even more important: @AdrianKnight invested a lot of work to write all those PRs - not only this one. His name pops up more often in the list of PRs than any Xamarin employee.

    I actually got to a point that i thought @AdrianKnight was the new hire on the Xamarin.Forms team to Squish all those bugs, i was really happy; then i found him confronting the @TheRealJasonSmith on rejecting a PR with a not so acceptable reason.

    True talk now: I really think Xamarin.Forms should be re-written just like Angular 2 was after some years of realizing it was worth it. I really think the Xamarin.Forms are doing this(a re-write) privately and maybe the reason they don´t seem to give enough attention to software and tool stability.

    Maybe that would be the best choice. We can't take too much BUG like now.

    Monday, November 28, 2016 3:17 AM
  • User2496 posted

    @Theos @JeffDalby can you please provide some sample code, we aren't able to reproduce it .

    Thanks

    Monday, November 28, 2016 10:51 AM
  • User132973 posted

    @Theos said:

    @JeffDalby said: Just tried the new 2.3.3.168 stable, and it still completely breaks us on iOS. Visibility changes sometimes don't happen, content views with a different background color and a bit of padding to make a border around other views don't draw if they weren't visible when the page is created,

    I'm having issues as well with the background color of elements. Some elements are 'losing' the background color when they are binded with the IsVisibleProperty which then changed from false to true. So after becoming visible from non-visible, they have lost their background color.

    edit: after going back to 2.3.2.127 these problems disappeared. Will stay on 2.3.2.127 for now.

    Please, we need a release which fixes these bugs, I can't believe it...

    Monday, November 28, 2016 3:09 PM
  • User113114 posted

    Was 2.3.3.4 pre 1 removed because of insane unstability? Im using it and im getting lots of unmanaged code crashes.. with stacktraces that means nothing to me

    Monday, November 28, 2016 4:11 PM
  • User2496 posted

    @BjornB Please provide that info in bugzilla so we can properly track it down.. Sample, and stack traces are be super helpful.

    We also identified the issue with BackgroundColor missing sometimes on iOS on 2.3.3 and we are testing the fix now will try to ship a hotfix ASAP.

    Thanks.

    Monday, November 28, 2016 8:05 PM
  • User55951 posted

    Just updated and faced the Background color on iOS. Also some of the listviews on iOS are looking bad now.

    Monday, November 28, 2016 8:48 PM
  • User113114 posted

    @rmarinho said: @BjornB Please provide that info in bugzilla so we can properly track it down.. Sample, and stack traces are be super helpful.

    We also identified the issue with BackgroundColor missing sometimes on iOS on 2.3.3 and we are testing the fix now will try to ship a hotfix ASAP.

    Thanks.

    Il post the bugzilla links here when its done. Im curious why you decided to remove 2.3.4 from nuget

    Monday, November 28, 2016 10:13 PM
  • User2496 posted

    @ksachdeva can you provide some info of ListView issues you are seeing in 2.3.3 ? thanks.

    Tuesday, November 29, 2016 11:13 AM
  • User17580 posted

    I have had some list issues with text that wraps outside its cell in iOS (I'm using TextCell)

    Tuesday, November 29, 2016 12:04 PM
  • User132171 posted

    @rmarinho said: @BjornB Please provide that info in bugzilla so we can properly track it down.. Sample, and stack traces are be super helpful.

    We also identified the issue with BackgroundColor missing sometimes on iOS on 2.3.3 and we are testing the fix now will try to ship a hotfix ASAP.

    Thanks.

    I'm back at the office, I take it you don't need code to reproduce this anymore. Looking forward to the fix.

    Tuesday, November 29, 2016 3:43 PM
  • User2496 posted

    Hey @JeffDalby the BackgroundColor issues we already have a fix, but can you reproduce a example where you are getting "null reference exceptions" with Modal?

    Tuesday, November 29, 2016 3:49 PM
  • User174034 posted

    @rmarinho said: @ksachdeva can you provide some info of ListView issues you are seeing in 2.3.3 ? thanks.

    We also found some bugs on ListViews running on iOS. The first one is quite important, as it might hide some important results for the user.

    On 2.3.3 I have only testet in the simulator, but on 2.3.2 we got the bugs also on our devices.

    First: If the listview has pulltorefresh, and is refreshing, and you then click on a entry, strange things might happend. It seems a little better on 2.3.3.168, but when I click on the entry, then on a refresh button, the result is unaligned.

    Second: If the RefreshCommand returns false on CanExecute, the spinner will start, but nothing else will happen.

    Third: If the RefreshCommand CanExecute changes during the pull to refresh, it will kill the spinner.

    For some code to reproduce the bugs, se: https://gist.github.com/oddbear/903b9c30aecc1e7067b9dfd709038cdb

    Tuesday, November 29, 2016 4:08 PM
  • User103333 posted

    Is CarouselView included in this release?

    Tuesday, November 29, 2016 6:09 PM
  • User132171 posted

    @rmarinho said: Hey @JeffDalby the BackgroundColor issues we already have a fix, but can you reproduce a example where you are getting "null reference exceptions" with Modal?

    Ok, so I've spent most of the morning trying to come up with a way to consistently duplicate this but so far haven't had any luck. I seem to have been able to narrow it down to pages with listviews that have the CachingStrategy set to RecycleElement. So far at least in my testing if I set it to RetainElement the crashes seem to stop. I can't say with 100% certainty that is the fix since the crash has been random. I can say that I've never been able to make it crash on a page without a listview, and that I've not yet been able to make it crash on a page that it had previously been crashing on after changing to RetainElement.

    Regardless of the page or content of the listview on the page the crash is always identical. From HockeyApp here's what it has been:

    Exception Type: SIGABRT Exception Codes: #0 at 0x10e9fddda Crashed Thread: 0

    Application Specific Information: * Terminating app due to uncaught exception 'System.NullReferenceException: Object reference not set to an instance of an object', reason: 'System.NullReferenceException: Object reference not set to an instance of an object at (wrapper managed-to-native) UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr) at UIKit.UIApplication.Main (System.String[] args, System.IntPtr principal, System.IntPtr delegate) [0x00005] in /Users/builder/data/lanes/3969/44931ae8/source/xamarin-macios/src/UIKit/UIApplication.cs:79 at UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x00038] in /Users/builder/data/lanes/3969/44931ae8/source/xamarin-macios/src/UIKit/UIApplication.cs:63 at WeFeelXamarin.iOS.Application.Main (System.String[] args) [0x00001] in C:\source\WeFeelX\WeFeelXamarin\WeFeelXamarin.iOS\Main.cs:17 '

    Let me know if the backtrace info would help.

    Tuesday, November 29, 2016 6:25 PM
  • User13234 posted

    Does 2.3.3 break Theming for anyone else? I'm running into an issue where The DarkThemeResources is trying to use an old version of SimpleValueTargetProvider and it's crashing with a method not found exception when I try to merge that dictionary into my own.

    @StephaneDelcroix I think you were the one that actually made the changes for the SimpleValueTargetProvider constructor, can you shed any light on this?

    Tuesday, November 29, 2016 7:41 PM
  • User1004 posted

    @deckertron9000 can you give more info on what you're doing to get the exception ?

    Tuesday, November 29, 2016 7:44 PM
  • User13234 posted

    @StephaneDelcroix Sure thing! I'm using Xamarin.Forms 2.3.3.168 and Xamarin.Forms.Themes 1.0.0.43-pre1 with a UAP project.

    I have a ResourceDictionary named DarkResourceDictionary (xaml) that I instantiate when my app starts up. This dictionary declares in xaml that it should be merged with the Xamarin.Forms.Theme.Dark.DarkThemeResources. When it tries to call the constructor on the DarkThemeResources I get a MissingMethodException referring to the constructor

    SimpleValueTargetProvider(object[] objectAndParents)
    

    I looked at the source for X.F 2.3.3.168 and it looks like SimpleValueTargetProvider had its constructor updated to look like

    SimpleValueTargetProvider(object[] objectAndParents, object targetProperty). 
    

    I suspect the Themes packages are still expecting the old constructor to exist.

    The actual exception is nested three deep and looks like so:

    outer exception at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at Xamarin.Forms.ResourceDictionary.set_MergedWith(Type value)

    middle exception at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck) at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark) at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark) at System.Activator.CreateInstance(Type type, Boolean nonPublic) at System.Activator.CreateInstance(Type type) at Xamarin.Forms.ResourceDictionary.GetInstance(Type type)

    inner exception at Xamarin.Forms.Themes.DarkThemeResources.InitializeComponent() at Xamarin.Forms.Themes.DarkThemeResources..ctor()

    Tuesday, November 29, 2016 8:19 PM
  • User57869 posted

    @rmarinho said: the BackgroundColor issues we already have a fix

    I tried to update from 2.3.2.127 to 2.3.3.168. BackgroundColor works, but I get an error with ToolbarItem.Icon instead

    DocNavigationPage.xaml(18,7): error : Position 18:7. No property, bindable property, or event found for 'Icon'
    

    This is the related xaml:

        <ToolbarItem Text="OpenFile" x:Name="OpenFileToolbarItem"
                     Command="{Binding OpenFileCommand}"
                     Priority="{x:Static common:Numbers.ToolbarItemPriority1}"
                     Icon="{x:Static common:Images.OpenFile}" />
    

    I tried in both iOS and Android.

    Hopefully this is the same problem as BackgroundColor and it is already fixed and just not released.

    Wednesday, November 30, 2016 3:31 PM
  • User97202 posted

    I got error : System.MissingMethodException: Method 'Xamarin.Forms.Xaml.Internals.SimpleValueTargetProvider..ctor' not found.

    But when I disable XamlCompilationOptions.Compile, every thing is working fine.

    Like following

    ```

    //[assembly: XamlCompilation(XamlCompilationOptions.Compile)]

    ```

    Wednesday, November 30, 2016 3:43 PM
  • User13234 posted

    @Vulcan I explicitly changed XamlCompilation to be skipped in all of my assemblies and I am still seeing this exception.

    @StephaneDelcroix I noticed someone else had opened a bug about this so I added my repro to the ticket.

    Wednesday, November 30, 2016 4:23 PM
  • User1004 posted

    @deckertron9000 it's because the Themes are compiled. I'm reenabling backward compatibility for those.

    Wednesday, November 30, 2016 4:26 PM
  • User13234 posted

    @StephaneDelcroix Awesome, thanks for your time!

    Wednesday, November 30, 2016 4:29 PM
  • User1004 posted

    @Vulcan make sure all your projects are up-to-date to the latest version

    Wednesday, November 30, 2016 4:47 PM
  • User151034 posted

    I get the error "Unable to create layer for ActivityIndicatorRenderer" in android after upgarding to this version, rolling back.

    Thursday, December 1, 2016 1:12 PM
  • User225119 posted

    Xamarin.Forms team, I don't know what kind of big feature your're guys doing, but currently big problem for us are: Memory leak and Listview and some performance problems....(for UWP for me)

    I hope you leader change the priority of the things. If we can't even use it normal, why we would use some kind of big feature?

    Thursday, December 1, 2016 4:13 PM
  • User225119 posted

    @Kir said: Master Detail Page is displayed incorrectly after update to 2.3.3.168.

    I also confirmed that, it already happening on 2.3.3.166 pre4. did you send it to the bugzilla? But only the PC version, not mobile.(thank God)

    Thursday, December 1, 2016 4:25 PM
  • User13234 posted

    @StephaneDelcroix I'm not sure who to ask, but do you have any knowledge on when the next update for 2.3.3 would be coming out? There's a lot of memory leaks on UWP that were addressed in 2.3.3 (profiling reveals way lower memory usage and way more released objects) but the themes not working is a blocker for me.

    Thursday, December 1, 2016 10:08 PM
  • User9 posted

    @deckertron9000 said: @StephaneDelcroix I'm not sure who to ask, but do you have any knowledge on when the next update for 2.3.3 would be coming out? There's a lot of memory leaks on UWP that were addressed in 2.3.3 (profiling reveals way lower memory usage and way more released objects) but the themes not working is a blocker for me.

    We mention a way of getting 2.3.4 right now on the following thread and a quick update on the current state of 2.3.3 so hopefully this gives you some extra information that's useful!

    ChrisNTR

    Friday, December 2, 2016 2:22 AM
  • User13234 posted

    @ChrisHardy Hey thanks for the additional information! I'm assuming that the Theme issue is included under the XamlC issues mentioned in that post. Looking forward to the release (assuming next week since it's already Friday). Cheers!

    Friday, December 2, 2016 2:27 PM
  • User92861 posted

    @huangjinshe @Kir

    I'm not able to reproduce the issue with the MasterDetailPage on UWP using Forms 2.3.3.168 or 2.3.3.166-pre4. Can you please file a bug report with a reproduction project so this can get looked into? Thanks!

    Friday, December 2, 2016 6:35 PM
  • User225119 posted

    @JimmyGarrido said: @huangjinshe @Kir

    I'm not able to reproduce the issue with the MasterDetailPage on UWP using Forms 2.3.3.168 or 2.3.3.166-pre4. Can you please file a bug report with a reproduction project so this can get looked into? Thanks!

    You guys really let me down, every time I add something to bugzilla let me upload sample I did it every time but a lot of time no any response after I put sample, and now again?

    Just download some of my bugs and update to :Forms 2.3.3.168 and core to 5.2.2, and test. I just did it and confirmed again. https://bugzilla.xamarin.com/show_bug.cgi?id=41843

    Also fix that bug too, that almost take half year.......

    Saturday, December 3, 2016 12:41 PM
  • User258 posted

    This one ( or rather the lack of it) is making our insights crash reporting glow in the dark : https://github.com/xamarin/Xamarin.Forms/pull/527 and our users very unhappy.

    Too bad it did not make it into https://github.com/xamarin/Xamarin.Forms/releases/tag/release-2.3.3-sr1

    Saturday, December 3, 2016 1:54 PM
  • User221964 posted

    @void I agree with that.

    And I'm curious how do you track crash report from your app? I saw reviews on HockeyApp component store, there are tons of 1 start reviews. So I'm afraid to implement it.

    Monday, December 5, 2016 5:56 AM
  • User258 posted

    @BBright We're flying on the fumes of an Insights Business Subscription. We've also implemented Hockey App, but to be honest it does not provide any value to us. So I've signed up for the Mobile Center preview https://blogs.msdn.microsoft.com/visualstudio/2016/11/16/visual-studio-mobile-center/ that I suppose will be the tool to rule'm' all.

    Monday, December 5, 2016 8:12 AM
  • User221964 posted

    Wow. it looks really cool. Thanks! @void

    Monday, December 5, 2016 8:50 AM
  • User311 posted

    @BBright I'm using Raygun, works ok for me.

    Monday, December 5, 2016 8:54 AM
  • User221964 posted

    Wow... why I thought hockeyApp is only solution! Thanks so much @rogihee . It looks great!

    Sorry about talking out of topic.

    Monday, December 5, 2016 8:57 AM
  • User89515 posted

    Frames without rounded border in this version! Was this intended?

    Had already reported this in https://forums.xamarin.com/discussion/76737/xamarin-color-same-value-different-tone-in-ios#latest

    Can someone confirm?

    Monday, December 5, 2016 1:59 PM
  • User210933 posted

    Is there a way to stop getting e-mails about this thread only?

    Monday, December 5, 2016 5:08 PM
  • User221964 posted

    I would like to know how to get e-mail about this thread. :) When 2.3.3 stable will be released again? @ChrisHardy

    Thanks.

    Monday, December 5, 2016 6:42 PM
  • User180180 posted

    I am also experiencing the background color bug since updating Xamarin.Forms from 2.3.2.127 to 2.3.3.168.

    I have several RelativeLayouts defined in code as follows:

    RelativeLayout myLayout = new RelativeLayout { BackgroundColor = Color.Green, };

    The new version of Xamarin.Forms ignores my setting the background color and displays the RelativeLayout with a white color instead.

    Tuesday, December 6, 2016 6:19 AM
  • User240159 posted

    @Franz.B said: I am also experiencing the background color bug since updating Xamarin.Forms from 2.3.2.127 to 2.3.3.168.

    I have several RelativeLayouts defined in code as follows:

    RelativeLayout myLayout = new RelativeLayout { BackgroundColor = Color.Green, };

    The new version of Xamarin.Forms ignores my setting the background color and displays the RelativeLayout with a white color instead.

    Same for me - switching from 2.3.2.127 to 2.3.3.168, causes on some views, missing BackgroundColor - it's just white. For me, it occurs only on iOS.

    Tuesday, December 6, 2016 7:24 AM
  • User221964 posted

    @pierce.boggan @ChrisHardy @JimmyGarrido

    If you add on your listview's viewcell, This will ruin every UI in cell. looks like height of root cell fits to contextactions's height which is incorrect by some reason.

    Please set your cell's height like 100. It will be reproduced.

    It happens 2.3.4-pre1 as well. It started to happen on 2.3.3 stable, 2.3.3-pre4 works fine.

    Tuesday, December 6, 2016 11:43 AM
  • User221964 posted

    @rmarinho Please see above bug. Thanks.

    Tuesday, December 6, 2016 11:47 AM
  • User221964 posted

    @rmarinho @pierce.boggan @ChrisHardy @JimmyGarrido

    This occurs on iOS 9 (tested on iPhone 5). iOS10 works fine. It happens 2.3.4-pre1 as well. It started to happen on 2.3.3 stable, 2.3.3-pre4 works fine.

    Tuesday, December 6, 2016 11:57 AM
  • User92861 posted

    @RaphaelChiorlinRanieri I can confirm the issue exists in 2.3.3 and it is not intentional! I tested with the master branch and it is fixed but it doesn't seem to have made it into 2.3.4 yet.

    @BBright Can you please put together a sample project and attach it to a new bug report so I can look into confirming this? Thanks!

    @huangjinshe I understand your frustration and I do apologize. As @pierce.boggan wrote in another thread this is one area we we want to improve on. Thank you for all the feedback you have provided and I will be looking into the bug reports you have mentioned.

    Tuesday, December 6, 2016 4:45 PM
  • User181025 posted

    @StephaneDelcroix @rmarinho @EZHart When I compile Android dlls and use them in a test project, I'm getting a runtime exception. See attached. It has to do with ExportRendererAttribute in Registrar#L117.

    I haven't tracked down the exact commit, but the issue seems to be somewhere between 4f4fae6 and 5642dd5 in history.

    P.S. My workspace is current as of commit 526.

    Tuesday, December 6, 2016 10:43 PM
  • User263 posted

    @JimmyGarrido Have filed a report on Bugzilla but figured was also worth mentioning in this thread.

    Unfortunately, the new platform-specific IsNavigationBarTranslucent does not work on iOS. Neither does attempting to manually set the Translucent property on the NavigationBar in a renderer.

    Repro project and additional notes attached to the bug report.

    My guess is that the following change (EdgesForExtendedLayout = None) in NavigationRenderer.cs prevents the view from extending its layout to fill the whole screen.

    public override void ViewWillAppear(bool animated) { UpdateNavigationBarVisibility(animated); EdgesForExtendedLayout = UIRectEdge.None; base.ViewWillAppear(animated); }

    NavigationRenderer.cs Line: 856. Commit: fc66448

    Wednesday, December 7, 2016 12:33 AM
  • User167259 posted

    Using any of the release 2.3.3 builds of xamarin forms in a UWP Desktop app if I hide the master page in a master detail setup the hamburger button disappears making it no longer possible to pop out the master page again.

    Wednesday, December 7, 2016 2:51 AM
  • User1004 posted

    @AdrianKnight we do not provide support on master or on your private branch, esp not here. Thanks for the report, but this is supposed to be already fixed.

    Wednesday, December 7, 2016 7:31 AM
  • User221964 posted

    @rmarinho @pierce.boggan @ChrisHardy @JimmyGarrido

    Thanksfully, viewcell with contextaction's height problem is gone on 2.3.3.175. Thanks again.

    Wednesday, December 7, 2016 9:29 AM
  • User2496 posted

    2.3.3 Service Release 1 was pushed, please update.

    Thanks

    Wednesday, December 7, 2016 2:00 PM
  • User76049 posted

    @rmarinho

    All good here. Thanks.

    (not quite)

    Wednesday, December 7, 2016 3:01 PM
  • User75196 posted

    Transparency bug is fixed. Great job!

    Wednesday, December 7, 2016 3:27 PM
  • User76049 posted

    @rmarinho

    In 2.3.3 the toolbaritems have gone to the bottom of the screen in UWP. Is this a new feature? if so it's an unwanted one, setting the order and priority does nothing.

    edit:

    Ahh, might be related to this.

    Need to give this a try :smile:

    https://bugzilla.xamarin.com/show_bug.cgi?id=39531

    Wednesday, December 7, 2016 3:56 PM
  • User10329 posted

    Is the following a known problem?

    I upgraded from XF 2.3.2.127 to XF 2.3.3.X and my Android status bar is clipping my ActionBar. See attached image.

    My only option is to intentionally use a different version of XF on iOS versus Android. I need 2.3.3 for iOS to fix the iOS 10 context menu crash but need 2.3.2 for Android to avoid this ActionBar clipping problem.

    Wednesday, December 7, 2016 4:59 PM
  • User2496 posted

    @NMackay do you have a Navigationbar ?

    @ShawnCastrianni.5092 different versions can/will make weird issues ... Do you have a reproduction of that case ?

    Wednesday, December 7, 2016 5:21 PM
  • User162453 posted

    @NMackay Are you seeing this on desktop or mobile? By default, the toolbar should be on the bottom on a mobile device and at the top on the desktop. (If you're seeing a different default, then we might be looking at a bug.)

    You can force the placement to the bottom or the top using page.On<Windows>().SetToolbarPlacement(...);.

    Wednesday, December 7, 2016 5:21 PM
  • User76049 posted

    @EZHart

    Thanks, It's mobile. I'd just found and tested that approach and it works fine in regular Forms apps tested on Lumia hardware. Just a bit of a problem in a Prism Forms app but that's nothing to do with Forms, I've logged an issue.

    Wednesday, December 7, 2016 5:26 PM
  • User225119 posted

    @JimmyGarrido said: @RaphaelChiorlinRanieri I can confirm the issue exists in 2.3.3 and it is not intentional! I tested with the master branch and it is fixed but it doesn't seem to have made it into 2.3.4 yet.

    @BBright Can you please put together a sample project and attach it to a new bug report so I can look into confirming this? Thanks!

    @huangjinshe I understand your frustration and I do apologize. As @pierce.boggan wrote in another thread this is one area we we want to improve on. Thank you for all the feedback you have provided and I will be looking into the bug reports you have mentioned.

    @JimmyGarrido ,I finally found a serious performance problem for Xamarin.Forms(UWP), could you let your team of member put it to the high priority? Because that problem exist since I touch with Xamarin.Forms, I almost thought this is what the Xamarin.Forms worked. https://bugzilla.xamarin.com/show_bug.cgi?id=46856

    Simply just replace some logic from TabbedPage to other pages...I think not too hard to team.

    Wednesday, December 7, 2016 5:50 PM
  • User134292 posted

    @ShawnCastrianni.5092 @rmarinho

    This might be related to this: https://bugzilla.xamarin.com/show_bug.cgi?id=45215

    http://forums.xamarin.com/discussion/78685/listview-overlaps-navigationbar-when-the-keyboard-appears/

    Wednesday, December 7, 2016 6:09 PM
  • User92861 posted

    @Franz.B @NamyslawSzymaniuk Are you still seeing this issue with 2.3.3.175? If so can you open up a bug report and attach a repro project? Thanks!

    @AlmaJensen.9398 Can you file a bug report for this and include a repro project? You can link to it in here and we'll look into it. Thanks!

    @TheEngineer Thanks for the report and info! I've opened a pull request for it.

    Wednesday, December 7, 2016 7:37 PM
  • User10329 posted

    @rmarinho In trying to recreate my ActionBar clipping problem in a test program, I was able to isolate the cause. It was this code I added in MainActivity.cs which I got from Xamarin as a workaround for another bug:

    base.OnCreate(bundle); #region Workaround: for Xamarin bug with AppCompat losing scrollview functionality Window.SetSoftInputMode(SoftInput.AdjustResize); if (Build.VERSION.SdkInt >= BuildVersionCodes.Lollipop) { Window.DecorView.SystemUiVisibility = 0; var statusBarHeightInfo = typeof(FormsAppCompatActivity).GetField("_statusBarHeight", BindingFlags.Instance | BindingFlags.NonPublic); statusBarHeightInfo.SetValue(this, 0); Window.SetStatusBarColor(Android.Graphics.Color.Black); } #endregion

    I will have to remember what this workaround was trying to resolve to determine if it is still needed.

    Wednesday, December 7, 2016 7:48 PM
  • User240159 posted

    @JimmyGarrido I'll let you know tomorrow, when I'll be able to test it on real iOS device, as on Simulator it work without issue (against 2.3.3.175) :smiley:

    Wednesday, December 7, 2016 8:00 PM
  • User10329 posted

    @JimmyGarrido @rmarinho

    Here is the original forum post that I was also suffering from that required this workaround code that is now causing the ActionBar to be clipped.

    https://forums.xamarin.com/discussion/62668/appcompat-does-not-resize-screen-with-keyboard

    I just verified that if I remove the workaround to resolve scrolling in appcompat, then the ActionBar clipping problem is resolved. However, I verified that I still can't scroll in appcompat when the keyboard is up. In fact, even with the workaround, I still can't scroll in appcompat. So this workaround from @JimmyGarrido no longer works with XF 2.3.3.

    FYI: It is really getting hard to manage all of these workarounds and bugs to get something that is production worthy.

    Wednesday, December 7, 2016 8:10 PM
  • User181025 posted

    @ShawnCastrianni.5092 Even with or without the service release, AppCompat has issues with scrolling when the keyboard is toggled on and off. I have a PR submitted on Oct 6 that should address some of the issues: https://github.com/xamarin/Xamarin.Forms/pull/422. You could see the video I attached there.

    https://github.com/xamarin/Xamarin.Forms/pull/552 should help you remove the status bar underlay XF is hard-coding. Most people should not need this, but in my use case, I need to skip this step.

    Thursday, December 8, 2016 1:53 AM
  • User180180 posted

    @JimmyGarrido the background color bug is gone and it works correctly with Xamarin.Forms 2.3.3.175

    Thursday, December 8, 2016 2:15 AM
  • User77843 posted

    Good finally, I actually desperately repaint the view with the same background color when the view value isVisible = true; as a workaround :P

    Thursday, December 8, 2016 3:29 AM
  • User240159 posted

    @NamyslawSzymaniuk said: @JimmyGarrido I'll let you know tomorrow, when I'll be able to test it on real iOS device, as on Simulator it work without issue (against 2.3.3.175) :smiley:

    Confirmed, works as expected at iOS device - no issue with Background color on 2.3.3.175, as it was on 2.3.3.168 :wink: .

    Thursday, December 8, 2016 9:02 AM
  • User176027 posted

    3 days now i am struggling with a bug in a library that i use https://github.com/TorbenK/TK.CustomMap which after updating to 2.3.3 nothing renders on the map. Just today i figured out that protected override void OnElementChanged(ElementChangedEventArgs<View> e) changed to protected override void OnElementChanged(ElementChangedEventArgs<Map> e) from MapRenderer

    i believe that is a breaking change, shouldn't be documented somewhere?

    Thursday, December 8, 2016 2:11 PM
  • User139040 posted

    ok I am trying to find a way to upgrade Xamarin Forms and now I am getting a new error when I try to compile...

    I am getting a new error with the latest alpha when I try to compile: Severity Code Description Project File Line Suppression State Error Member 'System.Reflection.Assembly' is declared in another module and needs to be imported App.Droid C:\Projects\App\packages\Xamarin.Forms.2.3.3.175\build\portable-win+net45+wp80+win81+wpa81+MonoAndroid10+Xamarin.iOS10+xamarinmac20\Xamarin.Forms.targets 62

    Anyone else getting this? if so what did you do to fix it?

    EDIT: I can compile if I dont use the build libraries by taking out [assembly: XamlCompilation(XamlCompilationOptions.Compile)].

    Thursday, December 8, 2016 4:33 PM
  • User139040 posted

    Well I think I am tracking down the problem. All my views fail to load if they have events attached in the XAML when the view is inherited. Surely this isnt meant to happen?

    EDIT: To add when I remove all my events to test if the view can even load I am getting Null references thrown in the CreateInstance now...

    EDIT2: Appears just about all events dont work anylonger, what gives?

    at System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters) [0x00016] in /Users/builder/data/lanes/4009/72366f70/source/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:667 at System.Reflection.MonoCMethod.DoInvoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00089] in /Users/builder/data/lanes/4009/72366f70/source/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:652 at System.Reflection.MonoCMethod.Invoke (System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in /Users/builder/data/lanes/4009/72366f70/source/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:680 at System.RuntimeType.CreateInstanceImpl (System.Reflection.BindingFlags bindingAttr, System.Reflection.Binder binder, System.Object[] args, System.Globalization.CultureInfo culture, System.Object[] activationAttributes, System.Threading.StackCrawlMark& stackMark) [0x00243] in /Users/builder/data/lanes/4009/72366f70/source/mono/mcs/class/referencesource/mscorlib/system/rttype.cs:5394

    I just feel like Forms keeps going backwards instead of forwards.

    Thursday, December 8, 2016 5:38 PM
  • User92610 posted

    On the topic of Android slowdown has anyone managed to improve Xamarin.Android startup times with Forms? Ours is getting unacceptable on lower end phones. I cannot find a blogpost or anything in the docs about guidelines for xamarin.android cold boot and warm boot start times

    Thursday, December 8, 2016 10:12 PM
  • User132171 posted

    Background color issue fixed for me as well. Unfortunately still having crashing issues, and so I still can't release a patched version of our stuff on iOS. Looks like there's an issue somewhere with context actions now (which is a crash we hadn't seen until applying this update):

    Application Specific Information: * Terminating app due to uncaught exception 'System.NullReferenceException: Object reference not set to an instance of an object', reason: 'System.NullReferenceException: Object reference not set to an instance of an object at Xamarin.Forms.Platform.iOS.ContextActionsCell.SetupSelection (UIKit.UITableView table) <0x101298430 + 0x0009c> in :0 at Xamarin.Forms.Platform.iOS.ContextActionsCell.Update (UIKit.UITableView tableView, Xamarin.Forms.Cell cell, UIKit.UITableViewCell nativeCell) <0x1012951e0 + 0x004c7> in :0 at Xamarin.Forms.Platform.iOS.ContextActionsCell.OnMenuItemPropertyChanged (System.Object sender, System.ComponentModel.PropertyChangedEventArgs e) <0x1012975a0 + 0x00113> in :0 at Xamarin.Forms.BindableObject.OnPropertyChanged (System.String propertyName) <0x101344c40 + 0x0005f> in :0 at Xamarin.Forms.Element.OnPropertyChanged (System.String propertyName) <0x1013bce60 + 0x00023> in :0 at Xamarin.Forms.BindableObject.SetValueActual (Xamarin.Forms.BindableProperty property, Xamarin.Forms.BindableObject+BindablePropertyContext context, System.Object value, System.Boolean currentlyApplying, Xamarin.Forms.BindableObject+SetValueFlags attributes, System.Boolean silent) <0x101346320 + 0x00223> in :0 at Xamarin.Forms.BindableObject.SetValueCore (Xamarin.Forms.BindableProperty property, System.Object value, Xamarin.Forms.BindableObject+SetValueFlags attributes, Xamarin.Forms.BindableObject+SetValuePrivateFlags privateAttributes) <0x101345710 + 0x002fb> in :0 at Xamarin.Forms.BindingExpression.ApplyCore (System.Object sourceObject, Xamarin.Forms.BindableObject target, Xamarin.Forms.BindableProperty property, System.Boolean fromTarget) <0x10134b7e0 + 0x005d7> in :0 at Xamarin.Forms.BindingExpression.Apply (System.Boolean fromTarget) <0x10134b4f0 + 0x0008f> in :0 at Xamarin.Forms.BindingExpression+BindingExpressionPart.b_470 () <0x10134ddd0 + 0x00023> in :0 at Foundation.NSAsyncActionDispatcher.Apply () <0x10191d890 + 0x00023> in <1b8eccd9010447b8b48086ab0847b072#a15ec443984bdd8b1a0e9260134dd65d>:0 at (wrapper managed-to-native) UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr) at UIKit.UIApplication.Main (System.String[] args, System.IntPtr principal, System.IntPtr delegate) <0x10192f090 + 0x0002b> in <1b8eccd9010447b8b48086ab0847b072#a15ec443984bdd8b1a0e9260134dd65d>:0 at UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) <0x10192efd0 + 0x000ab> in <1b8eccd9010447b8b48086ab0847b072#a15ec443984bdd8b1a0e9260134dd65d>:0 at WeFeelXamarin.iOS.Application.Main (System.String[] args) <0x100ed9e50 + 0x00023> in <90f546fc608c4a268f1196f92e2db5ed#a15ec443984bdd8b1a0e9260134dd65d>:0 '

    Thursday, December 8, 2016 11:43 PM
  • User140202 posted

    @JeffDalby Isolating the issue and providing a reproduction would be very helpful here for looking into this.

    Friday, December 9, 2016 12:10 AM
  • User132171 posted

    @PaulDiPietro said: @JeffDalby Isolating the issue and providing a reproduction would be very helpful here for looking into this.

    I will try when I get a moment. Again it's not consistent. Just going back and forth between pages where there is a listview with context actions will eventually cause the crash. Back rev'ing to 2.2.x fixes the problem. In the meantime until I can reproduce, was anything changed between 2.3.x in the handling of listview's on iOS, in particular dealing with them when they have a context menu?

    Friday, December 9, 2016 9:51 PM
  • User221964 posted

    @void

    Hi, void. After I was told about Mobile Center Preview, I request to use it. But never got response yet.

    Did you receive invitation reply mail something and using it currently?

    Saturday, December 10, 2016 9:19 PM
  • User258 posted

    @BBright said: @void

    Hi, void. After I was told about Mobile Center Preview, I request to use it. But never got response yet.

    Did you receive invitation reply mail something and using it currently?

    Not yet.

    Sunday, December 11, 2016 11:03 AM
  • User221964 posted

    OK Thanks for reply! @void

    Monday, December 12, 2016 5:28 AM
  • User263301 posted

    Upgrading to 2.3.3.* is causing some serious issue in our WP 8.1 (Silverlight) application.

    "Object of type 'Xamarin.Forms.RowDefinition' cannot be converted to type 'Xamarin.Forms.View'." at System.RuntimeType.TryChangeType(Object value, Binder binder, CultureInfo culture, Boolean needsSpecialCast) at System.RuntimeType.CheckValue(Object value, Binder binder, CultureInfo culture, BindingFlags invokeAttr) at System.Reflection.MethodBase.CheckArguments(Object[] parameters, Binder binder, BindingFlags invokeAttr, CultureInfo culture, Signature sig) at System.Reflection.RuntimeMethodInfo.InvokeArgumentsCheck(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters) at Xamarin.Forms.Xaml.ApplyPropertiesVisitor.TryAddToProperty(Object element, String localName, Object value, IXmlLineInfo lineInfo, XamlServiceProvider serviceProvider, Exception& exception) at Xamarin.Forms.Xaml.ApplyPropertiesVisitor.SetPropertyValue(Object xamlelement, XmlName propertyName, Object value, Object rootElement, INode node, HydratationContext context, IXmlLineInfo lineInfo) at Xamarin.Forms.Xaml.ApplyPropertiesVisitor.Visit(ElementNode node, INode parentNode) at Xamarin.Forms.Xaml.ElementNode.Accept(IXamlNodeVisitor visitor, INode parentNode) at Xamarin.Forms.Xaml.ElementNode.Accept(IXamlNodeVisitor visitor, INode parentNode) at Xamarin.Forms.Xaml.RootNode.Accept(IXamlNodeVisitor visitor, INode parentNode) at Xamarin.Forms.Xaml.XamlLoader.Visit(RootNode rootnode, HydratationContext visitorContext) at Xamarin.Forms.Xaml.XamlLoader.Load(Object view, String xaml) at Xamarin.Forms.Xaml.XamlLoader.Load(Object view, Type callingType) at Xamarin.Forms.Xaml.Extensions.LoadFromXaml[TXaml](TXaml view, Type callingType) at KDS.Mobile.Views.IntroView.InitializeComponent() in C:\Development\KDS-Release-HotFix\KDS.Mobile\KDS.Mobile\obj\Release\KDS.Mobile.Views.IntroView.xaml.g.cs:line 30 at KDS.Mobile.Views.IntroView..ctor() in C:\Development\KDS-Release-HotFix\KDS.Mobile\KDS.Mobile\Views\IntroView.xaml.cs:line 35 at Autofac.Core.Activators.Reflection.ConstructorParameterBinding.Instantiate()

    If I comment the Grid.RowDefinitions and navigate to the next screen that still uses Grid I get:

    Position 30:14. Cannot assign property "ColumnDefinitions": Property does not exists, or is not assignable, or mismatching type between value and property

    So obviously something is messed up for WP 8.1 - Silverlight ... I've created a sample project attached to this post.

    Edit: Noticed that the previous attachment was targeting WinRT ... I've attached the Silverlight version. Please note that the issue can be reproduce only in Release mode for WP 8.1 Silverlight - I've noticed that WinRT version generates the same issue independent of build configuration.

    Monday, December 12, 2016 10:44 AM
  • User210933 posted

    OK, I guess bugs don't get any attention until it's posted here, so here it goes:

    Devs, would you please take a look at this bug? Thanks

    https://bugzilla.xamarin.com/show_bug.cgi?id=47701

    Monday, December 12, 2016 5:19 PM
  • User210933 posted

    @ShanePope said: On the topic of Android slowdown has anyone managed to improve Xamarin.Android startup times with Forms? Ours is getting unacceptable on lower end phones. I cannot find a blogpost or anything in the docs about guidelines for xamarin.android cold boot and warm boot start times

    Not just Android, UWP is unacceptably slow too. But I guess even for a multiplatform the iOS gets all the attention.

    Monday, December 12, 2016 5:22 PM
  • User226799 posted

    When I use the new feature native view Declaration, there is no intellisense in xaml for paltform control. For example:

    <?xml version="1.0" encoding="utf-8"?>
    <ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
                 xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
                 xmlns:win="clr-namespace:Windows.UI.Xaml.Controls;assembly=Windows, Version=255.255.255.255, Culture=neutral, PublicKeyToken=null, ContentType=WindowsRuntime;targetPlatform=Windows"
                 x:Class="NativeViewDeclaration.NativeViewDeclarationPage">
        <ContentPage.Content>      
            <win:TextBlock Text="Native Text"/>
        </ContentPage.Content>
    </ContentPage>
    

    I have to input TextBlockmanually. Does anybody have same issue?

    Tuesday, December 13, 2016 7:07 AM
  • User311 posted

    @dpedrinha Forms is not thread-safe everywhere, so always go to the main thread when updating GUI elements. Have you tried that?

    And don't use Device.StartTimer, the Timer is one of the worst parts of Forms and just doesn't work. This PR needs to be merged: https://github.com/xamarin/Xamarin.Forms/pull/374

    Tuesday, December 13, 2016 7:18 AM
  • User210933 posted

    @rogihee said: @dpedrinha Forms is not thread-safe everywhere, so always go to the main thread when updating GUI elements. Have you tried that?

    And don't use Device.StartTimer, the Timer is one of the worst parts of Forms and just doesn't work. This PR needs to be merged: https://github.com/xamarin/Xamarin.Forms/pull/374

    Thank you for your reply.

    To be honest I first tried using Task.Delay(1000); but then I read somewhere in Xamarin docs that Device.StartTimer was better. Anyway, neither worked.

    After your reply I also tried

        await Task.Delay(1000);
        Device.BeginInvokeOnMainThread(() =>
            {
                MyLabel.Text = "bla";
             });
    

    And it didn't work. Same behavior.

    Any other thought?

    Tuesday, December 13, 2016 8:47 PM
  • User92861 posted

    @BradChase.2654 I tried reproducing this with a sample project but was not able to. Can you please file a bug report and attach a repro project? Thanks!

    @MihaiCvasnievschi1 Thank you for the repro project! I was able to reproduce the crash and I've filed a bug report

    Wednesday, December 14, 2016 11:36 PM
  • User139040 posted

    @JimmyGarrido I thought I did file a bug report on it. I'll check again, regardless you should have full access to our repro to test. All you have to do it try to upgrade it to the latest forms.

    Thursday, December 15, 2016 3:01 AM
  • User28549 posted

    Just a request on the for the Release threads on the Forum. It's a lot harder to track releases when you update the thread and change the title. I feel it would be a lot clearer if you would create one thread per update (link to the previous one if necessary).

    Friday, December 16, 2016 10:58 PM
  • User113114 posted

    @BjornB said:

    @rmarinho said: @BjornB Please provide that info in bugzilla so we can properly track it down.. Sample, and stack traces are be super helpful.

    We also identified the issue with BackgroundColor missing sometimes on iOS on 2.3.3 and we are testing the fix now will try to ship a hotfix ASAP.

    Thanks.

    Il post the bugzilla links here when its done. Im curious why you decided to remove 2.3.4 from nuget

    Turned out to be a bug caused by ModernHttpClient on C8, works well on alpha C9 https://bugzilla.xamarin.com/showbug.cgi?id=50210 https://bugzilla.xamarin.com/showbug.cgi?id=45003

    Monday, December 19, 2016 10:31 AM
  • User283146 posted

    I'm trying to use a java code in xamarin with C #, I was doing well until I got to that part:

    Inside this method, create a ContentResolver instance, retrieve the URI for external music files, and create a Cursor instance using the ContentResolver instance to query the music files:

    ContentResolver musicResolver = getContentResolver(); Uri musicUri = android.provider.MediaStore.Audio.Media.EXTERNALCONTENTURI; Cursor musicCursor = musicResolver.query(musicUri, null, null, null, null);

    Can anyone help me to adapt this part?

    Monday, December 26, 2016 11:11 PM
  • User130 posted

    @Jair_xamarin said: I'm trying to use a java code in xamarin with C #, I was doing well until I got to that part:

    Inside this method, create a ContentResolver instance, retrieve the URI for external music files, and create a Cursor instance using the ContentResolver instance to query the music files:

    ContentResolver musicResolver = getContentResolver(); Uri musicUri = android.provider.MediaStore.Audio.Media.EXTERNALCONTENTURI; Cursor musicCursor = musicResolver.query(musicUri, null, null, null, null);

    Can anyone help me to adapt this part?

    @Jair_xamarin I don't think you're going to get much attention here on that topic. This thread is about the Xamarin.Forms 2.3.3-sr1 release and your question is specific to Android and Java to C# conversion. I recommend posting in the Xamarin Platform > Android forum.

    Tuesday, December 27, 2016 4:12 AM
  • User283146 posted

    @DavidOrtinau said:

    @Jair_xamarin said: I'm trying to use a java code in xamarin with C #, I was doing well until I got to that part:

    Inside this method, create a ContentResolver instance, retrieve the URI for external music files, and create a Cursor instance using the ContentResolver instance to query the music files:

    ContentResolver musicResolver = getContentResolver(); Uri musicUri = android.provider.MediaStore.Audio.Media.EXTERNALCONTENTURI; Cursor musicCursor = musicResolver.query(musicUri, null, null, null, null);

    Can anyone help me to adapt this part?

    @Jair_xamarin I don't think you're going to get much attention here on that topic. This thread is about the Xamarin.Forms 2.3.3-sr1 release and your question is specific to Android and Java to C# conversion. I recommend posting in the Xamarin Platform > Android forum.

    But the problem is that I posted this is a problem close to a week and no one will answer me, I have already spent 3 whole days breaking my head trying to get an equivalent and nothing ... I did not know what else to do.

    To be an idea now I need help just with getcontentResolver, I'm not able to make it an instance.

    Tuesday, December 27, 2016 11:58 AM
  • User8854 posted

    InputTransparent applies to children on iOS but not Android. https://bugzilla.xamarin.com/show_bug.cgi?id=50992

    Wednesday, December 28, 2016 3:03 AM
  • User2022 posted

    Seems that with 2.3.3 the Android app always 'crash' when pressing the back-button on the masterdetail-page. So normally the app should just hide, now the activity gets destroyed everytime. This means that when opening the app again, it always will have to start over again.

    "Activity has been destroyed" at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in /Users/builder/data/lanes/3511/77cb8568/source/mono/mcs/class/referencesource/mscorlib/system/runtime/exceptionservices/exceptionservicescommon.cs:143 at Java.Interop.JniEnvironment+InstanceMethods.CallIntMethod (Java.Interop.JniObjectReference instance, Java.Interop.JniMethodInfo method) [0x00084] in /Users/builder/data/lanes/3511/ce955cc0/source/Java.Interop/src/Java.Interop/Java.Interop/JniEnvironment.g.cs:11464 at Android.Runtime.JNIEnv.CallIntMethod (System.IntPtr jobject, System.IntPtr jmethod) [0x00000] in /Users/builder/data/lanes/3511/ce955cc0/source/monodroid/src/Mono.Android/JNIEnv.g.cs:186 at Android.Support.V4.App.FragmentTransactionInvoker.CommitAllowingStateLoss () [0x00033] in <27c17fe440cf491ba8255bcefade6e02>:0 at Xamarin.Forms.Platform.Android.AppCompat.MasterDetailContainer.Dispose (System.Boolean disposing) [0x00042] in C:\BuildAgent2\work\ca3766cfc22354a1\Xamarin.Forms.Platform.Android\AppCompat\MasterDetailContainer.cs:130 at Java.Lang.Object.Dispose () [0x00000] in /Users/builder/data/lanes/3511/ce955cc0/source/xamarin-android/src/Mono.Android/Java.Lang/Object.cs:203 at Xamarin.Forms.Platform.Android.AppCompat.MasterDetailPageRenderer.Dispose (System.Boolean disposing) [0x00046] in C:\BuildAgent2\work\ca3766cfc22354a1\Xamarin.Forms.Platform.Android\AppCompat\MasterDetailPageRenderer.cs:192 at Java.Lang.Object.Dispose () [0x00000] in /Users/builder/data/lanes/3511/ce955cc0/source/xamarin-android/src/Mono.Android/Java.Lang/Object.cs:203 at Xamarin.Forms.Platform.Android.AppCompat.Platform.SetPage (Xamarin.Forms.Page newRoot) [0x0003f] in C:\BuildAgent2\work\ca3766cfc22354a1\Xamarin.Forms.Platform.Android\AppCompat\Platform.cs:226 at Xamarin.Forms.Platform.Android.AppCompat.Platform.Dispose () [0x00010] in C:\BuildAgent2\work\ca3766cfc22354a1\Xamarin.Forms.Platform.Android\AppCompat\Platform.cs:52 at Xamarin.Forms.Platform.Android.FormsAppCompatActivity.OnDestroy () [0x0002f] in C:\BuildAgent2\work\ca3766cfc22354a1\Xamarin.Forms.Platform.Android\AppCompat\FormsAppCompatActivity.cs:195 at Android.App.Activity.n_OnDestroy (System.IntPtr jnienv, System.IntPtr native__this) [0x00009] in /Users/builder/data/lanes/3511/ce955cc0/source/monodroid/src/Mono.Android/platforms/android-24/src/generated/Android.App.Activity.cs:2981 at (wrapper dynamic-method) System.Object:632037c4-bf97-4366-9df8-cfe2ce5b9b8a (intptr,intptr) --- End of managed Java.Lang.IllegalStateException stack trace --- java.lang.IllegalStateException: Activity has been destroyed at android.support.v4.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:1515) at android.support.v4.app.BackStackRecord.commitInternal(BackStackRecord.java:638) at android.support.v4.app.BackStackRecord.commitAllowingStateLoss(BackStackRecord.java:621) at md5b60ffeb829f638581ab2bb9b1a7f4f3f.FormsAppCompatActivity.n_onDestroy(Native Method) at md5b60ffeb829f638581ab2bb9b1a7f4f3f.FormsAppCompatActivity.onDestroy(FormsAppCompatActivity.java:80) at android.app.Activity.performDestroy(Activity.java:6169) at android.app.Instrumentation.callActivityOnDestroy(Instrumentation.java:1141) at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:3693) at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:3724) at android.app.ActivityThread.access$1400(ActivityThread.java:151) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1357) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:135) at android.app.ActivityThread.main(ActivityThread.java:5254) at java.lang.reflect.Method.invoke(Native Method) at java.lang.reflect.Method.invoke(Method.java:372) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)

    Are more having this issue since 2.3.3?

    Friday, December 30, 2016 4:01 PM
  • User92861 posted

    @Theos This crash looks like this bug that should be fixed in 2.3.4-pre1. Also, your post got duplicated so I cleaned those up :)

    Tuesday, January 3, 2017 6:00 PM
  • User22745 posted

    @Theos said: Seems that with 2.3.3 the Android app always 'crash' when pressing the back-button on the masterdetail-page. So normally the app should just hide, now the activity gets destroyed everytime. This means that when opening the app again, it always will have to start over again.

    "Activity has been destroyed" at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in /Users/builder/data/lanes/3511/77cb8568/source/mono/mcs/class/referencesource/mscorlib/system/runtime/exceptionservices/exceptionservicescommon.cs:143 at Java.Interop.JniEnvironment+InstanceMethods.CallIntMethod (Java.Interop.JniObjectReference instance, Java.Interop.JniMethodInfo method) [0x00084] in /Users/builder/data/lanes/3511/ce955cc0/source/Java.Interop/src/Java.Interop/Java.Interop/JniEnvironment.g.cs:11464 at Android.Runtime.JNIEnv.CallIntMethod (System.IntPtr jobject, System.IntPtr jmethod) [0x00000] in /Users/builder/data/lanes/3511/ce955cc0/source/monodroid/src/Mono.Android/JNIEnv.g.cs:186 at Android.Support.V4.App.FragmentTransactionInvoker.CommitAllowingStateLoss () [0x00033] in <27c17fe440cf491ba8255bcefade6e02>:0 at Xamarin.Forms.Platform.Android.AppCompat.MasterDetailContainer.Dispose (System.Boolean disposing) [0x00042] in C:\BuildAgent2\work\ca3766cfc22354a1\Xamarin.Forms.Platform.Android\AppCompat\MasterDetailContainer.cs:130 at Java.Lang.Object.Dispose () [0x00000] in /Users/builder/data/lanes/3511/ce955cc0/source/xamarin-android/src/Mono.Android/Java.Lang/Object.cs:203 at Xamarin.Forms.Platform.Android.AppCompat.MasterDetailPageRenderer.Dispose (System.Boolean disposing) [0x00046] in C:\BuildAgent2\work\ca3766cfc22354a1\Xamarin.Forms.Platform.Android\AppCompat\MasterDetailPageRenderer.cs:192 at Java.Lang.Object.Dispose () [0x00000] in /Users/builder/data/lanes/3511/ce955cc0/source/xamarin-android/src/Mono.Android/Java.Lang/Object.cs:203 at Xamarin.Forms.Platform.Android.AppCompat.Platform.SetPage (Xamarin.Forms.Page newRoot) [0x0003f] in C:\BuildAgent2\work\ca3766cfc22354a1\Xamarin.Forms.Platform.Android\AppCompat\Platform.cs:226 at Xamarin.Forms.Platform.Android.AppCompat.Platform.Dispose () [0x00010] in C:\BuildAgent2\work\ca3766cfc22354a1\Xamarin.Forms.Platform.Android\AppCompat\Platform.cs:52 at Xamarin.Forms.Platform.Android.FormsAppCompatActivity.OnDestroy () [0x0002f] in C:\BuildAgent2\work\ca3766cfc22354a1\Xamarin.Forms.Platform.Android\AppCompat\FormsAppCompatActivity.cs:195 at Android.App.Activity.n_OnDestroy (System.IntPtr jnienv, System.IntPtr native__this) [0x00009] in /Users/builder/data/lanes/3511/ce955cc0/source/monodroid/src/Mono.Android/platforms/android-24/src/generated/Android.App.Activity.cs:2981 at (wrapper dynamic-method) System.Object:632037c4-bf97-4366-9df8-cfe2ce5b9b8a (intptr,intptr) --- End of managed Java.Lang.IllegalStateException stack trace --- java.lang.IllegalStateException: Activity has been destroyed at android.support.v4.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:1515) at android.support.v4.app.BackStackRecord.commitInternal(BackStackRecord.java:638) at android.support.v4.app.BackStackRecord.commitAllowingStateLoss(BackStackRecord.java:621) at md5b60ffeb829f638581ab2bb9b1a7f4f3f.FormsAppCompatActivity.n_onDestroy(Native Method) at md5b60ffeb829f638581ab2bb9b1a7f4f3f.FormsAppCompatActivity.onDestroy(FormsAppCompatActivity.java:80) at android.app.Activity.performDestroy(Activity.java:6169) at android.app.Instrumentation.callActivityOnDestroy(Instrumentation.java:1141) at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:3693) at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:3724) at android.app.ActivityThread.access$1400(ActivityThread.java:151) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1357) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:135) at android.app.ActivityThread.main(ActivityThread.java:5254) at java.lang.reflect.Method.invoke(Native Method) at java.lang.reflect.Method.invoke(Method.java:372) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)

    Are more having this issue since 2.3.3?

    I know it's ugly hack, but you can use this workaround. Worked for me (put it in your MainActivity)

        protected override void OnDestroy()
        {
            try
            {
                base.OnDestroy();
            }
            catch (Exception ex)
            {
                ex.ToString();
            }
        }
    
    Friday, January 6, 2017 6:36 PM
  • User130 posted

    Greetings all,

    I want to call your attention to a small bump in the build to .180. Details at the head, but it amounts to authenticode signing of the build. That's it.

    In the future we'll be creating separate posts for each release. That's been requested and we like the idea as well.

    Friday, January 6, 2017 8:51 PM
  • User89714 posted

    Have just updated to 2.3.3.180 . Suddenly getting System.InvalidOperationException in Xamarin.Forms.ColorTypeConverter when running on UWP (I haven't tried other platforms yet). I'm wondering if, when converting a string such as "white" to a Xamarin.Forms.Color, the case-sensitivity on the string has changed. Has anybody else observed this?

    Tuesday, January 10, 2017 6:42 PM
  • User1004 posted

    @JohnHardman does it works with "White" (which is the correct capitalization of "white") ? As far as I can remember the ColorTypeConverter is case-sensitive...

    Wednesday, January 11, 2017 9:08 AM
  • User89714 posted

    @StephaneDelcroix - Yes, it does work with "White". Before updating, it also worked with "white". Not the end of the world ;-)

    Wednesday, January 11, 2017 9:32 AM
  • User89714 posted

    Using 2.3.3.180 on UWP (testing on desktop whilst my phone recharges), title bar and toolbar functionality that was previously working is now unpredictable. Regardless of whether or not I use SetToolbarPlacement, the presence of the page title and the toolbar is inconsistent. On some pages the title and toolbar appear, on other pages the title and/or toolbar do not appear. Any ideas/workarounds?

    [Edit: Now that phone has just enough charge to test on - the title line is unpredictable on the phone, although the toolbar seems more predictable than on desktop. As per desktop, the title does not always appear when pushing a new page, but then is present after later popping a subsequently pushed page. But on phone, unlike desktop, the toolbar seems to appear reliably (based on limited testing)]

    [Edit: Found the problem. In 2.3.3.180, the title line will only appear if Title was populated in the constructor of the page object. I have many pages where Title (and everything else) is populated in OnAppearing. It appears that in 2.3.3.180, if I set a dummy value for Title in the constructor, the subsequent behavior looks ok (based on limited testing)]

    Wednesday, January 11, 2017 3:12 PM
  • User183635 posted

    I have a build issue with an Android project. The Platform specific iOS isn't referenced si I can't build : 2>C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1410,2): error : Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly 'Xamarin.Forms.Platform.iOS, Version=2.0.0.0, Culture=neutral, PublicKeyToken='. Perhaps it doesn't exist in the Mono for Android profile? 2>C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1410,2): error : File name: 'Xamarin.Forms.Platform.iOS.dll' 2>C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1410,2): error : at Java.Interop.Tools.Cecil.DirectoryAssemblyResolver.Resolve(AssemblyNameReference reference, ReaderParameters parameters) 2>C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1410,2): error : at Xamarin.Android.Tasks.ResolveAssemblies.AddAssemblyReferences(ICollection`1 assemblies, AssemblyDefinition assembly, Boolean topLevel) 2>C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1410,2): error : at Xamarin.Android.Tasks.ResolveAssemblies.Execute()

    I use this version with the stable canal and last SDK revisions

    Thursday, January 12, 2017 8:52 AM
  • User229611 posted

    @MihaiCvasnievschi1 said: Upgrading to 2.3.3.* is causing some serious issue in our WP 8.1 (Silverlight) application.

    "Object of type 'Xamarin.Forms.RowDefinition' cannot be converted to type 'Xamarin.Forms.View'." at System.RuntimeType.TryChangeType(Object value, Binder binder, CultureInfo culture, Boolean needsSpecialCast) at System.RuntimeType.CheckValue(Object value, Binder binder, CultureInfo culture, BindingFlags invokeAttr) at System.Reflection.MethodBase.CheckArguments(Object[] parameters, Binder binder, BindingFlags invokeAttr, CultureInfo culture, Signature sig) at System.Reflection.RuntimeMethodInfo.InvokeArgumentsCheck(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters) at Xamarin.Forms.Xaml.ApplyPropertiesVisitor.TryAddToProperty(Object element, String localName, Object value, IXmlLineInfo lineInfo, XamlServiceProvider serviceProvider, Exception& exception) at Xamarin.Forms.Xaml.ApplyPropertiesVisitor.SetPropertyValue(Object xamlelement, XmlName propertyName, Object value, Object rootElement, INode node, HydratationContext context, IXmlLineInfo lineInfo) at Xamarin.Forms.Xaml.ApplyPropertiesVisitor.Visit(ElementNode node, INode parentNode) at Xamarin.Forms.Xaml.ElementNode.Accept(IXamlNodeVisitor visitor, INode parentNode) at Xamarin.Forms.Xaml.ElementNode.Accept(IXamlNodeVisitor visitor, INode parentNode) at Xamarin.Forms.Xaml.RootNode.Accept(IXamlNodeVisitor visitor, INode parentNode) at Xamarin.Forms.Xaml.XamlLoader.Visit(RootNode rootnode, HydratationContext visitorContext) at Xamarin.Forms.Xaml.XamlLoader.Load(Object view, String xaml) at Xamarin.Forms.Xaml.XamlLoader.Load(Object view, Type callingType) at Xamarin.Forms.Xaml.Extensions.LoadFromXaml[TXaml](TXaml view, Type callingType) at KDS.Mobile.Views.IntroView.InitializeComponent() in C:\Development\KDS-Release-HotFix\KDS.Mobile\KDS.Mobile\obj\Release\KDS.Mobile.Views.IntroView.xaml.g.cs:line 30 at KDS.Mobile.Views.IntroView..ctor() in C:\Development\KDS-Release-HotFix\KDS.Mobile\KDS.Mobile\Views\IntroView.xaml.cs:line 35 at Autofac.Core.Activators.Reflection.ConstructorParameterBinding.Instantiate()

    If I comment the Grid.RowDefinitions and navigate to the next screen that still uses Grid I get:

    Position 30:14. Cannot assign property "ColumnDefinitions": Property does not exists, or is not assignable, or mismatching type between value and property

    So obviously something is messed up for WP 8.1 - Silverlight ... I've created a sample project attached to this post.

    Edit: Noticed that the previous attachment was targeting WinRT ... I've attached the Silverlight version. Please note that the issue can be reproduce only in Release mode for WP 8.1 Silverlight - I've noticed that WinRT version generates the same issue independent of build configuration.

    Turn on the XAML compiler.

    Add to AssemblyInfo.cs this:

    using Xamarin.Forms.Xaml; [assembly: XamlCompilation(XamlCompilationOptions.Compile)]

    It's working for me.

    Friday, January 27, 2017 6:01 PM
  • User263301 posted

    @FerencCzirok.0862 said:

    Turn on the XAML compiler.

    Add to AssemblyInfo.cs this:

    using Xamarin.Forms.Xaml; [assembly: XamlCompilation(XamlCompilationOptions.Compile)]

    It's working for me.

    Sorry ... still crashing for me on WinPhone.

    Monday, January 30, 2017 9:41 AM
  • User78885 posted

    @MihaiCvasnievschi1 said:

    @FerencCzirok.0862 said:

    Turn on the XAML compiler.

    Add to AssemblyInfo.cs this:

    using Xamarin.Forms.Xaml; [assembly: XamlCompilation(XamlCompilationOptions.Compile)]

    It's working for me.

    Sorry ... still crashing for me on WinPhone.

    Same experience here - does not work on WinPhone 8.1, but works fine on Android using Xamarin.Forms 2.3.4.184-pre1

    Thursday, February 2, 2017 12:23 PM
  • User263301 posted

    @TrevBoyd said:

    @MihaiCvasnievschi1 said:

    @FerencCzirok.0862 said:

    Turn on the XAML compiler.

    Add to AssemblyInfo.cs this:

    using Xamarin.Forms.Xaml; [assembly: XamlCompilation(XamlCompilationOptions.Compile)]

    It's working for me.

    Sorry ... still crashing for me on WinPhone.

    Same experience here - does not work on WinPhone 8.1, but works fine on Android using Xamarin.Forms 2.3.4.184-pre1

    Odd enough everything works fine with the Debug version of Xamarin.Forms.Xaml I've downloaded the Xamarin.Forms code base from GitHub trying to figure out what happens. It appears that the problem was introduced in ApplyPropertiesVisitor.cs and probably around "//Simplify ListNodes with single elements". Unfortunately being a "Release" kind of error I cannot debug and figure out what happens but it appears that the code in the "simplify ListNodes" is executed for "Release" but not for "Debug".

    Thursday, February 2, 2017 12:57 PM
  • User207182 posted

    Critical bug:

    https://bugzilla.xamarin.com/show_bug.cgi?id=51238

    When setting opacity less than 1, the app crashes.

    Thursday, February 23, 2017 1:54 PM
  • User302214 posted

    Hey thanks for the additional information! I'm assuming that the Theme issue is included under the XamlC issues mentioned in that post.

    Thursday, February 23, 2017 3:45 PM
  • User53097 posted

    Here my update error.

    /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets: Error: Tool exited with code: 2. Output: trouble writing output: Too many field references: 82151; max is 65536. You may try using --multi-dex option.

    Nice.

    Friday, February 24, 2017 3:13 PM
  • User53097 posted

    Why when i add the package "Xamarin.GooglePlayServices.AppIndexing" I get another supporting package for Xamarin.Firebase? What does Firebase have to do with AppIndexing? I can not remove Firebase without AppIndexing being removed.

    Another issue is the Xamarin.GooglePlayServices.AppIndexing, requires me to install about 7 other packages that I do not need.

    Friday, February 24, 2017 3:46 PM
  • User66766 posted

    @AndrewMcCormack is moving to latest Google play services and Forms making apps go multi-dex?

    Friday, February 24, 2017 5:48 PM
  • User53097 posted

    think it was a referenced package that got updated that should NOT have.

    after a few hours of reloading packages and fighting errors, it working. My "other" comment about firebase being included in appIndexing package remains. I see no reason for this package to be included with appIndexing.

    It working again. needed to update for bug fixes.

    Friday, February 24, 2017 6:21 PM
  • User176749 posted

    @rogihee said: @dpedrinha Forms is not thread-safe everywhere, so always go to the main thread when updating GUI elements. Have you tried that?

    And don't use Device.StartTimer, the Timer is one of the worst parts of Forms and just doesn't work. This PR needs to be merged: https://github.com/xamarin/Xamarin.Forms/pull/374

    what is wrong with Device.StartTimer? I have been using it for long time in my app and havent had experienced any problem yet. I created small stopwatch i my app using it

    Sunday, February 26, 2017 12:22 AM
  • User302758 posted

    We had some issues and looking at that release again. We will try to put it up again soon next week.

    Monday, February 27, 2017 4:13 PM
  • User251790 posted

    @DavidOrtinau do you know when there is an official nuget release for this hotfix? https://github.com/xamarin/Xamarin.Forms/releases/tag/release-2.3.3-hf1

    I cannot see it here https://www.nuget.org/packages/Xamarin.Forms/

    Are there problems with this package or why is it not released?

    Wednesday, March 1, 2017 5:44 PM
  • User130 posted

    @FokkeVermeulen well, that is an official hotfix release. We have some limitations on what and when we can push to NuGet. They currently coincide with IDE and template updates.

    So stable public releases and pre-releases will appear on NuGet, but for now hotfix releases only appear on GitHub.

    Thursday, March 2, 2017 12:16 AM
  • User176749 posted

    @FokkeVermeulen said: @DavidOrtinau do you know when there is an official nuget release for this hotfix? https://github.com/xamarin/Xamarin.Forms/releases/tag/release-2.3.3-hf1

    I cannot see it here https://www.nuget.org/packages/Xamarin.Forms/

    Are there problems with this package or why is it not released?

    does this occur only on 2.3.3.193? in which cases does it occur?

    Thursday, March 2, 2017 1:18 AM
  • User210933 posted

    @DavidOrtinau said: @FokkeVermeulen well, that is an official hotfix release. We have some limitations on what and when we can push to NuGet. They currently coincide with IDE and template updates.

    So stable public releases and pre-releases will appear on NuGet, but for now hotfix releases only appear on GitHub.

    More than an year working with Xamarin and I can't remember a single stable release. I'm sorry, but they are all hotfixes for the previous "stable" release. And with new problems.

    Thursday, March 2, 2017 1:37 AM
  • User251790 posted

    @dpedrinha said:

    @DavidOrtinau said: @FokkeVermeulen well, that is an official hotfix release. We have some limitations on what and when we can push to NuGet. They currently coincide with IDE and template updates.

    So stable public releases and pre-releases will appear on NuGet, but for now hotfix releases only appear on GitHub.

    More than an year working with Xamarin and I can't remember a single stable release. I'm sorry, but they are all hotfixes for the previous "stable" release. And with new problems.

    @DavidOrtinau @dpedrinha Puhh you don't put hot fixes on nuget anymore. Wow that is crazy. So we have to check now everytime github and not the nuget-page for new releases. You are doing hot fixes and noone knows about this. Good solution. I don't know who from the company decided to not put hot fixes to nuget anymore, but yeah the last releases weren't stable releases for sure.

    I thought this hot-fix release has to go through checks or something like that and therefore it is not on nuget. Waited the hole week since I saw it the first time :(.

    Thursday, March 2, 2017 6:39 AM
  • User311 posted

    This is insane, not putting hotfix releases on NuGet.

    Thursday, March 2, 2017 10:19 AM
  • User139758 posted

    This is unbelievable... Hotfixes need to be on nuget!

    Thursday, March 2, 2017 11:00 AM
  • User180523 posted

    SO with 2.3.3.193 we also don't have the requirement of Xamarin.Android.Support.xxx being stuck at 23.3.> @DavidOrtinau said:

    @FokkeVermeulen well, that is an official hotfix release. We have some limitations on what and when we can push to NuGet. They currently coincide with IDE and template updates.

    So stable public releases and pre-releases will appear on NuGet, but for now hotfix releases only appear on GitHub.

    I'm trying to envision how to handle this in a team environment and not a 'one man operation'. Our company has a dozen Xamarin developers. We keep our own NuGet repository of approved packages, where each developer's Visual Studio only looks at the company repo. One person tests new/updated packages that are released on NuGet.org to make sure they don't break the solution or compatibility with other packages. Once a package has been vetted then it is added to our company repo and everyone sees there is an update available from there.

    Now throw into that mix that these hotfixes ARE official, but not released through the established NuGet mechanism, supported by... well... everyone... as well as Visual Studio's NuGet Package Manager and so on...

    @DavidOrtinau Given the environment I've described, how would you recommend we adjust so we can stay up to date with the official releases and yet not have everyone on the team grabbing off Github willy-nilly?

    Thursday, March 2, 2017 12:47 PM
  • User126992 posted

    @DavidOrtinau said:

    @FokkeVermeulen well, that is an official hotfix release. We have some limitations on what and when we can push to NuGet. They currently coincide with IDE and template updates.

    Shouldn't it coincide with IDE and templates updates only if there's an actual reason?

    So stable public releases and pre-releases will appear on NuGet, but for now hotfix releases only appear on GitHub.

    Since a hot fix it's actually a fix, why not release a new version on NuGet too? A new released version can be for minor updates too, it doesn't have to be only for major\many updates....

    Thursday, March 2, 2017 2:39 PM
  • User130 posted

    Hey all, I hear you. I would love every build to be on NuGet, and I'm working to make that happen. The current state is not the optimal desired state, and so I said "for now hotfix releases only appear on GitHub".

    It requires coordination as I mentioned, and if we push everything to NuGet presently it will break other experiences in the IDEs.

    Thursday, March 2, 2017 2:52 PM
  • User210933 posted

    If only the "stable" versions on nugget were stable, I could accept the hot fixes not being there. At least they would have the excuse of needing time to test. But after an year working with xamarin I sure they don't even compile a single project before releasing the stable versions. Countless updates that just stop compiling even new projects.

    Thursday, March 2, 2017 2:53 PM
  • User130 posted

    @dpedrinha said: If only the "stable" versions on nugget were stable, I could accept the hot fixes not being there. At least they would have the excuse of needing time to test. But after an year working with xamarin I sure they don't even compile a single project before releasing the stable versions. Countless updates that just stop compiling even new projects.

    We do test against projects, and we also have the pre-release process to invite the community to also test. And we are improving our internal QA overall. I very much hope to see this experience improved.

    If you have bugzilla issues or want to discuss specifics, please let me know so we can speak to concrete issues.

    Thursday, March 2, 2017 2:57 PM
  • User144259 posted

    @DavidOrtinau said:

    @dpedrinha said: If only the "stable" versions on nugget were stable, I could accept the hot fixes not being there. At least they would have the excuse of needing time to test. But after an year working with xamarin I sure they don't even compile a single project before releasing the stable versions. Countless updates that just stop compiling even new projects.

    We do test against projects, and we also have the pre-release process to invite the community to also test. And we are improving our internal QA overall. I very much hope to see this experience improved.

    If you have bugzilla issues or want to discuss specifics, please let me know so we can speak to concrete issues.

    Since we are discussing bugs, I personally would love to see the bugs that deal with basic controls not working fixed. For example, label's don't work correctly (52631, 44888, 34943)

    Also I really think the discussion about Minimum width/height not working how people expect should be revisited. (see https://github.com/xamarin/Xamarin.Forms/pull/386)

    Thursday, March 2, 2017 6:10 PM
  • User65389 posted

    @DavidOrtinau: Unfortunately, I have to confirm experience of @dpedrinha I work since about two years now with .forms and fear every update (this means not only .forms, also integration SW to VS). Therefore, I only update, if I'm forced to (sad but unfortunately true)

    So it would be nice, if your own statement in the roadmap thread would become true:

    Primary Focus Quality is top of the list. This means stability and performance first and foremost. Xamarin.Forms has been swiftly adopted as a preferred tool for delivering production apps in addition to rapid prototypes. Our focus and priorities are to support the Xamarin.Forms community in those areas. In the release schedule below, we've highlighted how and where we are making those investments.

    Thursday, March 2, 2017 6:25 PM
  • User180523 posted

    @PaulBrenner said: Also I really think the discussion about Minimum width/height not working how people expect should be revisited. (see https://github.com/xamarin/Xamarin.Forms/pull/386)

    We if we are going to revisit - how about label FillAndExpand, behaving differently than CenterAndExpand https://bugzilla.xamarin.com/show_bug.cgi?id=52541 AND the added complexity of

    if the Label is inside a vertical StackLayout then the HorizontalOptions will be ignored and the centering in the first Label is coming from the HorizontalTextAlignment instead. And the bug was closed because this is the expected behavior. Really? By whom? Not your typical coder that might have the silly idea that CenterAndExpand, EndAndExpand, and StartAndExpand might all actually Expand in the same way, and align to either center, start or end as the name implies

    I've totally given up on trying to set such values of a Label. Any more i place a grid and color and align it, then layer a Label on top of it making the entire thing appear to be one unit. Silly work arounds - but still better than building separate apps in Java, Swift and WPF for Droid, iOS and UWP respectively.

    Thursday, March 2, 2017 6:43 PM
  • User139040 posted

    @PaulBrenner I agree that Labels have alot of issues right now. We actually removed all of our StackLayouts entirely (hundreds) because they not only had issues when rendering normally also when you leave the app and then come back into the app, they would just plain cut off all text within them down to the minimum 5 pixel width.

    That said I found another one where if you have two columns in a grid and two rows, have one label in each column then one that is stretched in the second row across the two columns it will render correctly but the height gets miscalculated and will mess up the entire view underneath it getting cut off. I will try to dig through Xamarin's code when I get a chance and see if there is a fix for it.

    Thursday, March 2, 2017 8:11 PM
  • User180523 posted

    Failure while updating in place

    A solution that worked just fine with Xamarin.Android.Support.xxx libraries version 23.3.0, was updated to XF 2.3.3.193 and works fine. Then updated the Android.Support libraries from 23.3.0 to 25.1.1. Now the solution fails in that same path location due to path too long.

    Copy/paste the solution to the root of D: and builds/deploys just fine. Somehow the new libraries introduce longer paths, I guess.

    Serious pain given in our TFS environment we have branch path names to the effect of ..\tfsworkspace\company\productname\Branches\2017Q1-ticketnum-description\ then all the actual solution files and subfolders below that.

    The OS can track paths beyond 260 characters. You'd think this wouldn't be an issue in the year 2017.

    Friday, March 3, 2017 7:05 PM
  • User210933 posted

    @DavidOrtinau said: @dpedrinha said: If only the "stable" versions on nugget were stable, I could accept the hot fixes not being there. At least they would have the excuse of needing time to test. But after an year working with xamarin I sure they don't even compile a single project before releasing the stable versions. Countless updates that just stop compiling even new projects.

    We do test against projects, and we also have the pre-release process to invite the community to also test. And we are improving our internal QA overall. I very much hope to see this experience improved.

    If you have bugzilla issues or want to discuss specifics, please let me know so we can speak to concrete issues.

    Well, my last bug took a month to be seen and two more to be fixed. Last time I updated xamarin and forms my project stopped compiling and I can't even find what is wrong to report or fix it. And the same happens with 90% of the updates. Always a new bug. So it's really hard to see that quality is a top priority.

    In fact, I dare anyone come here and say otherwise. Say that they update forms or xamarin without fear and that most of the times the transition is stable, which, in my understanding, means that it will compile at least projects with the previous version.

    And let us face it, every update brings many bug reports and complains.

    But, please, don't take it as any kind of flaming or if I'm somehow saying that you are lying or provoking you in any bad way. I'm not. But I really thing you should stop every thing that you are doing right now and focus on a stable version (which means fixing some really major bugs) even if you have to refactor it and only then go back to new stuff. I see some new stuff being released and to be honest, too little improvement to the overall developer experience. I mean, not even intelisense works out of the box and even after a bunch of workarounds, it still doesn't work as it should. So unless this is related to a partnership with Resharper, I really think this should be a top priority. Along with basic layout and event bugs and so on. I'm pretty sure the community would take those fixes a lot better than new stuff.

    Not even the install package is being updated! To be honest, I keep having to format my computer just because of Xamarin. Why? Because every time something goes wrong with an update, I end up screwing it all trying to fix it. To make things worse, I can't even make a clean uninstall of all it's components (another thing that xamarin install package should provide). So I have to format my computer and install it all over again. Ok, I'm dealing with it, it's just one day every couple of weeks doing this formatting job (just a little bit of sarcasm). But there's more to it, for instance: the install package has the option to install UWP emulators. And guess what? VS2015 can't find them and takes me to the download page every time after a clean install. And the main problem to me is that it adds around 5gb to my SSD drive (which is a huge problem). So it's not replacing the ones installed by xamarin, it's installing it somewhere else. And I'm too afraid to look for the other ones, delete it and have to format my computer again. And there's more! Some updates don't allow me to keep working on the same project. Some times I need to create a new project, set it up all over again and copy every thing to this one. Why? I have no idea, maybe it's my fault screwing all up trying to fix the last bug, maybe is my SSD being full all the time even though I have only Windows 10 and Xamarin installed, who knows. The point is that I didn't have any problem like this with any other platforms before. Working with Xamarin is exhausting and I spend more time trying to make it work than coding!

    Seriously, Xamarin is too old to have such elementary problems and this is not looking good in the dev community. That's why I really think you should stop every thing, and make a stable version, fix the intellisense problem, update the install package and then, go back to minor bugs and improvements.

    All other dev companies I know don't want to work with Xamarin. There are many other options for multiplatform development way more attractive than Xamarin and you know why? Not because they are better. No! Xamarin has a way better result then them. But because they are stable! People get interested in Xamarin because of it's goal but soon after installing and trying it they face way too many problems right out of the box! If I didn't hate HTML more than any other language I would have forgotten Xamarin a long time ago. But I'm 'this' close to go native.

    Please take it as a friendly suggestion. I'm sure you and the rest of your team are way over my league and I have no idea what the Xamarin team size is or what you are going through. But I really feel this is the way to go. Maybe ask the community. Send everyone an e-mail inviting for a quiz about what they want the most. It would even earn you some credit with your users. I know I would like it. Some times I get the feeling that Xamarin is being forgotten and it's just a matter of time for all my effort in it goes to the toilet. Have you heard about the almost dead Apache Flex (former Adobe Flex) project? Well, I took that punch really hard and I really feel you are going the same way. But for what it's worth, it worked great, and in a lot less time they got way further than Xamarin. Sadly Steve Jobs killed it, because of his competition with Adobe softwares, forbidding their apps in iOS devices. But it's open source now, and they did a really good job similar to Forms. Xamarin could learn a lot from their structure.

    Thanks for reading, sorry for the rambling. I really just want to help. I really believe and hope Xamarin will take off.

    Best regards

    Friday, March 3, 2017 7:20 PM
  • User42522 posted

    @ClintStLaurent said:

    Failure while updating in place

    A solution that worked just fine with Xamarin.Android.Support.xxx libraries version 23.3.0, was updated to XF 2.3.3.193 and works fine. Then updated the Android.Support libraries from 23.3.0 to 25.1.1. Now the solution fails in that same path location due to path too long.

    Copy/paste the solution to the root of D: and builds/deploys just fine. Somehow the new libraries introduce longer paths, I guess.

    Serious pain given in our TFS environment we have branch path names to the effect of ..\tfsworkspace\company\productname\Branches\2017Q1-ticketnum-description\ then all the actual solution files and subfolders below that.

    The OS can track paths beyond 260 characters. You'd think this wouldn't be an issue in the year 2017.

    You should update only Xamarin.Forms. Don't touch anything else.

    I think you just reinstall Xamarin.Forms from the NuGet. It will get what all it wants.

    Friday, March 3, 2017 7:31 PM
  • User180523 posted

    @ShantimohanElchuri

    You should update only Xamarin.Forms. Don't touch anything else. Up to and including forms version 2.3.3.180 that's true. The limitation of 23.3.30 exists. I've made a big, loud point of not updating these packages here on the forum and on my site.

    But...

    As of forms 2.3.3.193 and latest Xamarin for Visual Studio Cycle 9 that limitation is gone. (see photo at end showing GreaterThanOrEqualTo 23.3.0 I've successfully updated other test projects just fine. Even this project updates and runs fine - so long as the path is kept a little shorter. (Other thread with more detail)

    That's bug I'm reporting here in the threads specific to 2.3.3.193 - that the paths have grown when you do the android.support updates.

    But if you keep the paths shorter, the updates work.

    Friday, March 3, 2017 7:44 PM
  • User134292 posted

    @ClintStLaurent Same problem here. I was hoping that updating the support library to 25 would fix some problems with Android bindings...

    Friday, March 3, 2017 7:44 PM
  • User180523 posted

    @LGMaestrelli My workaround was to remap my local TFS workspace, trimming off all the leading stuff... D:\tfsworkspace\company\productname\Branches\2017Q1-ticketnum-description\ D:\Branches\.. D:\Trunk\

    To be fair to Xamarin... Its virtually impossible to mimic all the weird business behaviors that a company might have in place for years. That's why there are mechanisms to report this situations.

    Some of it is just 'real world' stuff though. Any company that makes software for clients is going to have longer paths. ..\client\year\projectnumber\ticket\blah isn't really all that uncommon in grown up world. Freelance contractors probably see this more than anyone since they have to file things by client and so on, making the paths deeper than one company might have.

    Friday, March 3, 2017 8:03 PM
  • User130 posted

    @dpedrinha we are resolving regressed issues for our next stable release and driving to get that candidate out. Lots of stability improvements in there. We've been very aggressively working open bug reports with support. We're moving in a good direction there as well.

    I'm going to reach out directly to discuss some of your specific issues.

    Friday, March 3, 2017 11:16 PM
  • User180523 posted

    @DavidOrtinau said: Lots of stability improvements in there. We've been very aggressively working open bug reports with support. We're moving in a good direction there as well.

    DO NOT UPDATE TO VS2017RC

    Can't make a new Xamarin solution. Can't select solution type (PCL/Shared). Solution templates are hosed (per every time) https://forums.xamarin.com/discussion/89979/do-not-update-vs2017rc/p1?new=1

    Saturday, March 4, 2017 1:20 AM
  • User103333 posted

    @ClintStLaurent said:

    @DavidOrtinau said: Lots of stability improvements in there. We've been very aggressively working open bug reports with support. We're moving in a good direction there as well.

    DO NOT UPDATE TO VS2017RC

    Can't make a new Xamarin solution. Can't select solution type (PCL/Shared). Solution templates are hosed (per every time) https://forums.xamarin.com/discussion/89979/do-not-update-vs2017rc/p1?new=1

    Its a RC you shouldn't consider it as an UPDATE, its just for testing.

    I'm having a problem with Android (Appcompat) and a TabbedPage, all of the childs onAppearing are triggered when I swipe them, is this the intended functionality?

    Saturday, March 4, 2017 2:53 AM
  • User311 posted

    @MiguelCervantes https://github.com/xamarin/Xamarin.Forms/pull/354 perhaps?

    Saturday, March 4, 2017 8:44 AM
  • User180523 posted

    @MiguelCervantes said: Its a RC you shouldn't consider it as an UPDATE, its just for testing.

    That was bad verbiage on my part. It should have said, "Do not update working VS2017RC", or "Do not update ~~to~~ VS2017RC"

    As I said on the post that link goes to:

    If your VS2017RC is making new Xamarin solutions DO NOT UPDATE IT.

    I didn't mean to imply 2017 as an update to 2015. But rather the latest update for 2017 is busted. I was in such a hurry to put the warning out I kinda typo'ed the headline and now can't edit the post (>4 hours later).

    Saturday, March 4, 2017 11:23 AM
  • User221964 posted

    I also think Xamarin team has been aggressively working open bug report with support. And they're listening and discuss altogether as possible as they can.

    I understand someone who is tired. I am too. But once I imagine how this Xamarin is built, we can imagine so many bugs pops up on every different devices and platform. I think it's an endless job. I like Xamarin and want to say thanks to them.

    Saturday, March 4, 2017 1:08 PM
  • User225542 posted

    @dpedrinha said: .But I'm 'this' close to go native.

    What this guy said.

    I know you Xamarin fellers are good nature fellars and have a lot of intelligence behind you. I don't know what you're testing in or how your environments are set up - but it's been an amazing and challenging journey for me to release my apps using Xamarin. Your bugs and places where your platform goes sideways on a developer needs to be addressed. You know what they are.

    At first I was grateful for the challenge. It made me a stronger and better developer. It did. I will always appreciate this platform for that experience. It made me UNDERSTAND what was being assembled and processed. It was almost morale defeating to come across cryptic and ungooglable errors - but I prevailed. "Damn it, I love this platform and this is doable! Regardless of silence and barren stackoverflow threads!" is what I thought as I pressed to release my applications.

    Now, I'm worn out. I got really excited about seeing updates to Xamarin.Forms. I upgraded everything believing in you guys. Now...things go silent and weird for me. Me, being a semi-novice and psuedo intermediate developer, can't even explain what the hell is going on. I just know that intellisense isn't working and god knows what else is lurking beyond my vision.

    I'm going to sit and ponder about this, but it really feels deflating and a bit like being betrayed. I mean, objective c is nasty looking to my eyes, but I do not think I would leave so frustrated after assembling a code base.

    Sunday, March 12, 2017 2:00 AM
  • User8854 posted

    I know this is not the correct thread to complain about other things than the update. I want to say just a few things. I had the opportunity to assist to Xamarin Evolve 2014 to take the certification training and assist to all talks, since then I've been using Xamarin for my clients. I can tell the poor performance of Xamarin.Forms on Android since the beginning and is a really annoying issue. Xamarin.Forms's team takes a lot of time fixing major bugs, I spend some time with workarounds to make some things works. There are new bugs on every update and some old bugs come alive with new updates.

    In other hand, the improvements are remarkable, nobody can say otherwise. When I read all the complains here sometimes I feel lucky because I'm not having most of them. In my experience, I have problems when I am making use of a lot of third party libraries and to be honest is not Xamarin's fault. Some developers wants to use Xamarin.Forms for cases that merit use of another technology or they're using Xamarin.Forms in a wrong way, listviews inside listviews for example exactly. Personally I take my time to upgrade any library on my projects to avoid unnecessary problems and this is common sense.

    I'm using Xamarin Studio and I'm not having any problems with Intellisense, compiling problems or any kind of IDE problems that you guys are facing with VS. Everything just works really good.

    I can not be more agree that Xamarin must improve the performance on Android (it's sucks) and stop adding new features. I really don't know what's the logic behind that. It could help if they hire more developers for Xamarin.Forms to reduce the time between updates and please focus on major bugs.

    Sunday, March 12, 2017 4:37 PM
  • User239635 posted

    can someone advise what to do with this issue after updating to latest Xamarin?

    System.IO.FileNotFoundException: Could not load file or assembly '/Users//Library/Developer/CoreSimulator/Devices/2096BE71-5E72-4292-B61C-2CA47177E88B/data/Containers/Bundle/Application/A536F063-475E-4AB6-A852-BA098F8EA7F4/.app/en/.resources.dll' or one of its dependencies

    Tuesday, March 21, 2017 1:11 AM
  • User221964 posted

    @AnatoliiB Did you try - update Xamarin Studio and other else - remove bin and obj folder for each platform folder(forms/iOS/Android) - clean & rebuild - delete the app and reinstall on the simulator or device.

    Tuesday, March 21, 2017 1:46 AM
  • User239635 posted

    @BrightLee said: @AnatoliiB Did you try - update Xamarin Studio and other else - remove bin and obj folder for each platform folder(forms/iOS/Android) - clean & rebuild - delete the app and reinstall on the simulator or device.

    Should I try that with new / update of Xamarin or with downgraded version? I am trying the downgrades now and going back to VS studio 4.3.0.784 didn't resolve this. ....

    Tuesday, March 21, 2017 2:03 AM