[CRD iOS] Branching internal and external implementations

[CRD iOS] Branching internal and external implementations

This CL:

* Introduces the RemotingResourceFactory class for providing different resources
  depending on whether it's an external or internal build.
* Adds an AppInitializer for initializing common resources.

BUG=731851
Review-Url: https://codereview.chromium.org/2937733003
Cr-Commit-Position: refs/heads/master@{#481006}
Committed: https://chromium.googlesource.com/chromium/src/+/4a13a977ca3b4db548fae2cf14990e797688bb79

[Yuwei, 2017-06-13 21:29:02]

Patchset #1 (id:1) has been deleted

[Yuwei, 2017-06-13 23:07:04]

Patchset #1 (id:20001) has been deleted

[Yuwei, 2017-06-13 23:23:48]

Patchset #1 (id:40001) has been deleted

[Yuwei, 2017-06-13 23:26:08]

Description was changed from

==========
[CRD iOS] Introduce the RemotingResourceFactory

This CL introduces the RemotingResourceFactory class for providing different
resources depending on whether it's an external or internal build.

BUG=731851
==========

to

==========
[CRD iOS] Branching internal and external implementations

This CL:

* Introduces the RemotingResourceFactory class for providing different resources
  depending on whether it's an external or internal build.
* Adds an AppInitializer for initializing common resources.

BUG=731851
==========

[Yuwei, 2017-06-13 23:27:20]

yuweih@chromium.org changed reviewers:
+ nicholss@chromium.org

[Yuwei, 2017-06-13 23:27:22]

PTAL thanks!

For the internal usage/implementation, please see:
https://chromereviews.googleplex.com/593117014

https://codereview.chromium.org/2937733003/diff/60001/remoting/ios/app/resour...
File
remoting/ios/app/resources/Assets.xcassets/ic_refresh.imageset/Contents.json
(left):

https://codereview.chromium.org/2937733003/diff/60001/remoting/ios/app/resour...
remoting/ios/app/resources/Assets.xcassets/ic_refresh.imageset/Contents.json:2:
"images" : [
The name "ic_refresh" gets collided with the one used by SSOAuth :(

[nicholss, 2017-06-14 15:19:18]

On 2017/06/13 23:27:22, Yuwei wrote:
> PTAL thanks!
> 
> For the internal usage/implementation, please see:
> https://chromereviews.googleplex.com/593117014
> 
>
https://codereview.chromium.org/2937733003/diff/60001/remoting/ios/app/resour...
> File
> remoting/ios/app/resources/Assets.xcassets/ic_refresh.imageset/Contents.json
> (left):
> 
>
https://codereview.chromium.org/2937733003/diff/60001/remoting/ios/app/resour...
>
remoting/ios/app/resources/Assets.xcassets/ic_refresh.imageset/Contents.json:2:
> "images" : [
> The name "ic_refresh" gets collided with the one used by SSOAuth :(

I think to solve this the better way would be to use ic_refresh from SSOAuth. If
the template is given a resource bundle target to depend on then we can choose
which icons are added to which build. No need including this twice with a
different name.

[nicholss, 2017-06-14 15:37:59]

I do not think the remoting_resource_factory is a good idea because it adds
complexity where we do not need it. I suggest instead to take a look at the
private implementation of the menu and create a chromium version that has the
same basic structure, and then private vs chromium include the correct menu view
controller.

I would assume you might need to wrap the private menu controller in something
that we can control the interface for, so if that was called
menu_view_controller, in chromium menu_view_controller interface would accept
the remoting_view_controller and do all the view creation and adding (don't
forget you also need to assign a parent view controller to be able to add view
controllers to view controllers) that needs to happen to get the host list to
display. This would be the chromium_menu_view_controller or some such name.

Then in private you make a private_menu_view_controller that is the same
interface as the chromium version, and perhaps this is injected into the app
delegate via the main method. 

The issue with what I see here is it is very not standard and you are doing a
lot of work to avoid duplicating ~10 lines of boilerplate code to start the app
up. It would be better done with an interface and dep injection from main into
app delegate.


As to the icon issue, again: I think we should pass in the asset bundle target
into the template and then we can customize it if needed on the private side. We
want the app size to be as small as possible.

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/BUILD.gn
File remoting/ios/app/BUILD.gn (right):

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/BUILD....
remoting/ios/app/BUILD.gn:41: "remoting_resource_factory_external.h",
please change external to chromium

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/main.mm
File remoting/ios/app/main.mm (right):

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/main.m...
remoting/ios/app/main.mm:12: #include "remoting/ios/app/app_initializer.h"
I think this is too complicated. If there needs to be special setup for private
vs chromium versions of main, I think we just reimplement the file on the
private side and leave the chromium version alone. This change adds a lot of
complexity and unusual naming conventions which makes it very hard to
understand.

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/remoti...
File remoting/ios/app/remoting_resource_factory.h (right):

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/remoti...
remoting/ios/app/remoting_resource_factory.h:12: @interface
RemotingResourceFactory : NSObject
A resource in iOS is an image or other static content. This implies that this
factory produces images and strings and stuff, not UIViewContollers.

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/remoti...
File remoting/ios/app/remoting_resource_factory_external.h (right):

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/remoti...
remoting/ios/app/remoting_resource_factory_external.h:12: // The Chromium
external implementation of the resource factory.
just chromium

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/remoti...
File remoting/ios/app/remoting_view_controller.mm (left):

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/remoti...
remoting/ios/app/remoting_view_controller.mm:79: initWithImage:[UIImage
imageNamed:@"ic_refresh"]
why are you renaming this asset?

[Yuwei, 2017-06-15 07:02:08]

PTAL

On 2017/06/14 15:37:59, nicholss wrote:
> I do not think the remoting_resource_factory is a good idea because it adds
> complexity where we do not need it. I suggest instead to take a look at the
> private implementation of the menu and create a chromium version that has the
> same basic structure, and then private vs chromium include the correct menu
view
> controller.

I added a simple container VC similar to GOOPanelVC for Chromium. I named it
PanelViewControllerChromium. Not sure whether it's good though...

> I would assume you might need to wrap the private menu controller in something
> that we can control the interface for, so if that was called
> menu_view_controller, in chromium menu_view_controller interface would accept
> the remoting_view_controller and do all the view creation and adding (don't
> forget you also need to assign a parent view controller to be able to add view
> controllers to view controllers) that needs to happen to get the host list to
> display. This would be the chromium_menu_view_controller or some such name.
>
> Then in private you make a private_menu_view_controller that is the same
> interface as the chromium version, and perhaps this is injected into the app
> delegate via the main method. 

The AppDelegate is not initialized until UIApplicationMain() is called and it
doesn't seem you can inject dependencies through init method or anything. I
implemented a PanelViewControllerFactory instead.

> The issue with what I see here is it is very not standard and you are doing a
> lot of work to avoid duplicating ~10 lines of boilerplate code to start the
app
> up. It would be better done with an interface and dep injection from main into
> app delegate.

Reverted that change. It's hard to inject argc and argv into AppDelegate so
let's keep it like this for now.

> As to the icon issue, again: I think we should pass in the asset bundle target
> into the template and then we can customize it if needed on the private side.
We
> want the app size to be as small as possible.

I'm not sure whether it's good to make assumption that the SSOAuth will always
include the ic_refresh imageset. We could add a dependency on
"//ios_internal/google_internal/piper/local_src/google3/googlemac/iPhone/Shared/Icons:ic_refresh",
but this will only work on the private build, or we can discuss offline.

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/BUILD.gn
File remoting/ios/app/BUILD.gn (right):

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/BUILD....
remoting/ios/app/BUILD.gn:41: "remoting_resource_factory_external.h",
On 2017/06/14 15:37:59, nicholss wrote:
> please change external to chromium

Done.

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/main.mm
File remoting/ios/app/main.mm (right):

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/main.m...
remoting/ios/app/main.mm:12: #include "remoting/ios/app/app_initializer.h"
On 2017/06/14 15:37:59, nicholss wrote:
> I think this is too complicated. If there needs to be special setup for
private
> vs chromium versions of main, I think we just reimplement the file on the
> private side and leave the chromium version alone. This change adds a lot of
> complexity and unusual naming conventions which makes it very hard to
> understand.

Removed.

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/remoti...
File remoting/ios/app/remoting_resource_factory.h (right):

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/remoti...
remoting/ios/app/remoting_resource_factory.h:12: @interface
RemotingResourceFactory : NSObject
On 2017/06/14 15:37:59, nicholss wrote:
> A resource in iOS is an image or other static content. This implies that this
> factory produces images and strings and stuff, not UIViewContollers.

Obsolete.

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/remoti...
File remoting/ios/app/remoting_resource_factory_external.h (right):

https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/remoti...
remoting/ios/app/remoting_resource_factory_external.h:12: // The Chromium
external implementation of the resource factory.
On 2017/06/14 15:37:59, nicholss wrote:
> just chromium

Done.

[nicholss, 2017-06-15 15:14:19]

On 2017/06/15 07:02:08, Yuwei wrote:
> PTAL
> 
> On 2017/06/14 15:37:59, nicholss wrote:
> > I do not think the remoting_resource_factory is a good idea because it adds
> > complexity where we do not need it. I suggest instead to take a look at the
> > private implementation of the menu and create a chromium version that has
the
> > same basic structure, and then private vs chromium include the correct menu
> view
> > controller.
> 
> I added a simple container VC similar to GOOPanelVC for Chromium. I named it
> PanelViewControllerChromium. Not sure whether it's good though...
> 
> > I would assume you might need to wrap the private menu controller in
something
> > that we can control the interface for, so if that was called
> > menu_view_controller, in chromium menu_view_controller interface would
accept
> > the remoting_view_controller and do all the view creation and adding (don't
> > forget you also need to assign a parent view controller to be able to add
view
> > controllers to view controllers) that needs to happen to get the host list
to
> > display. This would be the chromium_menu_view_controller or some such name.
> >
> > Then in private you make a private_menu_view_controller that is the same
> > interface as the chromium version, and perhaps this is injected into the app
> > delegate via the main method. 
> 
> The AppDelegate is not initialized until UIApplicationMain() is called and it
> doesn't seem you can inject dependencies through init method or anything. I
> implemented a PanelViewControllerFactory instead.
> 
> > The issue with what I see here is it is very not standard and you are doing
a
> > lot of work to avoid duplicating ~10 lines of boilerplate code to start the
> app
> > up. It would be better done with an interface and dep injection from main
into
> > app delegate.
> 
> Reverted that change. It's hard to inject argc and argv into AppDelegate so
> let's keep it like this for now.
> 
> > As to the icon issue, again: I think we should pass in the asset bundle
target
> > into the template and then we can customize it if needed on the private
side.
> We
> > want the app size to be as small as possible.
> 
> I'm not sure whether it's good to make assumption that the SSOAuth will always
> include the ic_refresh imageset. We could add a dependency on
>
"//ios_internal/google_internal/piper/local_src/google3/googlemac/iPhone/Shared/Icons:ic_refresh",
> but this will only work on the private build, or we can discuss offline.
> 
>
https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/BUILD.gn
> File remoting/ios/app/BUILD.gn (right):
> 
>
https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/BUILD....
> remoting/ios/app/BUILD.gn:41: "remoting_resource_factory_external.h",
> On 2017/06/14 15:37:59, nicholss wrote:
> > please change external to chromium
> 
> Done.
> 
> https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/main.mm
> File remoting/ios/app/main.mm (right):
> 
>
https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/main.m...
> remoting/ios/app/main.mm:12: #include "remoting/ios/app/app_initializer.h"
> On 2017/06/14 15:37:59, nicholss wrote:
> > I think this is too complicated. If there needs to be special setup for
> private
> > vs chromium versions of main, I think we just reimplement the file on the
> > private side and leave the chromium version alone. This change adds a lot of
> > complexity and unusual naming conventions which makes it very hard to
> > understand.
> 
> Removed.
> 
>
https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/remoti...
> File remoting/ios/app/remoting_resource_factory.h (right):
> 
>
https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/remoti...
> remoting/ios/app/remoting_resource_factory.h:12: @interface
> RemotingResourceFactory : NSObject
> On 2017/06/14 15:37:59, nicholss wrote:
> > A resource in iOS is an image or other static content. This implies that
this
> > factory produces images and strings and stuff, not UIViewContollers.
> 
> Obsolete.
> 
>
https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/remoti...
> File remoting/ios/app/remoting_resource_factory_external.h (right):
> 
>
https://codereview.chromium.org/2937733003/diff/80001/remoting/ios/app/remoti...
> remoting/ios/app/remoting_resource_factory_external.h:12: // The Chromium
> external implementation of the resource factory.
> On 2017/06/14 15:37:59, nicholss wrote:
> > just chromium
> 
> Done.




The pattern used elsewhere is to not make a new class for the chromium version,
but to make a file that makes it clear it is the chromium implementation and
still call the class it's normal name, ie:

panel_view_controller.h holds the interface for PanelViewController
panel_view_controller_chromium.m holds the implementation of PanelViewController
for chromium builds
panel_view_controller_private.m holds the implementation of PanelViewController
for private builds

The trick is you do not include panel_view_controller_chromium.m  in private
builds, this is what the template is used for, how you inject impl into the
build. 

If this is done then you don't need the factory and the code gets a lot simpler.

Also I think you still need to wrap the panel view on layer up to hide the impl
of the GOO side. So you really should be making a
app_with_menu_view_controller_(chromium | private).m and the private version
uses the goo panel internally, and the chromium version pops the current modal
window on request.

[nicholss, 2017-06-15 15:15:16]

https://codereview.chromium.org/2937733003/diff/180001/remoting/ios/app/app_d...
File remoting/ios/app/app_delegate.h (right):

https://codereview.chromium.org/2937733003/diff/180001/remoting/ios/app/app_d...
remoting/ios/app/app_delegate.h:18: @property(class, strong, nonatomic,
readonly) AppDelegate* currentDelegate;
I see this pattern naming would called "instance" but I am not sure why you need
this.

[Yuwei, 2017-06-15 21:22:18]

PTAL

> The pattern used elsewhere is to not make a new class for the chromium
version,
> but to make a file that makes it clear it is the chromium implementation and
> still call the class it's normal name, ie:
> 
> panel_view_controller.h holds the interface for PanelViewController
> panel_view_controller_chromium.m holds the implementation of
PanelViewController
> for chromium builds
> panel_view_controller_private.m holds the implementation of
PanelViewController
> for private builds
> 
> The trick is you do not include panel_view_controller_chromium.m  in private
> builds, this is what the template is used for, how you inject impl into the
> build. 

Done. I think we will also need to temporarily disable the private build target
to allow the file to be branched. X_X

> If this is done then you don't need the factory and the code gets a lot
simpler.

Acknowledged.

> Also I think you still need to wrap the panel view on layer up to hide the
impl
> of the GOO side. So you really should be making a
> app_with_menu_view_controller_(chromium | private).m and the private version
> uses the goo panel internally, and the chromium version pops the current modal
> window on request.

Done. I just called it AppViewController since it might be used for other things
like toggling the help&feedback modal. It feels like it's going back to the
ResourceFactory approach but in a more logical way.

Actually what about using the AppViewController as the branch point of the logic
rather than using the main function? This seems cleaner to me.


Also how should we deal with the ic_refresh stuff now? Shall we create a
separate Assets bundle for the private app that completely depend on the icon in
piper?
i.e.:
//ios_internal/google_internal/piper/local_src/google3/googlemac/iPhone/Shared/Icons:*

https://codereview.chromium.org/2937733003/diff/180001/remoting/ios/app/app_d...
File remoting/ios/app/app_delegate.h (right):

https://codereview.chromium.org/2937733003/diff/180001/remoting/ios/app/app_d...
remoting/ios/app/app_delegate.h:18: @property(class, strong, nonatomic,
readonly) AppDelegate* currentDelegate;
On 2017/06/15 15:15:16, nicholss wrote:
> I see this pattern naming would called "instance" but I am not sure why you
need
> this.

Renamed to `instance`.

I added this to simplify code to access the AppViewController, otherwise I'll
need something like:

((AppDelegate*)UIApplication.sharedApplication.delegate).appViewController

[Yuwei, 2017-06-15 22:19:39]

The CQ bit was checked by yuweih@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-15 22:20:04]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-15 22:23:28]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-15 22:23:29]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Yuwei, 2017-06-15 23:38:12]

PTAL thanks!

Fixed according to our discussion. I'll need to temporary disable the private
target to yield for the change.

Also I'll send another CL to fix the resource issue.

[nicholss, 2017-06-19 16:32:10]

https://codereview.chromium.org/2937733003/diff/340001/remoting/ios/app/app_v...
File remoting/ios/app/app_view_controller.h (right):

https://codereview.chromium.org/2937733003/diff/340001/remoting/ios/app/app_v...
remoting/ios/app/app_view_controller.h:16: // For adding new method, please make
sure the method is implemented privatel
Fix typos: "methods" or "a new method", "privately"

To ensure there is a mirror of methods you can make a protocol.

setMenuVisible is not a good iOS name. It should be two methods
showMenuAnimated: and hideMenuAnimated:. The set verb is normally only used for
setters. This implies that you are setting the property "menuVisible".

https://codereview.chromium.org/2937733003/diff/340001/remoting/ios/app/app_v...
remoting/ios/app/app_view_controller.h:23: - (void)requestSignIn;
I don't think you mean request, this implies that there will be a call to the
sign-in server, I think you mean presentSignIn.

In iOS the naming matters a lot for clarity. In usage the methods are suppose to
read like language.

https://codereview.chromium.org/2937733003/diff/340001/remoting/ios/app/app_v...
remoting/ios/app/app_view_controller.h:25: @property(nonatomic)
UIViewController* mainViewController;
mainViewController should be readonly, but I don't understand why you need this.

https://codereview.chromium.org/2937733003/diff/340001/remoting/ios/app/app_v...
File remoting/ios/app/app_view_controller_chromium.mm (right):

https://codereview.chromium.org/2937733003/diff/340001/remoting/ios/app/app_v...
remoting/ios/app/app_view_controller_chromium.mm:1: // Copyright 2016 The
Chromium Authors. All rights reserved.
2017

https://codereview.chromium.org/2937733003/diff/340001/remoting/ios/app/app_v...
remoting/ios/app/app_view_controller_chromium.mm:28: _menuController =
[[RemotingMenuViewController alloc] init];
It would be better to lazy init the menu controller, delay the alloc/init until
the menu is requested. There are many times where the user will never click on
the menu so no need to have it using memory and slowing down the app startup
time.

[Yuwei, 2017-06-19 19:17:27]

PTAL thanks!

https://codereview.chromium.org/2937733003/diff/340001/remoting/ios/app/app_v...
File remoting/ios/app/app_view_controller.h (right):

https://codereview.chromium.org/2937733003/diff/340001/remoting/ios/app/app_v...
remoting/ios/app/app_view_controller.h:16: // For adding new method, please make
sure the method is implemented privatel
On 2017/06/19 16:32:09, nicholss wrote:
> Fix typos: "methods" or "a new method", "privately"
> 
> To ensure there is a mirror of methods you can make a protocol.
> 
> setMenuVisible is not a good iOS name. It should be two methods
> showMenuAnimated: and hideMenuAnimated:. The set verb is normally only used
for
> setters. This implies that you are setting the property "menuVisible". 

Done.

https://codereview.chromium.org/2937733003/diff/340001/remoting/ios/app/app_v...
remoting/ios/app/app_view_controller.h:23: - (void)requestSignIn;
On 2017/06/19 16:32:10, nicholss wrote:
> I don't think you mean request, this implies that there will be a call to the
> sign-in server, I think you mean presentSignIn.
> 
> In iOS the naming matters a lot for clarity. In usage the methods are suppose
to
> read like language. 

Done.

https://codereview.chromium.org/2937733003/diff/340001/remoting/ios/app/app_v...
remoting/ios/app/app_view_controller.h:25: @property(nonatomic)
UIViewController* mainViewController;
On 2017/06/19 16:32:10, nicholss wrote:
> mainViewController should be readonly, but I don't understand why you need
this.

This is used to set the main VC to be shown on AppViewController. I moved the
assignment into the init method to simplify it.

https://codereview.chromium.org/2937733003/diff/340001/remoting/ios/app/app_v...
File remoting/ios/app/app_view_controller_chromium.mm (right):

https://codereview.chromium.org/2937733003/diff/340001/remoting/ios/app/app_v...
remoting/ios/app/app_view_controller_chromium.mm:1: // Copyright 2016 The
Chromium Authors. All rights reserved.
On 2017/06/19 16:32:10, nicholss wrote:
> 2017

Oops... Done.

https://codereview.chromium.org/2937733003/diff/340001/remoting/ios/app/app_v...
remoting/ios/app/app_view_controller_chromium.mm:28: _menuController =
[[RemotingMenuViewController alloc] init];
On 2017/06/19 16:32:10, nicholss wrote:
> It would be better to lazy init the menu controller, delay the alloc/init
until
> the menu is requested. There are many times where the user will never click on
> the menu so no need to have it using memory and slowing down the app startup
> time.

Done.

[nicholss, 2017-06-19 22:36:49]

lgtm thanks for the work!

[Yuwei, 2017-06-19 22:56:36]

The CQ bit was checked by yuweih@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-19 22:56:59]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-20 00:51:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-20 00:51:01]

