Implementing sign-in promo for "Other Devices" on the iPad

ios/chrome/browser/ui/tab_switcher/tab_switcher_panel_overlay_view.mm

Index: ios/chrome/browser/ui/tab_switcher/tab_switcher_panel_overlay_view.mm
diff --git a/ios/chrome/browser/ui/tab_switcher/tab_switcher_panel_overlay_view.mm b/ios/chrome/browser/ui/tab_switcher/tab_switcher_panel_overlay_view.mm
index b6c5b14096a4d46ad37598a6a3005289419b9823..e9fce78095d4620b968452d90bc520cf349cf457 100644
--- a/ios/chrome/browser/ui/tab_switcher/tab_switcher_panel_overlay_view.mm
+++ b/ios/chrome/browser/ui/tab_switcher/tab_switcher_panel_overlay_view.mm
@@ -6,6 +6,12 @@
 
 #include "base/metrics/user_metrics.h"
 #include "base/metrics/user_metrics_action.h"
+#include "components/signin/core/browser/signin_metrics.h"
+#include "ios/chrome/browser/experimental_flags.h"
+#import "ios/chrome/browser/ui/authentication/signin_promo_view.h"
+#import "ios/chrome/browser/ui/authentication/signin_promo_view_configurator.h"
+#import "ios/chrome/browser/ui/authentication/signin_promo_view_consumer.h"
+#import "ios/chrome/browser/ui/authentication/signin_promo_view_mediator.h"
 #import "ios/chrome/browser/ui/colors/MDCPalette+CrAdditions.h"
 #import "ios/chrome/browser/ui/commands/UIKit+ChromeExecuteCommand.h"
 #include "ios/chrome/browser/ui/commands/ios_command_ids.h"
@@ -52,7 +58,7 @@ const CGFloat kTitleMinimumLineHeight = 32.0;
 const CGFloat kSubtitleMinimunLineHeight = 24.0;
 }
 
-@interface TabSwitcherPanelOverlayView ()
+@interface TabSwitcherPanelOverlayView ()<SigninPromoViewConsumer>
 
 // Updates the texts of labels and button according to the current
 // |overlayType|.
@@ -73,6 +79,8 @@ const CGFloat kSubtitleMinimunLineHeight = 24.0;
   MDCButton* _floatingButton;
   MDCActivityIndicator* _activityIndicator;
   std::string _recordedMetricString;
+  SigninPromoViewMediator* _signinPromoViewMediator;
+  SigninPromoView* _signinPromoView;
 }
 
 @synthesize overlayType = _overlayType;
@@ -167,7 +175,36 @@ const CGFloat kSubtitleMinimunLineHeight = 24.0;
           @"H:|-(>=0)-[container(==containerWidth@999)]-(>=0)-|",
         ],
         @{ @"container" : _container },
-        @{ @"containerWidth" : @(kContainerWidth) }, self);
+        @{ @"containerWidth" : @(kContainerWidth) });
+
+    // Adding sign-in promo view.

[msarda, 2017/05/23 12:55:54]

It looks like the sign-in promo view is created even when the user is signed in.
I think that we should avoid creating the sign-in promo view when the overlay
type is different than OVERLAY_PANEL_USER_SIGNED_OUT

[jlebel, 2017/05/23 14:34:15]

Done.

+    _signinPromoView = [[SigninPromoView alloc] initWithFrame:CGRectZero];
+    _signinPromoView.translatesAutoresizingMaskIntoConstraints = NO;
+    _signinPromoView.textLabel.text =
+        l10n_util::GetNSString(IDS_IOS_SIGNIN_PROMO_SETTINGS);

[msarda, 2017/05/23 12:55:55]

Why are we using the settings promo string in the recent tabs?

[jlebel, 2017/05/23 14:34:15]

Done.

+    _signinPromoView.textLabel.textColor = [UIColor whiteColor];
+    _signinPromoView.textLabel.font = [MDCTypography headlineFont];
+    _signinPromoView.textLabel.preferredMaxLayoutWidth =
+        kContainerWidth - (2 * _signinPromoView.horizontalPadding);
+    [self addSubview:_signinPromoView];
+    ApplyVisualConstraintsWithMetrics(
+        @[ @"H:[signinPromoView(containerWidth)]" ],
+        @{ @"signinPromoView" : _signinPromoView },
+        @{ @"containerWidth" : @(kContainerWidth) });
+    AddSameCenterXConstraint(_signinPromoView, self);
+    [_signinPromoView.centerYAnchor
+        constraintEqualToAnchor:self.centerYAnchor
+                       constant:kContainerOriginYOffset]
+        .active = YES;
+    _signinPromoView.hidden = YES;
+    _signinPromoViewMediator = [[SigninPromoViewMediator alloc] init];
+    _signinPromoViewMediator.accessPoint =
+        signin_metrics::AccessPoint::ACCESS_POINT_RECENT_TABS;
+    _signinPromoView.delegate = _signinPromoViewMediator;
+    _signinPromoViewMediator.consumer = self;
+    [[_signinPromoViewMediator createConfigurator]
+        configureSigninPromoView:_signinPromoView];
+    [_signinPromoView setNeedsLayout];

[msarda, 2017/05/23 12:55:55]

Why should the sign-in promo view be layed out if it is hidden?

[jlebel, 2017/05/23 14:34:15]

I've done it just to make sure the layout is correct when it will shown. But
there is no reason anyway for this line since we just created the view, and the
layout has to be made anyway. 

   }
   return self;
 }
@@ -185,8 +222,17 @@ const CGFloat kSubtitleMinimunLineHeight = 24.0;
 
 - (void)setOverlayType:(TabSwitcherPanelOverlayType)overlayType {
   _overlayType = overlayType;
-  [self updateText];
-  [self updateButtonTarget];
+  if (experimental_flags::IsSigninPromoEnabled() &&
+      _overlayType ==
+          TabSwitcherPanelOverlayType::OVERLAY_PANEL_USER_SIGNED_OUT) {
+    _container.hidden = YES;
+    _signinPromoView.hidden = NO;
+  } else {
+    _container.hidden = NO;
+    _signinPromoView.hidden = YES;
+    [self updateText];

[msarda, 2017/05/23 12:55:55]

When the promo is enabled, it looks like we do not call updateText or
updateButtonTarget when the overlay type is SIGNED_OUT. However we still call it
for the other cases. Is that expected?

[jlebel, 2017/05/23 14:34:15]

In this overlay view, I can't use the current UI element. I choose to add the
SigninPromoView on top and hide one or the other. So if the sign-in promo view
is shown there is no reason to update the hidden elements.

+    [self updateButtonTarget];
+  }
 }
 
 #pragma mark - Private
@@ -410,4 +456,12 @@ const CGFloat kSubtitleMinimunLineHeight = 24.0;
   base::RecordAction(base::UserMetricsAction(_recordedMetricString.c_str()));
 }
 
+#pragma mark - SigninPromoViewConsumer
+
+- (void)configureSigninPromoViewWithNewIdentity:(BOOL)newIdentity
+                                   configurator:(SigninPromoViewConfigurator*)
+                                                    configurator {
+  [configurator configureSigninPromoView:_signinPromoView];
+}
+
 @end