chrome/browser/media/router/media_route_provider_util.h - Issue 1821823002: [Media Router] Conditionally enable mDNS on Windows.

Side by Side Diff: chrome/browser/media/router/media_route_provider_util.h

Issue 1821823002: [Media Router] Conditionally enable mDNS on Windows. (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: Fixed compile and build dependency issues Created 4 years, 9 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

« no previous file with comments | « chrome/browser/media/android/router/media_router_android.cc ('k') | chrome/browser/media/router/media_route_provider_util.cc » ('j') | chrome/browser/media/router/media_route_provider_util.cc » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
(Empty)
	1 // Copyright 2016 The Chromium Authors. All rights reserved.

	2 // Use of this source code is governed by a BSD-style license that can be

	3 // found in the LICENSE file.

	4

	5 #ifndef CHROME_BROWSER_MEDIA_ROUTER_MEDIA_ROUTE_PROVIDER_UTIL_H_

	6 #define CHROME_BROWSER_MEDIA_ROUTER_MEDIA_ROUTE_PROVIDER_UTIL_H_

	7

	8 #include "chrome/browser/media/router/media_router_mojo_impl.h"

	9

	10 namespace media_router {

	11

	12 #if defined(OS_WIN)
	mark a. foltz 2016/03/24 22:59:32 If you name these media_router_provider_util_win.{ If you name these media_router_provider_util_win.{h,cc}, then they will only be included in the Windows build. https://gyp.gsrc.io/docs/UserDocumentation.md#Add-new-source-files btolsch 2016/03/25 04:40:50 Done but should I leave the include in media_route Show quoted text On 2016/03/24 22:59:32, mark a. foltz wrote: > If you name these media_router_provider_util_win.{h,cc}, then they will only be > included in the Windows build. > > https://gyp.gsrc.io/docs/UserDocumentation.md#Add-new-source-files > > Done but should I leave the include in media_router_mojo_impl.cc or guard that with another #if defined(OS_WIN)?
	13 void CanFirewallUseLocalPorts(MediaRouterMojoImpl* router);
	mark a. foltz 2016/03/24 22:59:33 It's not a good pattern to pass a pointer to the c It's not a good pattern to pass a pointer to the caller call back on it directly. Instead have the caller pass a base::Closure and have this method call .Run() in it. From an API point of view, I would have passed a base::Callback<void(bool)> and have the caller decide how to handle the positive or negative result (versus requiring the negative case be a no-op). But I don't feel strongly since this is only used in one place. mark a. foltz 2016/03/24 23:02:10 Correction: Have this method post a task to run i Show quoted text On 2016/03/24 at 22:59:33, mark a. foltz wrote: > It's not a good pattern to pass a pointer to the caller call back on it directly. Instead have the caller pass a base::Closure and have this method call .Run() in it. Correction: Have this method post a task to run it :) Show quoted text > From an API point of view, I would have passed a base::Callback<void(bool)> and have the caller decide how to handle the positive or negative result (versus requiring the negative case be a no-op). But I don't feel strongly since this is only used in one place. btolsch 2016/03/25 04:40:50 Done. Show quoted text On 2016/03/24 22:59:33, mark a. foltz wrote: > It's not a good pattern to pass a pointer to the caller call back on it > directly. Instead have the caller pass a base::Closure and have this method > call .Run() in it. > > From an API point of view, I would have passed a base::Callback<void(bool)> and > have the caller decide how to handle the positive or negative result (versus > requiring the negative case be a no-op). But I don't feel strongly since this > is only used in one place. Done.
	14 #endif

	15

	16 } // namespace media_router

	17

	18 #endif // CHROME_BROWSER_MEDIA_ROUTER_MEDIA_ROUTE_PROVIDER_UTIL_H_

OLD	NEW