Dry run: This issue passed the CQ dry run.

[Yuwei, 2017-06-20 20:45:27]

On 2017/06/19 22:36:49, nicholss wrote:
> lgtm thanks for the work!

Thanks! I'll need to wait until the private target being disabled to check in
though...

[Yuwei, 2017-06-20 21:10:21]

The CQ bit was checked by yuweih@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-20 21:11:05]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Yuwei, 2017-06-20 21:40:30]

The CQ bit was unchecked by yuweih@chromium.org

[Yuwei, 2017-06-20 21:40:35]

The CQ bit was checked by yuweih@chromium.org

[Yuwei, 2017-06-20 21:40:35]

The patchset sent to the CQ was uploaded after l-g-t-m from
nicholss@chromium.org
Link to the patchset: https://codereview.chromium.org/2937733003/#ps400001
(title: "Fix presenting check")

[commit-bot: I haz the power, 2017-06-20 21:41:01]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-20 23:09:39]

CQ is committing da patch.

Bot data: {"patchset_id": 400001, "attempt_start_ts": 1497994835081860,
"parent_rev": "95d8be7f74506f6517885ab3a4571edfcecbc764", "commit_rev":
"37f9cdbf07a28191df478111e73479ca5c0f2df6"}

[commit-bot: I haz the power, 2017-06-20 23:09:55]

