Mark Murphy: > On Fri, Mar 25, 2016, at 05:36, Hans-Christoph Steiner wrote: >> * why did you use the custom WeakSet class rather than just a plain Set? > > To help prevent memory leaks, in case clients fail to unregister their > callbacks.
I'd prefer to error/warn the user about this rather than reducing the impact of doing the wrong thing. I vaguely remember seeing such warnings in logcat. >> * keep things as a JAR as much as possible, not an AAR, i.e. by avoiding >> string resources, etc. I find it makes the library a lot easier to >> deploy in a variety of situations (ant!). > > What do you want to do about the keystore? > > In my sample, I moved that to an asset, as I was having problems > referencing the raw resource across library module boundaries. However, > if you're aiming to change packaging to be a JAR instead of your current > AAR, then the keystore cannot be either a raw resource or an asset. > > Options include: > > - Remove the keystore references from my code entirely, with an eye > towards revamping all this (e.g., your proposed "make it look like > Android N" approach). > > - Leave the keystore references more or less as-is, and tell users of > the library that they need to put the keystore in the proper spot in > assets/ (i.e., the old SQLCipher approach, before they switched to the > AAR). > > - Add something (to OrbotHelper?) that exposes the keystore from raw > resources via a Java API, then have my code use that API, and leave the > raw resource where it is, requiring AAR packaging. > > - Attempt to switch this to an old-style Java JAR resource (note: not > recommended, as I worry that the Android tools team will eventually > break that). > > And there may be other options that I'm not thinking of, as I just woke > up. I'm saying remove the keystore references from your code entirely, for now at least. I think that approach could be good, but I'd like to have it wrapped in a proper test suite before deploying it any more. Right now, the focus of this round of work is improved proxy/tor integration. .hc -- 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]
