Initial implementation of Cronet Async API.

components/cronet/android/java/src/org/chromium/net/UrlRequestListener.java

Index: components/cronet/android/java/src/org/chromium/net/UrlRequestListener.java
diff --git a/components/cronet/android/java/src/org/chromium/net/UrlRequestListener.java b/components/cronet/android/java/src/org/chromium/net/UrlRequestListener.java
index a0a537d041643255caee33870e96997921be1baa..663d192f4f869fbde76791e7f5d214efad0da9c0 100644
--- a/components/cronet/android/java/src/org/chromium/net/UrlRequestListener.java
+++ b/components/cronet/android/java/src/org/chromium/net/UrlRequestListener.java
@@ -41,16 +41,19 @@ public interface UrlRequestListener {
      * Cancelling the request also invalidates the buffer.
      *
      * @param request Request that received data.
+     * @param info Response information.
      * @param byteBuffer Received data.
      */
-    public void onDataReceived(UrlRequest request, ByteBuffer byteBuffer);
+    public void onDataReceived(UrlRequest request,
+            ResponseInfo info, ByteBuffer byteBuffer);
 
     /**
      * Called when request is complete, no callbacks will be called afterwards.
      *
      * @param request Request that is complete.
+     * @param info Response information.
      */
-    public void onComplete(UrlRequest request);
+    public void onComplete(UrlRequest request, ResponseInfo info);

[Charles, 2014/09/26 22:52:26]

Do we still need to pass the UrlRequest? Why not just the ResponseInfo?

[mef, 2014/09/29 17:57:37]

I've chatted with Matt and we've agreed to keep it there for consistency.

[Charles, 2014/09/29 18:10:34]

I don't understand. There are no methods that could possibly be called on it, it
provides absolutely no value to the embedder. All it does is add confusion and
the possibility for leaking a dead object. Consistency is only of value when it
lets the consumer of the API intuit the behavior of some API based on their
knowledge of the rest, which this doesn't do - the intuition of the embedder
will lead them to do the wrong thing, like cancelling the request in onError
when it's already done for you. Adding a parameter that you can't/shouldn't
touch is confusing and unnecessary.  

[mmenke, 2014/09/29 19:26:46]

The embedder should be able to uniquely identify the request a response came
from, unless we want to force the embedder to use a separate listener for every
request.  The only way to do this is either through the use of a request ID
(Which we could either provide, or take from the embedder), or passing the
UrlRequest for pointer comparison.

The URL is insufficient, as there may be multiple requests for a single URL
(Particularly for POSTs - Knowing the URL was "https://www.googleapis.com/rpc",
for instance, isn't terribly useful, since it's quite possible we have a bunch
of POSTs to different services that all use the same URL).

[mmenke, 2014/09/29 19:28:36]

Oh, and I should add, if we do want to force the embedder to use one listener
per request, I think we should get rid of the UrlRequest parameter completely -
the embedder created the request and set up the listener, so seems reasonable to
expect them to track it as well.

[Charles, 2014/09/29 19:52:50]

What is the use case where multiple listeners are useful? Anywhere you want the
request body you're going to need a listener per request, so that limits this to
posts. Where are we doing a whole bunch of concurrent posts? Are you envisioning
the listener maintaining a map of UrlRequests -> success stats?

 
     /**
      * Can be called at any point between start() and onComplete().  Once
@@ -58,8 +61,10 @@ public interface UrlRequestListener {
      * provides information about error.
      *
      * @param request Request that received an error.
+     * @param info Response information.
      * @param error information about error.
      */
     public void onError(UrlRequest request,
+                        ResponseInfo info,
                         UrlRequestException error);
 }