Copy link to clipboard
Copied
Hi
I am using Adobe air 3.9 Beta. It seems that iOS7 give you the the possibility to style the Statusbar. But if you open an adobe air application the statusbar overlays the stage by default. It creates problems with my tabs.
I tested the app with an iPod and IPhone, both with iOs7 Both have the Issues. If I compile the app with Adobe air 3.8 the Statusbar will be displayed correct.
But I can't use air 3.8 because I need the new Icons 120x120 76x76 etc.
Other people have the same issue. See screenshots https://github.com/mutualmobile/MMDrawerController/issues/51
I think the solution is in the info.plist. There is an option for the info.plist UIViewControllerBasedStatusBarAppearance. We need this paramter to activate or deactivate the Statusbar overlay.
any Ideas?
Copy link to clipboard
Copied
@Apocalyptic0n3 Almost 2 months indeed https://bugbase.adobe.com/index.cfm?event=bug&id=3633422
State Open
Status ToTrack
Reason
Frequency All users will encounter
Failure Type Cosmetic Issue
Product Area OS Interation
Copy link to clipboard
Copied
As a further note, iOS 7 adoption rate is reportedly at 73%, not 90%. iOS6 didn't hit 97% until about a month before iOS 7 was released actually.
Copy link to clipboard
Copied
iOS and Android are indeed fragmented to have different devices, OS version, and screen resolutions. You can not support them all without a little bit of coding workarounds in your application. Just the life of a flex mobile developer.
Copy link to clipboard
Copied
You are hilariously missing the point. This is not something "to work around". It is a serious bug and even the workarounds have their issues (going fullscreen and going back to normal will fix it, for instance, so your padding trick will not work after that). Adobe needs to fix this bug.
Copy link to clipboard
Copied
Flash Built its success over cross browser stability/reliability and this will naturally apply to devices and AIR.
Also going fullscreen back and forth may fix it for certain cases, but for GPU accelerated (starling for example), this provoque a loss of context and teh experience get really choppy.
Adobe needs either to fix the bug or provide clear documentation on how to handle the issue.
Copy link to clipboard
Copied
For all those looking for help in a non-fullscreen app, there are more steps you need than simply ...
s|ActionBar
{
paddingTop:45;
}
this solution assumes your using Flex and only accounts for iOS7, if you're building for Android as well you wouldn't want to do this.
You need to only move your main container down (assuming you have one, if not, make one) if you detect it's iOS7.
Here's how I did it:
var iOSVer:String = Capabilities.os.substr(10,1);
switch(iOSVer){
case "7":
//iOS7
break;
default:
//others
}
For Retina Displays you move it down 40, for non-retina you move it down 20.
This part will ONLY cover the display list portion, if you're using things like StageWebView you will also need to do conditionals to determine it's size as well.
Copy link to clipboard
Copied
I don't know if you have even tested your "workaround" but this does NOT work for pure AS or Stage3D projects like for instance Starling.
Once you move your entire app down (i.e. the Starling instance) all StageTextTextInputs are broken since once focussed the TextInput doesn't sit at the same y position as the underlying StageTextTextInput.
Your "solution" might "work" for Flex, but as soon as you need rotation or something for a pure AS or Stage3D project it ain't gonna work.
So stop proposing it as a general solution and tell other's they are stupid and need to work this out for themselves whereas this clearly is an issue that needs to be addressed by Adobe!
Thank you!
Copy link to clipboard
Copied
Hope that wasn't geared towards me. I completely agree with you that this is a bug that needs to be fixed. Never said it wasn't. What I posted was what I did to fix my Display List non-fullscreen app. I never said it was a general solution I just posted some help. I'm sure other's in my same scenario have benefited.
Copy link to clipboard
Copied
Sorry I accidentally replied to the wrong post. I meant to reply to isaac.sunkes.
However, your solution will suffer from the StageTextTextInput issue as well if I'm not mistaken. At least in a Starling app this moving the apps container for a non-fullscreen app down by the height of the status bar will break the textinput.
Copy link to clipboard
Copied
aha... speak of the devil... I was literally about to attempt to implement a StageText into my app (as I didn't have any) but you are 100% correct. I can't because of the alignment issue...
Copy link to clipboard
Copied
So now it's April and I'm still having this issue with AIR 4.0. Any news?
Copy link to clipboard
Copied
Sadly the issue isn't really with AIR, it's with iOS in general. All native apps are having the same issue
Like me and the other above, I've done the work around to detect if it's iOS7 and then push the app 20px down. Yeah it sucks.
Copy link to clipboard
Copied
This can be fixed using native extension. All you need it's reduce UIApplication sharedApplication rectangle. But AIR can't fire EVENT.Resize after that so fixing mostly unusable
Copy link to clipboard
Copied
I am here only to give some confirmation because what I was looking for was spread across many posts and I wanted a solid answer.
My settings:
<fullScreen>false</fullScreen>
<renderMode>GPU</renderMode>
on iOS 6 with AIR 3.8 (there are no problems) - Rendered non-fullscreen with status bar seperate from the app at the top.
on iOS 7 with AIR 3.8 (there are no problems) - Rendered non-fullscreen with status bar seperate from the app at the top.
on iOS 7 with AIR 3.9 the app is being rendered fullscreen and the status bar is being overlayed on top.
This post was started in September 17th, it's now November 7th, 2013, AIR 3.9 is no longer beta.
This problem 100% still exists.
every solution/comment mentioned on this thread seems to help only "fullscreen" apps.... any workarounds for the non-fullscreen apps?
Copy link to clipboard
Copied
Call me crazy, but the status bar overlaying the header is how it is supposed to work in iOS 7 and is part of the new iOS developer guidlines. Have any of you even used any other apps optimized for iOS 7 on an iPhone. Look to them as an example, they all have the status bar overlaying the header (facebook, instagram, foursquare, etc).
To me, that means AIR 3.9 fixed the issue.
Copy link to clipboard
Copied
No, that is a feature of iOS 7, available to developers (and, in general, being used by most devs). That is not actually the default way it is handled (or at least it wasn't the last time I looked at Xcode). Additionally, if this is how Adobe means for it to work, that means they are requiring us to do the grunt work of figuring out if the user is running Android or iOS <7 and how to modify it. Generally, such a situation would be handled by leaving the previous method as the default and allowing us to manually change the color via the app.xml (Adobe consistently states not to use platform or OS version to determine interface).
Additionally, as has been stated, going fullscreen completely screws it up. If you go fullscreen and then return to non-fullscreen, the issue resolves itself and the app accounts for the height of the status bar. That alone designates at least part of this issue as a bug.
Copy link to clipboard
Copied
I'll bet I'm not the only one who felt this information was a little hard to dig up to get a concrete solution... So let me try and clarify for others like me...
If you're building a non-fullscreen app for iOS7, and have buttons at the top of your UI, your screwed. The word "iPad", the time, the battery life, are all going to cover up your buttons or parts of them. You will have to manually detect that your users are using iOS7 and move your entire app down.
Copy link to clipboard
Copied
By screwed i think jonathan means getting shity comments/ratings on the app store like that one:
Bugs
by B. I.
It needs big fixes it doesn't let u rotate the screen so I only have half a screen and I know it's the app because, my rotation is unlocked needs bug fixing!
rated 1 star...
Copy link to clipboard
Copied
Please see this blog post I wrote, good luck coding.
Copy link to clipboard
Copied
This is not a complete workaround:
From your article: "Keep in mind this will only address this issue for iOS7, so if you plan on supporting other platforms you will need to put in some conditional logic"
Also I don't use flex but pure action script instead...
Copy link to clipboard
Copied
Sounds like you need to write some code.
Copy link to clipboard
Copied
Please read the thread. Again. This method breaks if your app goes full screen. I have a VOD app I am currently trying to finalize. It is normally not in fullscreen. When I go to fullscreen watching a video and then exit again, the bug where the padding is gone disappears (most of the time, sometimes it will reappear). So while this will work if your app never changes screen display state, you're screwed otherwise.
This is not something we can work around with code. It is a genuine bug. Your constant comments stating otherwise or giving workarounds that have been suggested for WEEKS now is doing nothing but hurting this process and the chances of Adobe fixing this.
Please just stop replying to this thread. You are doing more harm than good.
Copy link to clipboard
Copied
I second @Apocalyptic0n3!
Please Isaac unless you have a serious bug fix for all cases (camera roll, orientation change and fullscreen), stay away from the thread.
It would be much apreciatted.
Copy link to clipboard
Copied
Wow whats with the negativity? Not a problem guys, I will bow out and leave you two to hash out the details. Just trying to help.
Copy link to clipboard
Copied
The problem is that you are consistently not helping. The workaround you suggested is not a comprehensive workaround and will break in various scenarios (not just the one I mentioned. There are several other times it will break). And, to boot, has been suggested several times before. You have claimed that this is not a bug, which could potentially harm the chances of it getting fixed. And you have stated numerous times that this should be the developer's job to fix, when it is not possible for us to completely fix this. Luckily this is not on the actual ticket where real harm to getting this fixed could have potentially happened.