Mark Murphy: > 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 mean using Android patterns rather than Java patterns, like BroadcastReceiver/LocalBroadcastManager instead of callbacks and interfaces. We are in agreement on the target audience. This should work for all Android devs, as much as possible. I think the callbacks are clean, I guess my head has been more in event-based messaging and Android APIs. .hc >> 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. > -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
