dialog: Use Cupertino-flavored alert dialogs on iOS #1017

u7088495 · 2024-10-22T04:43:49Z

This pull request closes #996.

In dialog.dart:

Switched alertDialog( to alertDialog.adaptive(, as per #996.

Defined new private widget _adaptiveAction which displays a CupertinoDialogAction for IOS and a TextButton otherwise. _adaptiveAction( is used in place of TextButton( when stating dialog actions.

The new result for IOS:

dialog-checks.dart has been updated to check the text content of the respective dialog types depending on the platform

chrisbobbe

Thanks! Comments below.

Also, please tidy up the branch's commit history for clear and coherent commits. Each commit should be clean and pass all tests (you can run our tests with tools/check).

chrisbobbe · 2024-10-23T22:29:08Z

lib/widgets/dialog.dart

+/// Sets the dialog action to be platform appropriate
+/// by displaying a [CupertinoDialogAction] for IOS platforms
+/// and a regular [TextButton] otherwise.
+Widget _adaptiveAction(
+      {required BuildContext context,
+      required VoidCallback onPressed,
+      required Widget child}) {
+    final ThemeData theme = Theme.of(context);
+    switch (theme.platform) {
+      case TargetPlatform.android:
+        return TextButton(onPressed: onPressed, child: child);
+      case TargetPlatform.fuchsia:
+      return TextButton(onPressed: onPressed, child: child);
+      case TargetPlatform.linux:
+        return TextButton(onPressed: onPressed, child: child);
+      case TargetPlatform.windows:
+        return TextButton(onPressed: onPressed, child: child);
+      case TargetPlatform.iOS:
+        return CupertinoDialogAction(onPressed: onPressed, child: child);
+      case TargetPlatform.macOS:
+        return CupertinoDialogAction(onPressed: onPressed, child: child);
+    }
+  }


This can be tightened up in a few ways:

Use empty cases to fall through. From the doc on Dart switch statements:

https://dart.dev/language/branches#switch-statements

Use defaultTargetPlatform instead of passing through context. When the app is run on a device, defaultTargetPlatform will match the platform (iOS or Android). When we need to simulate a specific platform in tests, we set defaultTargetPlatform; search for debugDefaultTargetPlatformOverride for how we do this.

More concise dartdoc

Also, because the logic in _dialogActionText fits and is recommended for the Material-style dialog, let's only apply it on Android. This helper is a fine place for that conditional logic; how about changing its interface so it takes a String instead of a Widget, and applies _dialogActionText in the Android branch. In my proposal below, I've also given _dialogActionText an appropriately specific name, _materialDialogActionText. That helper could even be inlined, perhaps in a followup NFC commit.

So, putting all that together:

Suggested change

/// Sets the dialog action to be platform appropriate

/// by displaying a [CupertinoDialogAction] for IOS platforms

/// and a regular [TextButton] otherwise.

Widget _adaptiveAction(

{required BuildContext context,

required VoidCallback onPressed,

required Widget child}) {

final ThemeData theme = Theme.of(context);

switch (theme.platform) {

case TargetPlatform.android:

return TextButton(onPressed: onPressed, child: child);

case TargetPlatform.fuchsia:

return TextButton(onPressed: onPressed, child: child);

case TargetPlatform.linux:

return TextButton(onPressed: onPressed, child: child);

case TargetPlatform.windows:

return TextButton(onPressed: onPressed, child: child);

case TargetPlatform.iOS:

return CupertinoDialogAction(onPressed: onPressed, child: child);

case TargetPlatform.macOS:

return CupertinoDialogAction(onPressed: onPressed, child: child);

}

}

/// A platform-appropriate action for [AlertDialog.adaptive]'s [actions] param.

Widget _adaptiveAction({required VoidCallback onPressed, required String text}) {

switch (defaultTargetPlatform) {

case TargetPlatform.android:

case TargetPlatform.fuchsia:

case TargetPlatform.linux:

case TargetPlatform.windows:

return TextButton(onPressed: onPressed, child: _materialDialogActionText(text));

case TargetPlatform.iOS:

case TargetPlatform.macOS:

return CupertinoDialogAction(onPressed: onPressed, child: Text(text));

}

}

Is this the idea for inlining the _materialDialogActionText?

return TextButton(onPressed: onPressed, child: Text(text, textAlign: TextAlign.end));

will update the commit message of the latest commit as well as per the guidelines

chrisbobbe · 2024-10-23T22:35:19Z

test/widgets/dialog_checks.dart

@@ -6,21 +8,41 @@ import 'package:flutter_test/flutter_test.dart';
 /// Checks for an error dialog matching an expected title
 /// and, optionally, matching an expected message. Fails if none is found.
 ///
-/// On success, returns the widget's "OK" button.
+/// On success, returns the widget's "OK" button
+/// (which is a [CupertinoDialogAction] for OS platforms).


We can leave this dartdoc unchanged. It doesn't matter what specific widget the button is, as long as it responds to taps.

chrisbobbe · 2024-10-23T22:37:26Z

test/widgets/dialog_checks.dart

-  final dialog = tester.widget<AlertDialog>(find.byType(AlertDialog));
-  tester.widget(find.descendant(matchRoot: true,
-    of: find.byWidget(dialog.title!), matching: find.text(expectedTitle)));
-  if (expectedMessage != null) {
+  if (defaultTargetPlatform == TargetPlatform.iOS 
+    || defaultTargetPlatform == TargetPlatform.macOS) {
+
+    final dialog = tester.widget<CupertinoAlertDialog>(find.byType(CupertinoAlertDialog));
+
    tester.widget(find.descendant(matchRoot: true,
-      of: find.byWidget(dialog.content!), matching: find.text(expectedMessage)));
-  }
+    of: find.byWidget(dialog.title!), matching: find.text(expectedTitle)));

-  return tester.widget(
-    find.descendant(of: find.byWidget(dialog),
-      matching: find.widgetWithText(TextButton, 'OK')));
+    if (expectedMessage != null) {
+      tester.widget(find.descendant(matchRoot: true,
+        of: find.byWidget(dialog.content!), matching: find.text(expectedMessage)));
+    }
+
+    return tester.widget(
+      find.descendant(of: find.byWidget(dialog),
+        matching: find.widgetWithText(CupertinoDialogAction, 'OK')));
+
+  } 
+  else {
+    final dialog = tester.widget<Dialog>(find.byType(Dialog));
+    tester.widget(find.widgetWithText(Dialog, expectedTitle));
+    if (expectedMessage != null) {
+      tester.widget(find.widgetWithText(Dialog, expectedMessage));
+    }
+    return tester.widget(
+      find.descendant(of: find.byWidget(dialog),
+        matching: find.widgetWithText(TextButton, 'OK')));
+  }


Let's use an exhaustive switch on defaultTargetPlatform, like we do elsewhere. Also, there are several formatting nits that makes this code harder to read than it needs to be.

Proposal:

switch (defaultTargetPlatform) { case TargetPlatform.android: case TargetPlatform.fuchsia: case TargetPlatform.linux: case TargetPlatform.windows: { final dialog = tester.widget<Dialog>(find.byType(Dialog)); tester.widget(find.widgetWithText(Dialog, expectedTitle)); if (expectedMessage != null) { tester.widget(find.widgetWithText(Dialog, expectedMessage)); } return tester.widget( find.descendant(of: find.byWidget(dialog), matching: find.widgetWithText(TextButton, 'OK'))); } case TargetPlatform.iOS: case TargetPlatform.macOS: { final dialog = tester.widget<CupertinoAlertDialog>( find.byType(CupertinoAlertDialog)); tester.widget(find.descendant(matchRoot: true, of: find.byWidget(dialog.title!), matching: find.text(expectedTitle))); if (expectedMessage != null) { tester.widget(find.descendant(matchRoot: true, of: find.byWidget(dialog.content!), matching: find.text(expectedMessage))); } return tester.widget(find.descendant(of: find.byWidget(dialog), matching: find.widgetWithText(CupertinoDialogAction, 'OK'))); } }

chrisbobbe · 2024-10-23T22:38:18Z

pubspec.lock

@@ -315,10 +315,10 @@ packages:
    dependency: transitive
    description:
      name: file
-      sha256: "5fc22d7c25582e38ad9a8515372cd9a93834027aacf1801cf01164dac0ffa08c"
+      sha256: a3b4f84adafef897088c160faf7dfffb7696046cb13ae90b508c2cbc95d3b8d4


The changes to this file don't look related; please remove them.

Ok thankyou for the feedback, will be sure to onboard these points when working on issues in the future. I'll fix these things up in a new commit.

gnprice · 2024-10-24T01:40:42Z

(Misclick, sorry)

chrisbobbe

Thanks. You'll need to tidy up your branch, as I mentioned above, before we can review this again. If you need help, please ask in #git help in the development community.

lib/widgets/dialog.dart

pubspec.lock

u7088495 · 2024-10-25T01:02:38Z

Thanks. You'll need to tidy up your branch, as I mentioned above, before we can review this again. If you need help, please ask in #git help in the development community.

yep my bad, will do so. Thanks for your patients with me on this.

As was suggested in a comment of the pull request zulip#1017 (comment).

chrisbobbe

Thanks, this is much closer! Small comments below.

Also, a few commit message nits:

dialog: display adaptive dialogs and action buttons based on the target platform

AlertDialog was changed to AlertDialog.adaptive to the effect described in #996.
_adaptiveAction was implemented to display a platform appropriate action for
AlertDialog.adaptive's actions param, as was also discussed in #996.
tests in dialog_test were updated to perform platform appropriate tests.

This commit fixes an issue (🎉), so let's put a Fixes: #996 line at the end of it.
Also, I think the paragraph ("AlertDialog was changed…") doesn't add anything that's not already obvious from reading the code changes and the linked issue, so let's just delete it.

dialog [nfc]: inline _materialDialogActionTest in _adaptiveAction
    
As was suggested in a comment of the pull request https://github.com/zulip/zulip-flutter/pull/1017#discussion_r1813819656.

The URL should be on a new line; we try to wrap to 68 columns except where doing so would make things more confusing. How about:
```
As suggested at:
  https://github.com/zulip/zulip-flutter/pull/1017#discussion_r1813819656 
```

Then for both commit messages, use initial caps for the part after the prefix, so:

dialog: Display adaptive dialogs and action buttons based on the target platform
dialog [nfc]: inline _materialDialogActionTest in _adaptiveAction

For examples of commit messages in the project's style, see the project's Git history; I recommend Greg's excellent tip about how to do that.

test/widgets/dialog_checks.dart

lib/widgets/dialog.dart

As was suggested in a comment of the pull request zulip#1017 (comment).

As suggested at: zulip#1017 (comment)

chrisbobbe

Thanks!

Some new nits below, and also some more commit-message nits that I should have caught last time 🙂:

dialog: Display adaptive dialogs and action buttons based on the target platform

This summary line is too long, at 80 characters. How about:

dialog: Use Cupertino-flavored alert dialogs on iOS

This also has a bit more information: the fact that iOS was the platform getting the wrong-style dialog. (The fact that the dialog's buttons match the rest of the dialog isn't surprising enough to need a mention. 🙂)

For what the length limit actually is, see discussion, which I've just started 🙂. This was a helpful opportunity for me to spot a change in the zulip/zulip documentation that I'd missed!

dialog [nfc]: Inline _materialDialogActionTest in _adaptiveAction

The function's name is _materialDialogActionText, not _materialDialogActionTest.

lib/widgets/dialog.dart

Fixes: zulip#996

As suggested at: zulip#1017 (comment)

u7088495 · 2024-10-30T05:01:40Z

Thanks!

Some new nits below, and also some more commit-message nits that I should have caught last time 🙂:
dialog: Display adaptive dialogs and action buttons based on the target platform
This summary line is too long, at 80 characters. How about:
dialog: Use Cupertino-flavored alert dialogs on iOS
This also has a bit more information: the fact that iOS was the platform getting the wrong-style dialog. (The fact that the dialog's buttons match the rest of the dialog isn't surprising enough to need a mention. 🙂)

For what the length limit actually is, see discussion, which I've just started 🙂. This was a helpful opportunity for me to spot a change in the zulip/zulip documentation that I'd missed!
dialog [nfc]: Inline _materialDialogActionTest in _adaptiveAction
The function's name is _materialDialogActionText, not _materialDialogActionTest.

all sorted :)

chrisbobbe · 2024-10-30T17:20:42Z

Thanks, LGTM! Marking for Greg's review.

u7088495 · 2024-10-30T23:27:16Z

Thanks, LGTM! Marking for Greg's review.

Thanks so much for your help through this process, It's been hugely helpful to me!

gnprice

Thanks @u7088495, and thanks @chrisbobbe for the previous reviews!

Generally these changes look good. Comments below.

Then there's one key thing this is missing before we can merge it: it needs tests. The current revision updates existing tests so that they continue to pass, but we also need tests that confirm the new logic is working correctly. That's how we ensure that a future change doesn't accidentally break this functionality.

A quick way to confirm that this version does not test the new functionality is to make the new code path artificially fail, like this:

     case TargetPlatform.iOS:
     case TargetPlatform.macOS:
+      throw 1;
       return CupertinoDialogAction(onPressed: onPressed, child: Text(text));

With that, the tests still pass. This PR needs to add a test or two that would fail with that change.

The tests should also fail if the changes get reverted. Try git checkout origin lib/widgets/dialog.dart to temporarily undo all your changes except the tests, then run flutter test to confirm that your new tests fail on the old code.

gnprice · 2024-11-04T21:03:56Z

test/widgets/dialog_checks.dart

+          matching: find.widgetWithText(TextButton, 'OK')));
+    }
+    case TargetPlatform.iOS:
+    case TargetPlatform.macOS: {


nits: no need for braces; and use a blank line to visually separate the two case blocks, since they're both several lines long

Suggested change

matching: find.widgetWithText(TextButton, 'OK')));

}

