On Mon, Dec 2, 2013 at 11:41 AM, Alex Harui <aha...@adobe.com> wrote:
> > > 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? > They are having to. Either via direct APIs [1] or through hacks [2] Thanks, Om [1] http://www.doubleencore.com/2013/09/developers-guide-to-the-ios-7-status-bar/ [1] http://www.icenium.com/blog/icenium-team-blog/2013/11/07/everything-hybrid-web-apps-need-to-know-about-the-status-bar-in-ios7 > > > > 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 > >
