Pre-release: Xamarin.Forms 2.4.0.275-pre3

1234579

Posts

  • DnielBugaDnielBuga USMember ✭✭

    First of all, I've already written this post but it got deleted when I tried to edit...

    I got hit by two exceptions after updating. One is a TypeLoadException, the other was a MethodMissingException.
    The first one occurred right after updating to 2.4, it was fixed by clearing the solution. The app installed and ran fine.
    The second one occurred after I changed some code and tried to run the app. Built, installed fine, but trying to access an SQLite table caused the exception. Again, it went away after clearing.

    Linking is set to None but it looks as if the linker would cut out a whole assembly or parts of it. Is it a build process fault or is LineageOS pulling a prank on me on my non-supported tablet?

    This happened for my android build, uwp runs just fine.

  • anton.emelyancevanton.emelyancev USMember ✭✭

    I'm experiencing wierd thing with new XF pre-release:
    Updated only XF to 2.4.0.266-pre1 and my VS for Mac can't open any xaml file (or any grouped file with EmbeddedResource) if using Netstandard library project type (created new Netstandard lib from scratch, not updated PCL one). If trying to build project, getting compile time error about duplicating embedded resource files (there is known issue with netstandard projects in VS for Mac that xaml resources duplicated in solution explorer). Rolling back to XF 2.3.5 pre-6 removes issue.
    Anyone else getting such issues?

  • BradChase.2654BradChase.2654 USMember ✭✭✭
    edited August 2017

    @DavidOrtinau I have not had time to bring this up or file a defect so forgive me but I noticed that the "Behavior change: Calling Focus on a Picker on WinRT/UWP will now open the drop down." addition is still in there. This is a major problem on UWP and we have it removed in our custom fork of Xamarin.Forms because focusing in UWP is a bit different than Android and iOS. If something unfocuses it seems to always refocus the other controls meaning it will focus say the first Picker in the view, causing the drop downs to open constantly! Its very annoying and unexpected to see random pickers constantly opening when your mouse is no where near them.

    Also I ask, is this a feature you really want to have on a desktop? It doesnt make any sense to me... So those are my thoughts but I believe this will either need reworked or (imho) removed entirely.

    EDIT: To add I have a bunch of fixes for UWP in our fork that I have been planning on putting up, just havent the time yet. Note that UWP cannot be deployed to store in its current state. It fails Microsoft testing.

  • KyleWarrenKyleWarren USUniversity ✭✭
    edited August 2017
    I can't update to 2.4.0.266pre1. Keep getting "The attribute 'Remove' in element None is unrecognized. c:\...\packages\Xamarin.Forms.2.4.0.266-pre1\build\netstandard1.0\Xamarin.Forms.props"

    I was on all the nightly builds until this.
  • PhilipGruebelePhilipGruebele USMember ✭✭

    2.4 pre1 Works normally with my Android app. Just make sure you rebuild the solution. Just in case I also delete the app, mono, and xamarin APKs from the phone.

    @DavidOrtinau Is this build compatible with the just-released .NET Standard 2.0 Nuget?

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @PhilipGruebele we have tested 2.4-pre1 with .NET Standard 2.0 projects and didn't find any problems.

    If you have other dependencies that are not yet compliant, you may need to add something like:

    <PackageTargetFallback>portable-net45+win8+wpa81+wp8</PackageTargetFallback>

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    Thanks all for initial feedback on 2.4-pre1. Working through it and we'll report back.

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @BradChase.2654 I'm reviewing it and will discuss with the team.

  • anton.emelyancevanton.emelyancev USMember ✭✭

    Okay, I can confirm issue I'm experiencing:
    1. Create from scrath Netstandard library (tested 1.4 and 2.0) and add XF 2.4 package
    2. Add xaml page (or just copy existing page here). It will be displayed in solution explorer as duplicated xaml (old issue with netstandard, but previously not caused any errors)
    3. Try to open new xaml file - VS shows error message without any text on it and opens empty tab for page. If you try to close that tab - VS crashes.
    4. If you upgrade PCL project with 2.4 XF to Netstandard - we can open xaml and compile without any issue.

    My environment:
    Visual Studio for Mac (latest stable update)

  • KennethGlaweKennethGlawe USMember

    My app is crashing on startup when the starting page wrapped in standard NavigationPage loads after I updated to 2.4.0.266-pre1

    D/dalvikvm(22988): no method with name='getElevation' signature='()F' in class Lcom/xamarin/forms/platform/android/FormsViewGroup;

    The page is just a scrollview with two buttons and no design at all.

    Is it related to this?

    Deprecation: Android IVisualElementRenderer.ViewGroup is now obsolete. Please use View instead.

  • BjornBBjornB USMember ✭✭✭

    @KennethGlawe what is your target platform?

  • KennethGlaweKennethGlawe USMember

    @BjornB 7.1 and it works when running on phones with higher Android version but dies on my test phone which is running 4.4.
    https://bugzilla.xamarin.com/show_bug.cgi?id=58868

  • BjornBBjornB USMember ✭✭✭

    One might wonder how that passed QA..

  • rogiheerogihee NLMember ✭✭✭

    This should really be covered by UITests, I thought Xamarin bought a company a while ago for that :-).

  • DnielBugaDnielBuga USMember ✭✭

    @ClintStLaurent said:
    !?
    So at least another 6 months before we see the next stable release?

    I don't know, let's see how it goes. FYI: https://github.com/xamarin/Xamarin.Forms/releases/tag/beta-2.4.0-pre1

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @rogihee said:
    This should really be covered by UITests, I thought Xamarin bought a company a while ago for that :-).

    More tests!

    https://blog.xamarin.com/beginners-guide-contributing-xamarin-forms/

  • FactoryOptimizrFactoryOptimizr USUniversity ✭✭

    @BradChase.2654, "Calling Focus on a Picker" is when you invoke the picker's .Focus method programmatically, no? Shouldn't have any impact on the Focused or UnFocused events, and shouldn't have the consequences you talked about in desktop mode. I'm definitely one of those who needs to be able to pop up the picker's selection screen programmatically. I've been waiting patiently for this for a LONG time!

  • BradChase.2654BradChase.2654 USMember ✭✭✭

    @FactoryOptimizr Unfortunately in UWP Focus is called on the picker quite a bit without interaction from the user. When another control unfocuses, the Picker will focus automatically. Also happens when view's IsVisible is changed.

    Also and correct me if I am wrong but Microsoft did not the design the UI to behave the way you are using it. Focus should focus but take no more actions than that. Usually in Desktops to bring down the selection, you hit another key to do so.

    Have you thought about maybe extending the renderer yourself to open the picker on focus? I could write you a very quick renderer if you need more info on it.

  • FactoryOptimizrFactoryOptimizr USUniversity ✭✭

    @BradChase.2654, I see your point. In Xamarin Forms, however, there's a (strong) argument to be made for the same code resulting in consistent behavior across platforms. So if .Focus opens the picker in iOS and Android, it should do the same in UWP...else over time we'll end up with more and more platform-specific exceptions for which we'll have to write work-arounds and custom renderers and what-not. While I'm all for aligning Xamarin Forms as much as possible with the Windows development vernacular, the whole point of Xamarin Forms is to create a common-denominator that brings us closer to the holy grail of "code once, deploy anywhere." We'll never get there, of course, since each platform has its own unique "special sauce" that's not really translatable into another platform's vernacular. But THAT is where I want to spend my time writing platform-specific code, not in the "bread-and-butter" stuff that really should apply across platforms.

  • PaulDiPietroPaulDiPietro USXamarin Team Xamurai

    @BradChase.2654 / @FactoryOptimizr The current implementation was based around GotFocus on the actual ComboBox control, which was causing the unintended behavior. It makes more sense to hook into Element.Focused instead, and it's also possible to directly track the Popup part of the ComboBox template. Ignoring a FocusState.Keyboard type of focus also allows you to tab through controls on a page without the pickers automatically opening, but if something such as a button calls Focus() on a picker and the user "clicks" it pressing the enter key, it will only focus the picker and not open the dropdown, but that could make sense depending on how you look at it.

    I can potentially put a PR up that would show a (hopefully) better solution, but we of course welcome different opinions with the possibility of removing the behavior entirely or theoretically moving it into a platform specific.

  • FactoryOptimizrFactoryOptimizr USUniversity ✭✭

    @PaulDiPietro, a step back to look at the requirement independent of implementation. We simply need a method that opens the picker's pop-up list.

    Today, the .Focus method does that for iOS and Android, but not UWP. And as @BradChase.2654 mentioned, the proposed UWP solution has some unintended side-effects in a mouseable/clickable environment like the desktop.

    Is there a way to implement a .Focus method so that a) it does what we expect it to do, and b) the behavior is consistent in all environments? (Okay...and c) without unintended side-effects.)

    I'm confident I'm not the only one who wants my Xamarin Forms solution to work in BOTH touchable and clickable environments (without a lot of tedious hacks and platform-specific workarounds).

  • BradChase.2654BradChase.2654 USMember ✭✭✭

    @FactoryOptimizr @PaulDiPietro Yea I am definitely understanding of both routes. I would love a discussion on it as well Paul, I think it might open some real avenues that differentiate what Mobile and what Desktop really means. Now I know thats a very verrrryyyyyyyy deep discussion and by all means dont want to dive into that life long journey, especially as the two are converging.

    @FactoryOptimizr That does lead me into questioning what is best for the desktop? Convention says users are most likely going to react to how the controls USED to work (on desktop). I am not sure if it makes sense currently to change that way of thinking with Xamarin.Forms as much as we would like to with making sure the same expected reactions happen on all platforms regardless of touch, keyboard, mouse, or any way of input.

    I think it might be best to hold expected outcomes per OS and have the UI behave as expected natively per that OS. That brings up of course, a crap ton of different arguments in and of itself, but I would love to discuss them, lets start a thread on it I think.

    I can give some personal testament to how the users expect certain reactions to their input and for us, they want what they are used to on desktop. I find them more forgiving on new controls on the Mobile side.

    As far as whats possible, as Paul stated -- anything is possible. On the developer side, any of us can create a custom renderer, as I have done around the current state of the renderer. So I think whats best for all of our users will be the correct choice.

  • BradChase.2654BradChase.2654 USMember ✭✭✭

    @FactoryOptimizr haha I think we posted around the same time. I agree. I think all the UI systems have neglected the Focus quite a bit. It can be extended to allow for a type of focus. That brings another level of complexity unfortunately and might undermine the use of tap, keyboard, or click. So maybe we stick with opening it on tap instead of focus? Keep it touch only and still stay within the user's predefined notions.

    It is wayyy too late here but thanks for getting my head spinning before bed time! hah.

  • MihaMarkicMihaMarkic SI ✭✭✭✭

    Anybody seeing this after latest pre1 upgrade?
    error : Duplicate 'EmbeddedResource' items were included. The .NET SDK includes 'EmbeddedResource' items from your project directory by default. You can either remove these items from your project file, or set the 'EnableDefaultEmbeddedResourceItems' property to 'false' if you want to explicitly include them in your project file. For more information, see https://aka.ms/sdkimplicititems. The duplicate items were: 'App.xaml'; [lists all XAML files in project]

  • FactoryOptimizrFactoryOptimizr USUniversity ✭✭
    edited August 2017

    @BradChase.2654, this is really a question of "interface" vs. "action". No matter whether your interface is touch/tap-able or mouse/click-able or voice/shout-able or AR/VR/wave-your-arms-in-the-air-able, the action is the same. In this case, the action is to show the picker's pop-up list. The action is related to the control's paradigm, and the picker/combobox paradigm has been around a long time -- people expect this behavior no matter the platform or interface. It's the tool-builder's responsibility for how the action gets wired into the framework...preferably in a way that's intuitive for users and so that it doesn't have unexpected side-effects for the developers. (@PaulDiPietro has an unenviable task in this regard!)

    In this case, the Xamarin Forms convention has been to associate this action with the .Focus method, and that's worked well for Android and iOS and the touch/mobile interface. But then comes UWP -- the new kid on the block -- with its new-fangled notions of using an adaptive UI across multiple interface paradigms (which is likely to get really intense next year with Andromeda). What worked before doesn't necessarily work for all the new use-cases. But... the requirement is the same: we just need a way to show the picker's pop-up list. Maybe that isn't the .Focus method going forward...maybe it's a new ".ShowPopUpList" method or some such. Fine...just as long as we have the ability and the implementation is consistent across platforms. But to preserve consistency, that may mean that .Focus needs to change, too. (Unless @PaulDiPietro can think of a creative way out of this...).

    (And as Forrest Gump said, "That's all I have to say about that." :smile: )

  • DidsDids FIMember ✭✭
    edited August 2017

    @MihaMarkic said:
    Anybody seeing this after latest pre1 upgrade?
    error : Duplicate 'EmbeddedResource' items were included. The .NET SDK includes 'EmbeddedResource' items from your project directory by default. You can either remove these items from your project file, or set the 'EnableDefaultEmbeddedResourceItems' property to 'false' if you want to explicitly include them in your project file. For more information, see https://aka.ms/sdkimplicititems. The duplicate items were: 'App.xaml'; [lists all XAML files in project]

    YES! I thought I messed something up and couldn't seem to get it working again, no matter what I tried. Never thought it would be the new preview version of XF that's causing it.

    EDIT: I feel like it might be related to the IDE version too, since something according to this it's now embedding resources automatically: https://blogs.msdn.microsoft.com/shaneosborne/2017/01/31/breaking-changes-in-visual-studio-2017-rc-build-26127-00/

    EDIT 2: Simply adding a new Xamarin.Forms Content Page (XAML) throws the error again though.

  • MihaMarkicMihaMarkic SI ✭✭✭✭

    It turns out there is already a bug report in bugzilla

  • DidsDids FIMember ✭✭

    @MihaMarkic said:
    It turns out there is already a bug report in bugzilla

    Just out of curiosity, if you downgrade back to pre6, are you still seeing "duplicate" entries in the solution explorer?
    Eg. something like this:

    - App.xaml
      - App.xaml.cs
    - App.xaml
    

    So far I haven't been able to fix this, even though it seems to be more of a visual issue than anything else.

  • MihaMarkicMihaMarkic SI ✭✭✭✭

    @dids I fixed that manually in csproj file first thing after adding them - adding them is a mess.

  • DidsDids FIMember ✭✭
    edited August 2017

    @MihaMarkic Doesn't work for me, unfortunately (VS4Mac stable). After I add a new XAML ContentPage, it looks fine in the IDE, but if I close and reopen the IDE the duplicate is there immediately. Fixing the csproj manually produces same results, or even worse in some case. Not sure if it's related to it being a .NET Standard library, but I'm pretty sure I haven't ran into this issue before, at least not like this where I can't fix it.

    EDIT: Never mind, found a fix. When adding a new XAML ContentPage, both the "Compile" and "EmbeddedResource" need to be set to "Update" instead of "Include". The XAML page is set to "Include" by default though, which is what causes the issue.

    EDIT 2: That breaks the binding between the .xaml and .xaml.cs files though, sigh.

    EDIT 3: Okay, had to additionally mark the .xaml files as embedded resources in the IDE properties. Works now.

  • MihaMarkicMihaMarkic SI ✭✭✭✭

    @dids sorry, I'm on VS. No idea how it is handled on VS4M (obviously not too well :( )

  • MichaelRumplerMichaelRumpler ATMember ✭✭✭✭✭

    I tried to update XF to 2.4, but I got an error in my xaml. I define a constant depending on the idiom in my app.xaml:

    <x:Double x:Key="IconColumnWidth">
        <OnIdiom x:TypeArguments="x:Double" Phone="30" Tablet="40" />
    </x:Double>
    

    This worked fine in 2.3.4.267, but with 2.3.5.233-pre1 and 2.4.0.266-pre1 I get:

    Can not set the content of x:Double as it doesn't have a ContentPropertyAttribute

    Filed bug 58922.

  • JoeMankeJoeManke USMember ✭✭✭✭✭

    Couldn't you do just use the OnIdiom item as the resource?

    <OnIdiom x:Key="IconColumnWidth" x:TypeArguments="x:Double" Phone="30" Tablet="40" />

  • KyleWarrenKyleWarren USUniversity ✭✭
    @JimmyGarrido any chance this will be fixed relatively quickly? I would hope I wouldn't have to wait for all the bugs being reported here just to install the nuget for those of us still using VS15.
  • DarshanJSDarshanJS USMember ✭✭✭

    Guys i am also facing same issue all of the sudden my Xaml Design changes which i am trying to do is not applying to project and then i tried to update the XF Package and i am getting error like this

    _The attribute "Remove" in element is unrecognized. _ i am using VS2015.
    How to get rid of this, if i install lower versions then also throwing error because of this Version 2.4.0.266

  • iiiiiiiiiiiiiiiiiiii USMember ✭✭

    Hi, I am having some errors when trying to compile new version of Xamarin Forms 2.4.0.266-pre1. I am always getting this error:

    "The attribute "Remove" in element is unrecognized. ...\Xamarin.Forms.2.4.0.266-pre1\build\netstandard1.0\Xamarin.Forms.props".

    Does anybody know what could be causing this?

    Thank you very much in advance.

  • MichaelRumplerMichaelRumpler ATMember ✭✭✭✭✭

    @JoeManke said:
    Couldn't you do just use the OnIdiom item as the resource?

    <OnIdiom x:Key="IconColumnWidth" x:TypeArguments="x:Double" Phone="30" Tablet="40" />

    This works! And it removes the redundant type definition.
    Thank you!

  • MichaelRumplerMichaelRumpler ATMember ✭✭✭✭✭
    edited August 2017

    In XF 2.4 the Xamarin.Forms.Platform.Android.EntryRenderer and EditorRenderer use a FormsEditText instead of the old EntryEditText and EditorEditText respectively. The old classes have been removed with PR #927 by @EZHart . Therefore every dll using one of those renderers must be recompiled with 2.4 or it won't load.

    My MR.Gestures uses every renderer they have and therefore I also have to recompile. But I also still support WinPhone and Windows Runtime. As Microsoft ceased to support these platforms in VS2017 I have to use VS2015 for that solution. But unfortunately XF 2.4 cannot be installed in VS2015.

    This not only affects MR.Gestures. The DevExpress Grid also doesn't work with XF 2.4 on Android.

    Instead of removing those classes, they should still be included in the dll, inherit from FormsEditText and marked as obsolete. You can remove them later on.

    PS:
    To be more specific: The app compiles in debug mode, but it crashes as soon as one of the types inheriting from EntryRenderer or EditorRenderer should be loaded. I get a

    TypeLoadException: Could not resolve type with token 010000d5 (from typeref, class/assembly Xamarin.Forms.Platform.Android.EditorEditText, Xamarin.Forms.Platform.Android, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null)

    In release mode the linker raises an error:

    Mono.Linker.MarkException: Error processing method: 'System.Void DevExpress.Mobile.DataGrid.Android.TextEditorRenderer::OnElementChanged(Xamarin.Forms.Platform.Android.ElementChangedEventArgs`1<Xamarin.Forms.Editor>)' in assembly: 'DevExpress.Mobile.Grid.Android.v17.1.dll' ---> Mono.Cecil.ResolutionException: Failed to resolve Xamarin.Forms.Platform.Android.EditorEditText

  • MichaelRumplerMichaelRumpler ATMember ✭✭✭✭✭

    I added these classes to Xamarin.Forms.Platform.Android:

    [Obsolete("Has been replaced with FormsEditText")]
    public class EntryEditText : FormsEditText
    {
        internal EntryEditText(Context context) : base(context) { }
    }
    
    [Obsolete("Has been replaced with FormsEditText")]
    public class EditorEditText : FormsEditText
    {
        internal EditorEditText(Context context) : base(context) { }
    }
    

    Compiled it and used that dll instead of the standard one. This got the DevExpress Grid and MR.Gestures working.

Sign In or Register to comment.