On Mon, Mar 21, 2016, at 11:09, Hans-Christoph Steiner wrote: > The Builder pattern makes perfect sense with HttpClient, where that > pattern is already used. It feels heavy for HttpURLConnection.
IMHO, consistency is key. > Also, about the interface, I think that's a very Java-ish approach, and > I could see some devs preferring that. I attempted to model the API after the ones used in Square's projects, generally hailed as some of the cleanest APIs in Android development. > I've been thinking mostly that devs will implement their own > BroadcastReceiver and pass that it, but I guess that doesn't work on > OkHTTP. OrbotInitializer and its internally-managed receiver are there to simplify the API. However, OrbotIinitializer is not a requirement for any of the builders. I don't get into it much in that chapter, but there is a version of apply() that takes the status Intent as input, if you got that independently. For OkHttp3, you'll find that at: https://github.com/commonsguy/cw-omnibus/blob/master/Internet/HTTPStacks/netcipher-okhttp3/src/main/java/info/guardianproject/netcipher/okhttp3/StrongOkHttpClientBuilder.java#L81-L102 (or https://goo.gl/QnS3f5 if that URL is too long) Given a choice between "roll your own receiver" or "let OrbotInitializer handle that", I would expect that most Android developers would be happy to to let OrbotInitializer handle that. I suppose part of my confusion comes from a failure on my part: I didn't ask who the audience is for NetCipher, particularly for these improvements. I had assumed that the audience was "all Android developers". Your comments suggest that you're aiming at a more-expert subset. I built a layered API with an eye towards offering flexibility for experts and simplicity for non-experts. > If we're sticking all this stuff in NetCipher anyway, then > going the full Android approach is more appealing to me. I do not know what "the full Android approach" means here. > I think > that this custom keystore approach could be simple and maintainable if > we provide a class or script that will automatically generate the custom > keystore for users. Even better, it would happen automatically from > gradle. I see it like this: > > * download keystore from Debian or Mozilla > * download the certificate app's provided hostname > * read the CA from that certificate > * prepare a custom keystore by grabbing only that CA from the > Debian/Mozilla keystore > * include that keystore in the app IIRC, the XML specification for the N Developer Preview supports multiple domains. That doesn't preclude what you're describing, but it adds to the complexity. Again, I haven't dived into this much yet. Your approach is interesting, though. -- 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]
