I have a design question.
I’m using the HttpURLConnection class to navigate a website. In order to obtain an HttpURLConnection instance, I have a local getter method. This is responsible for setting all the request properties, including possible cookies. Anyway, throughout the life cycle of this application, I use multiple HttpURLConnection instances. And never is there more than one open connection.
Anyway, I have another local method for sending requests in the form of an HTTP POST. Here is the code:
private final InputStream sendRequest(final HttpURLConnection conn, final String content){
InputStream in = null;
DataOutputStream out = null;
try{
// Write data out to the stream
out = new DataOutputStream(conn.getOutputStream());
out.writeBytes(content);
out.flush();
// Get the input stream
in = conn.getInputStream();
}
catch(IOException e){
e.printStackTrace();
}
finally{
try
{
if(out != null){
out.close();
}
}
catch(IOException e){
e.printStackTrace();
}
}
return in;
}
As you can see, as soon as I’m done writing out the content, I open an input stream on the connection and return it. The reason I do this is if I do not open the input stream on the connection, the application will hang. Therefore, I’m leaving it up to the caller as to whether or not they want to parse the incoming content. Also, the caller needs the connection instance because I leave it up to them to disconnect (that is, close the connection).
So, I guess my question is, is this a poor design? That is, opening the input stream of the connection object that the caller already has an instance of and then returning it?
It’s a shame you’re not allowed to use Apache HttpClient, but a little OOP may help you untangle your code.
Introduce a
ResponseHandlerinterface for the caller to implement. You might also want to provide some out-of-the-box implementations inpublic staticfields (if thread-safe) or via factory methods for the common cases like “give me a String” (make sure to consult the “charset” part of the response’sContent-Encodingheader when creating yourInputStreamReader) and “give me a byte[]”.Don’t supply just the
InputStreamto theResponseHandleras you might need access to the response headers for character encoding, etc.Again, this would really be much much nicer with HttpClient :/
(the following code lacks basic sanity checks for the parameters, please add them)
Edit: If you can somehow managed to get rid of
HttpUrlConnectionin the calling code, that would be even better. Check out if you can get along with aStringfor the URL and aMap<String, Object>for the parameters, maybe wrap this in aHttpRequestobject.