Remove Deprecated API that has reached EOL after Flutter 2.10

@rydmike

Internal: b/226976190

The time has come again. :)
These are the next batch of deprecations that have expired.

This one is a bit more significant than last batches, so it may take some time to get everyone migrated.
This should only be closed after the final migration guide for this batch lands in the website repo.

Notes

See comments below from @rydmike, as the button clean up is done, there are a lot of documentation improvements that should be made at the same time

Hi, I was working on removing these deprecations. There are two more deprecations that i found in release notes of 2.0.0

build ios-framework --universal deprecation pr
Android v1 embedding classes deprecation pr

also if you can add this pr in here

@amanv8060

Hi @amanv8060! Thanks for contributing! This is meant to track the progress of removing deprecated code in the framework as defined in the deprecation policy.

I think those deprecations will be removed at a different time.

@Piinks

Hi @Piinks nice collection of coming removal of @deprecated APIs in post 2.10.x stable release, quite a few coming breaking changes in next stable release then. And thanks @timsneath for tweeting out a heads up notice about it too.

I collected my quick findings on the deprecated buttons topic, I mentioned on Twitter here, plus some additional findings I noticed while at keyboard and looking into it out of curiosity.

ButtonThemeData

The ButtonThemeData class is marked as obsolete in the docs, but not as deprecated.

In its theme ButtonTheme:

flutter/packages/flutter/lib/src/material/button_theme.dart

Line 53 in adafd66

/// ### This class is obsolete.

And in its theme data ButtonThemeData:

flutter/packages/flutter/lib/src/material/button_theme.dart

Line 170 in adafd66

/// ### This class is obsolete.

In addition to the buttons that will be removed, the theme and theme data is used by the buttons' parent class MaterialButton and the ButtonBar and its theme ButtonBarTheme, plus as far I could notice DropdownButton uses one property from it as well.

Instead of having the docs above mention that it is used by buttons that will no longer exist, maybe consider updating the doc comment and instead mention the usage by ButtonBar, DropdownButton and MaterialButton, if it will remain. It kind of will have to, but more on that below.

Perhaps for the update also consider updating the doc comment for the buttonTheme property in ThemeData to better reflects its remaining usage in ButtonBar, DropdownButton and MaterialButton

flutter/packages/flutter/lib/src/material/theme_data.dart

Line 1322 in adafd66

/// Defines the default configuration of button widgets, like [RaisedButton]

MaterialButton

Next comes the question of the fate of the MaterialButton the parent class for the buttons to be removed.

It is also in the docs marked as obsolete but not deprecated.

flutter/packages/flutter/lib/src/material/material_button.dart

Line 22 in adafd66

/// ### This class is obsolete.

Will it remain available or be removed? My conclusion is, it will stay, even if it does not correctly implement or enable users to create Material buttons, plus its children will be gone due to same reasons. Considering this, it seems a bit illogical for it to remain, but it would be difficult to remove without a number of other changes discussed further below.

My search did no reveal any other usages and mentions of MaterialButton than in its child buttons that will be removed, and in ButtonThemeData itself, in a large number of odd looking getters.

In ButtonStyleButton there is also a doc ref to MaterialButton that I suspect should be to ButtonStyleButton instead, or just as a normal text "Material button" as a reference to the Material button concept itself, rather than a doc ref to a class that has nothing to do with ButtonStyleButton where the reference is.

flutter/packages/flutter/lib/src/material/button_style_button.dart

Line 425 in 8a6d0d6

/// A widget to pad the area around a [MaterialButton]'s inner [Material].

The fact that ButtonThemeData, that needs to remain for ButtonBar and DropdownButton, itself depends on MaterialButton, also makes it impossible to remove the "obsolete" MaterialButton parent of all the 3 buttons now being removed.

In Material there is in the MaterialType enum a doc comment to MaterialButton in enum value button.

flutter/packages/flutter/lib/src/material/material.dart

Line 35 in 8a6d0d6

/// Rounded edges, no color by default (used for [MaterialButton] buttons).

So I checked for references to MaterialType.button, other than in Material it is only used by RawMatererialButton and ButtonStyleButton. maybe consider updating the above doc ref to them instead of MaterialButton.

If the MaterialButton is considered and marked as obsolete in the docs, which imo is correct, thus maybe consider deprecating it and plan for changes need to be able to remove it.

ButtonBar

Since ButtonBar uses the ButtonThemeData and it is still a component with a "kind of" legit claim to do so, then ButtonThemeData does indeed need to remain for it to work.

The setup with ButtonBar using two different component themes ButtonThemeData and ButtonBarThemeData with the later overriding 6 properties, if defined in "parent" ButtonThemeData plus having 3 extra properties, and using some others from the 1st one too, "may" be a bit confusing for users trying to style it with the component themes.

