Closed cianclarke closed 12 years ago
Initial implmentation should mimic the existing studio.
Key is to get functionality from current product added to new studio.
We can iterate to improve once it's there.
fhc configuration list <app id>
lists current configuration for given app. However I see no possibility to list what can be set. For instance, I can set iPhone's "activity spinner" to "top", "center" or "hidden". Fhc configuration
says me that this config field is set to "top", but gives no means to learn that other allowed values are "center" and "hidden". I could hardcode that in Studio, but I doubt that it is the best option. Imagine that at some point Apple will add "bottom" option or you'll want to add another configuration field – all this would require devs to upgrade their Studio. And what if you are switching between two targets which run different versions of software? Possible fhc
should have another command fhc configuration options
which would return all available options including constraints and possibly hints.
My other question refers to "implement as fieldset/legend. This should as a first step read the key parts of 'fhc config list', and group based on these per destination. Anything that doesn't fall into our group goes to an 'other' section." In my understanding currently nothing falls to "other", did I get it right?
1) These values are not currently returned from the server, so for now we can put this in the template..
2) Perhaps I didn't explain properly, but for each destination (iPhone, Android, ..) the form would be broken up into many sections, rather than how it is at present - one long section.
Section titles might include: *(Device-Specific || Native) Configuration, including
but these are just suggestions Thanks CIan
Thanks a lot, now I got it.
Closing as of merge of skalee/skalee3
New UI should be tabbed - with Bootstrap 2.0 pill boxes on the left for each platform. Some kind of mockups / whiteboarding is needed, as the current implementation of configuration has grown columnar.
implement as fieldset/legend. This should as a first step read the key parts of 'fhc config list', and group based on these per destination. Anything that doesn't fall into our group goes to an 'other' section.