CQ is committing da patch.

Bot data: {"patchset_id": 400001, "attempt_start_ts": 1497994835081860,
"parent_rev": "09f1ab2c6026d5f6dfe699e1e2400d5c7c4105de", "commit_rev":
"4a13a977ca3b4db548fae2cf14990e797688bb79"}

[commit-bot: I haz the power, 2017-06-20 23:10:09]

Description was changed from

==========
[CRD iOS] Branching internal and external implementations

This CL:

* Introduces the RemotingResourceFactory class for providing different resources
  depending on whether it's an external or internal build.
* Adds an AppInitializer for initializing common resources.

BUG=731851
==========

to

==========
[CRD iOS] Branching internal and external implementations

This CL:

* Introduces the RemotingResourceFactory class for providing different resources
  depending on whether it's an external or internal build.
* Adds an AppInitializer for initializing common resources.

BUG=731851

Review-Url: https://codereview.chromium.org/2937733003
Cr-Commit-Position: refs/heads/master@{#481006}
Committed:
https://chromium.googlesource.com/chromium/src/+/4a13a977ca3b4db548fae2cf1499...
==========

[commit-bot: I haz the power, 2017-06-20 23:10:11]

Committed patchset #18 (id:400001) as
https://chromium.googlesource.com/chromium/src/+/4a13a977ca3b4db548fae2cf1499...