case TargetPlatform.iOS:

case TargetPlatform.macOS: {

matching: find.widgetWithText(TextButton, 'OK')));

case TargetPlatform.iOS:

case TargetPlatform.macOS:

gnprice · 2024-11-04T21:07:05Z

test/widgets/dialog_checks.dart

+      final dialog = tester.widget<Dialog>(find.byType(Dialog));
+      tester.widget(find.widgetWithText(Dialog, expectedTitle));
+      if (expectedMessage != null) {
+        tester.widget(find.widgetWithText(Dialog, expectedMessage));


This test logic in the non-Cupertino case differs from the old test logic. But the behavior in the non-Cupertino case is supposed to be the same as it was before, right? What's the motivation for changing the test logic?

Ah I see, the old version fails because there's no longer a widget whose exact type is AlertDialog — the widget is an instance of a subclass instead — and find.byType searches by exact type.

A clean solution to that is to search by type in a way that includes subclasses. With the original tests plus just this tweak, all the tests pass:

- final dialog = tester.widget<AlertDialog>(find.byType(AlertDialog)); + final dialog = tester.widget<AlertDialog>(find.bySubtype<AlertDialog>());

I found bySubtype by looking at the doc for byType, and in particular the "See also" section at the end:

/// See also: /// * [bySubtype], which allows subtype tests.

u7088495 marked this pull request as ready for review October 22, 2024 13:59

chrisbobbe reviewed Oct 23, 2024

View reviewed changes

gnprice added the maintainer review PR ready for review by Zulip maintainers label Oct 23, 2024

gnprice closed this Oct 24, 2024

gnprice reopened this Oct 24, 2024

u7088495 force-pushed the cupertino-dialog-for-ios branch 4 times, most recently from a255919 to db740f9 Compare October 24, 2024 04:34

chrisbobbe reviewed Oct 25, 2024

View reviewed changes

lib/widgets/dialog.dart Show resolved Hide resolved

pubspec.lock Outdated Show resolved Hide resolved

u7088495 force-pushed the cupertino-dialog-for-ios branch 2 times, most recently from ed8abb7 to 9d2c4df Compare October 25, 2024 01:30

u7088495 added a commit to u7088495/zulip-flutter that referenced this pull request Oct 25, 2024

dialog [nfc]: inline _materialDialogActionTest in _adaptiveAction

373cd75

As was suggested in a comment of the pull request zulip#1017 (comment).

u7088495 force-pushed the cupertino-dialog-for-ios branch from 9e6fc98 to 373cd75 Compare October 25, 2024 02:17

chrisbobbe requested changes Oct 25, 2024

View reviewed changes

test/widgets/dialog_checks.dart Outdated Show resolved Hide resolved

test/widgets/dialog_checks.dart Outdated Show resolved Hide resolved

lib/widgets/dialog.dart Outdated Show resolved Hide resolved

u7088495 added a commit to u7088495/zulip-flutter that referenced this pull request Oct 26, 2024

dialog [nfc]: inline _materialDialogActionTest in _adaptiveAction

52d762d

As was suggested in a comment of the pull request zulip#1017 (comment).

u7088495 force-pushed the cupertino-dialog-for-ios branch from 373cd75 to 52d762d Compare October 26, 2024 23:26

u7088495 added a commit to u7088495/zulip-flutter that referenced this pull request Oct 26, 2024

dialog [nfc]: Inline _materialDialogActionTest in _adaptiveAction

6166a0a

As suggested at: zulip#1017 (comment)

u7088495 force-pushed the cupertino-dialog-for-ios branch from 52d762d to 6166a0a Compare October 26, 2024 23:55

u7088495 added a commit to u7088495/zulip-flutter that referenced this pull request Oct 27, 2024

dialog [nfc]: Inline _materialDialogActionTest in _adaptiveAction

f91a8c5

As suggested at: zulip#1017 (comment)

u7088495 force-pushed the cupertino-dialog-for-ios branch from 6166a0a to f91a8c5 Compare October 27, 2024 00:03

u7088495 requested a review from chrisbobbe October 27, 2024 00:09

u7332137 approved these changes Oct 27, 2024

View reviewed changes

chrisbobbe self-assigned this Oct 28, 2024

chrisbobbe reviewed Oct 29, 2024

View reviewed changes

lib/widgets/dialog.dart Outdated Show resolved Hide resolved

lib/widgets/dialog.dart Outdated Show resolved Hide resolved

u7088495 added 2 commits October 30, 2024 15:52

dialog: Use Cupertino-flavored alert dialogs on iOS

0b91782

Fixes: zulip#996

dialog [nfc]: Inline _materialDialogActionText in _adaptiveAction

0a44828

As suggested at: zulip#1017 (comment)

u7088495 force-pushed the cupertino-dialog-for-ios branch from f91a8c5 to 0a44828 Compare October 30, 2024 04:56

u7088495 requested review from chrisbobbe and u7332137 October 30, 2024 05:02

chrisbobbe added integration review Added by maintainers when PR may be ready for integration and removed maintainer review PR ready for review by Zulip maintainers labels Oct 30, 2024

chrisbobbe assigned gnprice and unassigned chrisbobbe Oct 30, 2024

chrisbobbe requested review from gnprice and removed request for u7332137 October 30, 2024 17:21

gnprice reviewed Nov 4, 2024

View reviewed changes

gnprice mentioned this pull request Nov 20, 2024

dialog: Styling for action-button text when the action is destructive #1032

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

dialog: Use Cupertino-flavored alert dialogs on iOS #1017

dialog: Use Cupertino-flavored alert dialogs on iOS #1017

u7088495 commented Oct 22, 2024 •

edited

Loading

chrisbobbe left a comment

chrisbobbe Oct 23, 2024

u7088495 Oct 24, 2024

chrisbobbe Oct 23, 2024

chrisbobbe Oct 23, 2024

chrisbobbe Oct 23, 2024

u7088495 Oct 24, 2024

gnprice commented Oct 24, 2024

chrisbobbe left a comment

u7088495 commented Oct 25, 2024

chrisbobbe left a comment •

edited

Loading

chrisbobbe left a comment

u7088495 commented Oct 30, 2024

chrisbobbe commented Oct 30, 2024

u7088495 commented Oct 30, 2024

gnprice left a comment

gnprice Nov 4, 2024

gnprice Nov 4, 2024

gnprice Nov 4, 2024

dialog: Use Cupertino-flavored alert dialogs on iOS #1017

Are you sure you want to change the base?

dialog: Use Cupertino-flavored alert dialogs on iOS #1017

Conversation

u7088495 commented Oct 22, 2024 • edited Loading

chrisbobbe left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gnprice commented Oct 24, 2024

chrisbobbe left a comment

Choose a reason for hiding this comment

u7088495 commented Oct 25, 2024

chrisbobbe left a comment • edited Loading

Choose a reason for hiding this comment

chrisbobbe left a comment

Choose a reason for hiding this comment

u7088495 commented Oct 30, 2024

chrisbobbe commented Oct 30, 2024

u7088495 commented Oct 30, 2024

gnprice left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

u7088495 commented Oct 22, 2024 •

edited

Loading

chrisbobbe left a comment •

edited

Loading