>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?
As Om said, many non-native iOS frameworks are dealing with this issue. Even iOS native apps developers are "annoyed" by this change. Alex, After evaluating the new proposal again (changing iOS to more W3C compliant css selectors), I realize that I will not be able to do it, although I agree on the principle. So I will keep it as "os-version", and just implement the version-computation for Android (using build.prop file) (and of course fix the failed mustella tests). It's not that bad, and it will certainly be useful to handle iOS 7 / Android skins. The main and simple reason for that is am physically exhausted. It's just too much work for me. Moreover, I already committed to many other Flex tasks and I have to prioritize things. I Hope you understand. I will get back to it later in a few months. Maurice -----Message d'origine----- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : lundi 2 décembre 2013 20:44 À : dev@flex.apache.org Objet : Re: IOS7 status bar management ( FLEX-33860) 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 > >
