> > … I don't want to overcomplicate the design now based upon a future > requirement that we might not implement for a long time, if ever. >
This. We have so much else on our list of things to do that as soon as the menu as-is tests well, we'll be prioritizing other work. We might find that we never even want to ship any kind of customization, even if we found the time. Either way, thinking about the challenges of user configuration will help > us make design decisions now that will allow for ease of extendability > later. > I think you already have! Here's what we do on Android for our customizable home panels. Note that there's some extra complexity because add-ons can provide panels, so they have to store their title etc. — we don't. https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/home/HomeConfig.java#103 https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/home/HomePanelsManager.java#75 Pretty straightforward: enum for type, read and write a config to backing storage, implement an Editor (these days a Lens!) to modify. We have a few different types of menu (PB, tabs tray, main…) but the principle stays the same: you already have a collection view setup, so we'd make the backing data dynamic and write that data from some editing view. In short, I think you're already in a place with your design that will let us bolt on customization later with minimal changes.
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
