On 12/2/13 11:29 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote:
>>I think mozilla's custom properties is more on the right track. IOW, >>what is it about the screen that is or isn't changing? >>Whatever it is, while it got introduced in IOS 7, it doesn't mean that >>whatever it is won't be implemented in other OS's over time, or that >>there will someday be an option to turn that thing on and off. So if it >>is a status >bar appearing, maybe the property should simply be called >>pop-up-status-bar, or maybe the code should be watching for changes to >>screen-height or something like that. > >I see what you mean. Mozilla has other props like that: >" -moz-scrollbar-thumb-proportional" > >So it could be implemented as : >"-flex-status-bar-overlap" >And maybe: >"-ios-theme"=ios7|classic > >But technically, there is no way of knowing that the status bar is >overlapping, based on "os-independent"screen change). >The only valid test at the moment is the following: >- OS=iOS and version >= 7 + other iOS specific settings in air descriptor >file. > >Same for ios-theme => the internal test is based on the os+version. The internal test may have to trigger on os-version or other system.Capabilities info for now, but that's ok, IMO. If some future IOS makes status-bar-overlap optional, hopefully AIR will provide a way to find that out (or we'll make an ANE that can do that). Again, I don't really understand this particular issue, but why don't other non-Flex IOS apps have to react to this difference when running on IOS? Or are they? > > Another point is that this same "os-version" prop was meant to be used >for seting different skins for different versions of Androids ( >suggestion from Om) >Here again, we could have defined android-specific props such as: >"-flex-android-theme=A|B|C" Yes, if the theme can be determined and that is what matters to the code. You never know when the next version of Android will allow a choice of skins/themes. -Alex
