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. > * 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. > If you want to do it via pull requests, I'd do it one per HTTP API, and > another for the Orbot stuff. I'm not aware of other options for getting my stuff into your repo, other than pull requests, and possibly butterflies. https://xkcd.com/378/ Thanks! -- 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: guardian-dev-unsubscr...@lists.mayfirst.org