On Mon, Mar 21, 2016, at 10:27, Hans-Christoph Steiner wrote: > Can you explain the rationale behind using the StrongBuilderBase?
It represents the common builder code for all four concrete builders. Two of the builders (StrongConnectionBuilder for HttpURLConnection and StrongVolleyQueueBuilder for Volley) just extend StrongBuilderBase. One of the builders (StrongHttpClientBuilder for HttpClient) uses delegation, because HttpClient already has HttpClientBuilder. Rather than require two separate builders, StrongHttpClientBuilder extends HttpClientBuilder (to inherit stock HttpClientBuilder behavior). However, StrongHttpClientBuilder also implements the StrongBuilder interface and forwards all those methods to a StrongBuilderBase instance. This allows StrongHttpClientBuilder to offer both APIs (HttpClientBuilder and StrongBuilder) in one class with minimal code duplication. One of the builders (StrongOkHttpClientBuilder for OkHttp3) should take the approach used for StrongHttpClientBuilder. It doesn't -- once again, it was a deadline thing for the book release. > Yeah, we'll need to also do this for the existing ch.boye code there as > well. I'm thinking that the maven artifacts should be called: > > netcipher (the common one with the HttpsURLConnection stuff too) > netcipher-chboye > netcipher-httpclient > netcipher-okhttp3 > netcipher-volley OK. Note that pulling the chboye stuff out will resulting a breaking change for all existing NetCipher users (unless netcipher depends on netcipher-chboye, which I would not recommend). Otherwise, this seems reasonable. From a GitHub repo standpoint, I presume that this means that my netcipher-hurl code moves into libnetcipher. > I imagine will want to entirely ditch the ant/eclipse stuff in > netcipher.git at this point, and switch it all to gradle and Android > Studio. I stuck with eclipse so far because it seemed really painful to > get the JUnit test suite working with gradle+Android Studio. That shouldn't be too bad now, at least if you're willing to stick with instrumentation testing (i.e., running in Android) and not unit testing (i.e., running on the JVM). There aren't too many resources in this code. If we move them all elsewhere (e.g., assets, simple Java constants), we can make JARs available for download for those who are not using artifact-based build systems, such as legacy Android Eclipse development. We would need to document what beyond the JARs would be needed. > Also, I think we want to de-emphasis the custom keystore stuff. Maybe > we should not even include it in the new APIs, just leave it as is in > the ch.boye stuff... But I worry about the lack of tests and the maintenance. That's your call. Note that in the N Developer Preview, it appears that apps can supply their own CA keystore declaratively (manifest entry pointing to XML metadata resource pointing to the keystore). I haven't played with that yet, but it's on my to work on in the next month. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