I used a similar approach with custom themes for custom components. It was confusing to users to have two partially overlapping themes used in similar manner for effective result. I ended up simplifying it by just using one component theme per component. In retrospect I was just being lazy and reusing props from another kind of "parent" component theme, instead of defining them separately also in the other similar component. The refactored version ended up being cleaner by keeping the theme concerns separated.

Later on, maybe consider deprecating the properties ButtonBar uses in ButtonThemeData and provide replacements in ButtonBarThemeData, it would imo be simpler and cleaner to use it then.

DropdownButton

Lastly, and yes I did not see it first, you were right, the Dropdown button also uses ButtonThemeData, but apparently only one property from it: ButtonTheme.of(context).alignedDropdown, twice, here:

flutter/packages/flutter/lib/src/material/dropdown.dart

Line 1266 in 8d25ddd

final EdgeInsetsGeometry menuMargin = ButtonTheme.of(context).alignedDropdown

and here

flutter/packages/flutter/lib/src/material/dropdown.dart

Line 1405 in 8d25ddd

final EdgeInsetsGeometry padding = ButtonTheme.of(context).alignedDropdown

So there is indeed that too. Maybe later consider if DropdownButton should get its own component theme as well one day. It could then have some more and independent styling capabilities too.

Summary

I got curious about how it all of this fits together and thought I might just as well write it down while looking into it, perhaps some of it is useful.

Mostly observations on documentation clean-up suggestions, to do after the deprecated buttons FlatButton, RaisedButton and OutlineButton are removed.

Plus some observations of a potential path to enable removing the ButtonThemeData and MaterialButton if that is also on the clean-up agenda. Had the implementation of other features used better separation, they would now not had any references anywhere and already been removable, provided the policy would permit it of course.

OT
Now I'm going back to reading up on all the cool Material 3 changes/PRs moving forward on master. I need to see if there something more in there that I can prepare for in advance.

BTW I really like the new MaterialColorUtilities, the color algos for computing M3 tonal palettes are so fab. Already using it in a WIP version in FlexColorScheme to enable using primary, secondary and tertiary key colors for scheme generation, rather than the just the single key seed color (primary) offered by ColorScheme.fromSeed.

I was a bit surprised to see MaterialColorUtilities used as a Flutter SDK pub.dev package dependency in ColorScheme, and not having its code baked into the framework itself. That is actually quite unusual for the type of features it provides. Even a first I would say, other pubspec deps are much lower level. Typically "high" level features similar to MaterialColorUtilities are baked into the framework.

Will we see more of this approach going forward? Or is this an exception or only temporary as a package import? If it is a change of style and Flutter is going to see more add-on being used in the framework as package imports, it might be of general interest to hear more about it, just a thought.

@rydmike

@rydmike thank you!! This is an amazing wrap-up. Much appreciated.

I have not been working directly on the theme overhaul (Paging @darrenaustin & @HansMuller) so I do not know the answers to all of these questions, but I think they are all very important. I am going to open an issue for each section here for discussion and review. I don't want any bit of your breakdown to go unaccounted for. :)

Couple of quick notes though for the scope of this issue's work

Instead of having the docs above mention that it is used by buttons that will no longer exist, maybe consider updating the doc comment and instead mention the usage by ButtonBar, DropdownButton and MaterialButton, if it will remain. It kind of will have to, but more on that below.

Perhaps for the update also consider updating the doc comment for the buttonTheme property in ThemeData to better reflects its remaining usage in ButtonBar, DropdownButton and MaterialButton

Certainly any and all doc references will be updated as deprecated API is removed, I've made note of these cases and will include them in my changes. Thanks very much!

I'll link back the issues that will be generated from this feedback.

@rydmike

See associated issues above.
@rydmike I did come across these design docs, they may be of interest to you

@Piinks

Thanks @Piinks for the design doc links. Yes I'm familiar with them, especially the theme system updates one and the issue tracking its progress #91772, I have been following its action items closely and PRs concerning it too. I might have some observations/questions on a few colors that might be missing, and if so perhaps should be added to the list. I will double check that and drop a comment in the collection issue, if that is the case.

Glad if the above review was helpful. Creating separate actionable follow-up items from it was good idea too 👍🏻

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

Navigation Menu

Repository navigation

Remove Deprecated API that has reached EOL after Flutter 2.10 #98537

ButtonThemeData

MaterialButton

ButtonBar

DropdownButton

Summary

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Remove Deprecated API that has reached EOL after Flutter 2.10 #98537

Description

Activity

amanv8060 commented on Feb 16, 2022

Piinks commented on Feb 16, 2022

rydmike commented on Feb 17, 2022

ButtonThemeData

MaterialButton

ButtonBar

DropdownButton

Summary

Piinks commented on Feb 17, 2022

Piinks commented on Feb 17, 2022

rydmike commented on Feb 17, 2022

github-actions commented on Apr 28, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions