Xamarin.forms: [Bug] No text shown for RadioButton

[lee-m]

Description

Despite setting RadioButton's Text property, no text is shown on the page on Android. Tried testing on iOS but having some issues getting the test project running on my Mac.

Steps to Reproduce

1. Create a new basic XF app
2. Take the example XAML from the RadioButton docs page and add it to the MainPage as-is
3. Run the app

Expected Behavior

Value set for the Text property is shown.

Actual Behavior

Only the button part of the control is shown with no text visible.

Basic Information

• Version with issue: 4.8.0.1269
• Last known good version:
• IDE: Visual Studio 16.6.5
• Platform Target Frameworks:
  
  
  
  • Android: 9.0
  
  

Screenshots

This is the same code shown running on the docs page:

[holecekp]

This problem has already been reported as #11700. It is marked as closed, which makes it harder to find.

[pfafft33]

I'm having this problem also since I updated to XF 4.8.0.1269 about a week ago.
When can we expect a fix?

[Tommigun1980]

I'm having this problem also since I updated to XF 4.8.0.1269 about a week ago.
When can we expect a fix?

Probably never as they remade the radio buttons. Which means it will take several months before there is a working version. I think it would be best if new developments were stopped and the existing one was made functional. It is hard to find a a version of Xamarin.Forms where all widgets work, and it is not great to constantly have to remake stuff because the APIs change. So please please fix this before remaking the system - we really can't be constantly remaking our apps and it will probably take a while for the new system to stabilise anyway.

[ish-1313]

hit the same. as a temporary workaround using label near radiobutton inside stacklayout

[pfafft33]

I think I'll just stay at XF 4.7.0.1239 until they fix the RadioButton bug in a future release.

[ish-1313]

just checked. on IOS with 4.8.0.1269 there is a text near radiobutton

[Sebastian1989101]

Quick Workaround for the problem:

<StackLayout Orientation="Horizontal">
    <StackLayout.Spacing>
        <OnPlatform x:TypeArguments="x:Double">
            <On Platform="iOS" Value="-8" />
        </OnPlatform>
    </StackLayout.Spacing>

    <RadioButton x:Name="LocalRadioButton" IsChecked="{Binding IsSelected}"
                 GroupName="{Binding Source={x:Reference EntryGrid}, Path=BindingContext.Identifier}" />

    <Label Text="{Binding SelectionText}" FontSize="Default" LineBreakMode="TailTruncation" VerticalOptions="Center">
        <Label.GestureRecognizers>
            <TapGestureRecognizer Command="{Binding ViewModel.ToggleRadioButtonCommand, Source={x:Reference ContentPage}}"
                CommandParameter="{x:Reference LocalRadioButton}" />
        </Label.GestureRecognizers>
    </Label>
</StackLayout>

Yes, I know this increases the VisualTree. Yes, I also know that this requires the ViewModel to reference the RadioButton and do the IsChecked toggle. It's not a clean good solution but at least it is working..

[eramrit78]

Not resolved in XF 4.8.0.1364

[lee-m]

This was never claimed to be fixed in the release notes for 4.8.0.1364.

[Cfun1]

This was never claimed to be fixed in the release notes for 4.8.0.1364.

In my opinion it started to become a bit uncomfortable, users must to stick with the version 4.7.0.1351 (6 releases back) just for for the radiobutton text to be visible.

[lee-m]

Whilst sticking around on an old version is not ideal, there is a workaround to restore the desired behaviour.

[BartoszKopec]

Let me attach a great comment about the activities of the Xamarin.Forms team: https://github.com/xamarin/Xamarin.Forms/issues/10801#issuecomment-690357428
It doesn't really exists as workaround, because e.g. in my enterprise XF project i have 10 radiobuttons and don't have time to change this small control to huge visual tree. And i think i'm not alone.

[holecekp]

The Sebastian1989101's workaround worked for me with a small modification - I recommend setting the text for both RadioButton and the Label. Then, use IsVisible property on the Label to make sure it is visible only on Android (tested for Android and UWP). Otherwise, a large negative spacing would be required for UWP (and it did not look well even with the spacing).

