[NTP Snippets] Schedule periodic fetching

components/ntp_snippets/ntp_snippets_scheduler.h

+// Copyright 2016 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 COMPONENTS_NTP_SNIPPETS_NTP_SNIPPETS_SCHEDULER_H_
+#define COMPONENTS_NTP_SNIPPETS_NTP_SNIPPETS_SCHEDULER_H_
+
+namespace ntp_snippets {
+
+// Interface to schedule the periodic fetching of snippets.
+class NTPSnippetsScheduler {

[noyau (Ping after 24h), 2016/02/22 11:58:49]

I'm confused about the connection between this class and the snippet service.
What method does the scheduler call back on the service to do the fetch ? Can it
be documented on a Scheduler observer of some sort? How will the scheduler deal
with backing up when the download fails, or if the download takes a long time?
Who own instance of these classes, as apparently the service is not?

My problem is that I'm looking at this code and I don't understand what I have
to do to implement a concrete class on iOS. I'm also worried that the concrete
implementation for this is all in java, and as such completely unusable on iOS.
What is the reason for not implementing this in C++? It seems to me that having
common code between the platform would be a plus, keeping only the UI different.

Is there a scheduler code that can be reused from component updater for example?

[Bernhard Bauer, 2016/02/22 12:05:12]

The component updater does not use the Android scheduling mechanism ATM, so it
will only schedule tasks while Chrome is running (which is a known issue). If
anything, we could eventually start using the Android implementation here for
the component updater as well, but we will need an implementation in Java.

[Marc Treib, 2016/02/22 12:44:31]

Currently it just calls FetchSnippets on the service. I've added a comment on
the Scheduler interface saying that. IMO an extra observer is overkill at this
point, particularly since the specifics are likely to change soon.

Any logic to handle failed downloads etc will live in the service (so far, we
don't have any), so it'll be shared between platforms.
It's a singleton, because that's what makes sense on the Java side, and as long
as we only have an Android implementation there's no need to complicate things
here. If necessary, it'll be easy to add a wrapper around the singleton, so that
the service can own that.
Re common code, absolutely. But all the scheduler implementation does is call
some Android OS functions, so there's no way to share it.
All the actual logic for scheduling will live in the service.

+ public:
+  virtual bool Schedule(int period_seconds) = 0;
+  virtual bool Unschedule() = 0;
+};
+
+}  // namespace ntp_snippets
+
+#endif  // COMPONENTS_NTP_SNIPPETS_NTP_SNIPPETS_SCHEDULER_H_