On Thu, Sep 3, 2015 at 2:49 AM, Sebastian Kaspari <[email protected]> wrote:
> I don't know of any good code pattern to prevent this (does anyone?). > While I don't know of any official code pattern, I have an (overly complex?) idea: all components that wish to access private browsing can register "private browsing state" listeners. When the state changes (or when they initially register), they will be passed a "private browsing interface" Object that allows them to access private browsing methods, including privateBrowsing.isAvailable() (or similar). If isAvailable returns null, we can throw. Note that the *only* way to access private browsing would be through this interface. I can't recall the private browsing APIs though, so this might fundamentally change the way we interact with the Tabs/Tab classes and be a cause for too much refactoring. One concern here is memory leaks – we have to remove the listeners and I'm not sure there's a good way to do this automagically (onAttach/onDetach for Views?). This problem goes away if the state is consistent throughout an instance of the application (i.e. we restart when changing state) and we grab the state on startup. - Mike
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