The workaround was quite easy and it consumed less time than I originally thought. I am more concerned about the number of other bugs for which no workaround exists. So I fully understand the decision of the XF team not to fix this issue now and to deal with other issues instead.

Still, I am a little surprised how this bug could make it into the release without anyone noticing it (and passing all tests).

[Cfun1]

@BartoszKopec @holecekp Are you saying that Xamarin.Forms is not stable enough so that the whole time of the dev team is spent only on fixing the 2k bugs and making it stable and mature, and that there is no time for even making some improvements such #9839 (Issue) (6 months ago) ?
At the beginning I thought Xamarin.Forms is stable and mature enough, but unfortunately I was maybe wrong.

[BartoszKopec]

@Codwy, from my two years of experience coding in XF last 2 months was bad and the last was just adventure of discovering nice concept of crosplatforming.
In my opinion XF docs on Microsoft site aren't mirroring reality at all. Like e.g. this simple bug, bug with LabelRenderer that Java want to call but Label is disposed already by GC (and we'll get ObjectDisposedException).
In fact in XF you can come across very specyfic bug that solution might require bugfix in XF directly and fast workaround is not an option. Maybe it's a cost for covering Android/iOS code.

[Sebastian1989101]

@Codwy they didnt even manage to fix 4 year old bugs, so how high is the chance they fix anything (see: https://github.com/xamarin/Xamarin.Forms/issues/2017 which is back from the Bugzilla days)? Xamarin.Forms works for small easy projects but for anything big I would avoid it at all cost due to the huge amount of issues and new issues after a update (can't remember the last update where not at least 3 things got broken).

[lee-m]

Unfortunately I have to agree with recent sentiments. I've had (and continue to have) an assortment of crippling bugs in both XF itself and the tooling around it - whether it was apps crashing on startup in debug introduced with a VS update or the more recent inability to even build due to a Mono.Cecil version mismatch in AndroidX migration.

That this bug even exists is surprising as it's not even an obscure piece of functionality. The repro is literally copy/pasted from the Microsoft docs for the control.

[holecekp]

@Codwy No, that is not what I meant. I really like Xamarin.Forms. The number of open issues is understandable considering how many platforms they support and how many controls XF contains. My experience is that Xamarin.Forms is quite stable if you stick to one version and do not update often. The truth is that new XF releases often break things and when you report an issue it takes some time before it is fixed (weeks, months, or even never). It would be better if XF was slimmer and focused on the core functionality without bugs instead of adding new controls (such as Expander) in each version. This would mean less code and less things that can break.

[Sebastian1989101]

@holecekp It would also help a lot if they would actual use automated unit tests to test the implemented stuff. This way most issues could be filtered before a release. No need to rush a version if it contains bugs.

[hartez]

We're sorry that you have run into a problem with the RadioButton, but I have to point out that this is an _experimental_ feature; that's why you have to explicitly set a flag to use it. That's why there's a warning on that documentation page. Experimental features can go through extensive re-work and change as we integrate the data from the experiment. And sometimes we find bugs, which also inform that experiment.

The problem you're seeing (that the text is not appearing) is addressed in the re-work we did of the RadioButton for 5.0.0, which should be hitting stable in mid-October if our current schedule holds. Unfortunately we couldn't merge the revisions for 5.0.0 pre1, but if you're interested in seeing the new work sooner, it should be in pre2.

In the meantime, it's unlikely that we'll release a fix for the "old" version because we're focused on testing/bug fixes for the re-work. I would suggest something like the Label workaround from @Sebastian1989101 upthread.

[hartez]

For reference, the pending RadioButton update.

[mikebmcl]

I think it was wrong to close this without fixing it and that the reasons given are inconsistent with the documentation for experimental features. From the documentation page https://docs.microsoft.com/en-us/xamarin/xamarin-forms/internals/experimental-flags :

"When a new Xamarin.Forms feature is implemented, it's sometimes put behind an experimental flag. This enables the engineering team to provide new features to you more quickly, while still being able to change feature APIs before they move to a stable release. The experimental flag is then removed once the feature moves to a stable release."

That is the entire description. The expectation based on that language is "new features more quickly, while still being able to change feature APIs". The fact that RadioButton no longer displays the text provided in conformance with the documented API is not a change in the feature API; it is a bug. When the text disappeared from the Android control, RadioButton stopped being an experimental feature as per the description from the documentation and instead became something more like an internal work-in-progress or a something from a third-party repo. The fact that Sebastian1989101 posted a workaround was a great thing. But it doesn't fix the bug introduced into RadioButton in 4.8.

Presumably the purpose of releasing these experimental features is to get feedback on them to improve them. If developers cannot trust that an experimental control will continue to provide its basic functionality in some way through its own API (and there is no way to make RadioButton in 4.8 show text in Android using its API; the workaround requires the use of other functionality), then for my part, I can no longer consider experimental controls to meet what I've considered as being the "contract" of "new features" that might have "change(s to) feature APIs".

Instead, they are now (apologies for the unpolished wording) "things that work when they are first released but should not be considered reliable and may simply stop working in a future release". By refusing to fix RadioButton in 4.8, that is what experimental features have now become. Given that, as a developer, can you honestly expect anyone to use something that only provides that level of commitment? For my part, I can't use something like that. And if this bug isn't fixed in 4.8, I can't ever justify using or recommending that anyone else use an experimental control ever again.

I understood and accepted that the API might change and I might need to change my code accordingly. But now it's not a matter of changing a bit of code to adapt to API changes. It's a matter of completely redesigning everything I have that uses RadioButton, which may ultimately entail going so far as writing a custom control replacement for it (something I had already done but removed after RadioButton was released because I assumed RadioButton would take better advantage of the underlying platform features and it removed the burden of me testing my custom control under the assumption that RadioButton was being properly tested).

Going forward I will simply need to plan my apps in such a way that I ignore the existence of experimental controls. And frankly I will be wary of using controls that cease being experimental for at least one major release cycle since I expect experimental controls to get way less use from developers going forward, meaning that the first significant feedback you will get on them will be when the experimental flag is removed. If that does in fact happen, it will degrade the meaning of a stable release down to being something more like what experimental features (as described in the current documentation) are, with experimental flags being replaced with the release notes that tell developers what the new presumptively stable features are.

Lastly, the fact that this bug is expected to be fixed in the next major release is irrelevant. The current major release, 4.8, contains bug fixes some of which are for security bugs. I don't consider it reasonable to stick with the old release that still works and forego all bug fixes just so I can use a control that worked in the last major release (4.7), was broken by 4.8 and will not be fixed until the next major release at the earliest.

Sorry for the essay, but I strongly feel that this is a serious issue in that not fixing this bug in 4.8 breaks the "contract" that the documentation describes for experimental controls. I request that you please reopen the issue until such time as the documentation is revised to meet the revised definition of experimental controls or there is a 4.8 bug fix. If the bug fix is not released in 4.8, I respectfully suggest that the documentation be revised so that it accurately describes the expectations developers should have for experimental controls going forward.

[HeMinzhang]

https://github.com/xamarin/Xamarin.Forms/search?q=RadioButton&unscoped_q=RadioButton

This problem can be easily solved at present, because xamarin is open source access, so you only need to copy and slightly modify the 5.0 code, or use the old version of the code to fix it.

[HeMinzhang]

You can even create your own style of controls.

[HeMinzhang]

I think i need more coke

[HeMinzhang]

You can even make your own special version of xamarin pastry

[HeMinzhang]

https://github.com/xamarin/Xamarin.Forms/blob/4.6.0/Xamarin.Forms.Platform.Android/ButtonLayoutManager.cs#L275

https://github.com/xamarin/Xamarin.Forms/blob/4.8.0/Xamarin.Forms.Platform.Android/ButtonLayoutManager.cs#L275

I think there may be an error here, but I am very troublesome in the new android control rendering implementation, I tried to directly modify the xamarin.form package and compile it.

[HeMinzhang]

I don’t know if there is an error in ios, if there is any, you can consider searching here
https://github.com/xamarin/Xamarin.Forms/blob/4.6.0/Xamarin.Forms.Platform.iOS/Renderers/RadioButtonRenderer.cs#L294

https://github.com/xamarin/Xamarin.Forms/blob/4.8.0/Xamarin.Forms.Platform.iOS/Renderers/RadioButtonRenderer.cs#L294