[ios] TabIdTabHelper

ios/chrome/browser/web/tab_id_tab_helper.h

Index: ios/chrome/browser/web/tab_id_tab_helper.h
diff --git a/ios/chrome/browser/web/tab_id_tab_helper.h b/ios/chrome/browser/web/tab_id_tab_helper.h
new file mode 100644
index 0000000000000000000000000000000000000000..1297cf5c570f319eab389b880488885064e257ee
--- /dev/null
+++ b/ios/chrome/browser/web/tab_id_tab_helper.h
@@ -0,0 +1,30 @@
+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef IOS_CHROME_BROWSER_WEB_TAB_ID_TAB_HELPER_H_
+#define IOS_CHROME_BROWSER_WEB_TAB_ID_TAB_HELPER_H_
+
+#include "base/macros.h"
+#import "ios/web/public/web_state/web_state_user_data.h"
+
+// The type of the unique identifier.
+typedef std::string TabID;

[rohitrao (ping after 24h), 2017/06/23 11:10:27]

Is there a reason to put this behind a TabID typedef?

In theory, I like the idea of making the type opaque to callers, but in practice
doesn't everyone perform string operations directly on the result?  If callers
always treat this as a string, is there value in having the TabID ifdef?

[edchin, 2017/06/23 16:24:21]

Agree that in practice it does not provide any benefit. I have updated to 
directly use NSString.

+
+// Handles creating a TabID, which is stable across cold starts.
+class TabIDTabHelper : public web::WebStateUserData<TabIDTabHelper> {
+ public:
+  ~TabIDTabHelper() override;
+
+  // Returns the TabID for this tab.
+  const TabID& tab_id() const { return tab_id_; }
+
+ private:
+  explicit TabIDTabHelper(web::WebState* web_state);
+  friend class web::WebStateUserData<TabIDTabHelper>;
+  TabID tab_id_;
+
+  DISALLOW_COPY_AND_ASSIGN(TabIDTabHelper);
+};
+
+#endif  // IOS_CHROME_BROWSER_WEB_TAB_ID_TAB_HELPER_H_