Refactoring out the chromoting jni runtime class in favor of chromoting client runtime.

remoting/client/jni/chromoting_jni_instance.h

 // Copyright 2013 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 REMOTING_CLIENT_JNI_CHROMOTING_JNI_INSTANCE_H_
 #define REMOTING_CLIENT_JNI_CHROMOTING_JNI_INSTANCE_H_
 
 #include <memory>
 #include <string>
 
@@ skipping 14 matching lines @@
 
 namespace remoting {
 
 namespace protocol {
 class ClipboardEvent;
 class PerformanceTracker;
 class VideoRenderer;
 }  // namespace protocol
 
 class AudioPlayerAndroid;
-class ChromotingJniRuntime;
+class ChromotingClientRuntime;
 class JniClient;
 class JniPairingSecretFetcher;
 
 // ChromotingJniInstance is scoped to the session.
 // This class is Created on the UI thread but thereafter it is used and
 // destroyed on the network thread. Except where indicated, all methods are
 // called on the network thread.
 class ChromotingJniInstance
   : public ClientUserInterface,
     public protocol::ClipboardStub {
  public:
   // Initiates a connection with the specified host. Call from the UI thread.
   // The instance does not take ownership of |jni_runtime|. To connect with an
   // unpaired host, pass in |pairing_id| and |pairing_secret| as empty strings.
-  ChromotingJniInstance(ChromotingJniRuntime* jni_runtime,
-                        base::WeakPtr<JniClient> jni_client,
+  ChromotingJniInstance(base::WeakPtr<JniClient> jni_client,

[nicholss, 2017/03/10 19:04:28]

So this is a change I am not 100% sure about, I chose to pull the runtime from
the static instance method. 

The downside is this means the runtime is not injectable for tests, but we do
not do this currently. The upside is it makes the client code easier to
understand. But perhaps a little magical. No more pushing around pointers to a
runtime object, just ask the singleton for it's runtime object. 

For tests we could build them without the runtime singleton and link in our own
test version if it comes to that.

[Yuwei, 2017/03/10 20:18:53]

Maybe the real runtime object is good enough for the tests. Mocking task runners
inside the runtime is nontrivial anyways... Also given that the runtime is just
a combination of global resources, you may just write some test-only setters for
test.

                         base::WeakPtr<JniPairingSecretFetcher> secret_fetcher,
                         std::unique_ptr<protocol::CursorShapeStub> cursor_stub,
                         std::unique_ptr<protocol::VideoRenderer> video_renderer,
                         const ConnectToHostInfo& info);
 
   ~ChromotingJniInstance() override;
 
   // Starts the connection. Can be called on any thread.
   void Connect();
 
@@ skipping 73 matching lines @@
   void EnableStatsLogging(bool enabled);
 
   // If logging is enabled, logs the current connection statistics, and
   // triggers another call to this function after the logging time interval.
   // Called on the network thread.
   void LogPerfStats();
 
   // Releases the resource in the right order.
   void ReleaseResources();
 
-  // Used to obtain task runner references and make calls to Java methods.
-  ChromotingJniRuntime* jni_runtime_;
+  // Used to obtain task runner references.
+  ChromotingClientRuntime* runtime_;
 
   base::WeakPtr<JniClient> jni_client_;
 
   base::WeakPtr<JniPairingSecretFetcher> secret_fetcher_;
 
   ConnectToHostInfo connection_info_;
 
   protocol::ClientAuthenticationConfig client_auth_config_;
 
   // This group of variables is to be used on the network thread.
@@ skipping 35 matching lines @@
 
   base::WeakPtr<ChromotingJniInstance> weak_ptr_;
   base::WeakPtrFactory<ChromotingJniInstance> weak_factory_;
 
   DISALLOW_COPY_AND_ASSIGN(ChromotingJniInstance);
 };
 
 }  // namespace remoting
 
 #endif  // REMOTING_CLIENT_JNI_CHROMOTING_JNI_INSTANCE_H_