i0S7 StatusBar Overlays stage, Adobe Air 3.9 Beta Bug? Is there a Workarround

[simonschweizer]

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?

[mikatalk]

@Apocalyptic0n3 Almost 2 months indeed https://bugbase.adobe.com/index.cfm?event=bug&id=3633422

Status

State Open

Status ToTrack

Reason

Importance

Priority 2-Medium

Frequency All users will encounter

Failure Type Cosmetic Issue

Product Area OS Interation

[Apocalyptic0n3]

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.

[isaac.sunkes]

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.

[Apocalyptic0n3]

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.

[mikatalk]

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.

[phonefusionryan]

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.

[5898845]

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!

[phonefusionryan]

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.

[5898845]

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.

[phonefusionryan]

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...

[xTLS]

So now it's April and I'm still having this issue with AIR 4.0. Any news?

[phonefusionryan]

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.

[User_Unknow]

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

[phonefusionryan]

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?

[isaac.sunkes]

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.

[Apocalyptic0n3]

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.

[JonathanH_UK]

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.

[mikatalk]

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...

[isaac.sunkes]

Please see this blog post I wrote, good luck coding.

http://www.ravenglass.com/blog/index.cfm/2013/11/11/How-to-fix-iOS7-and-Flex-Mobile-with-Adobe-AIR-3...

[mikatalk]

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...

[isaac.sunkes]

Sounds like you need to write some code.

[Apocalyptic0n3]

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.

[mikatalk]

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.

[isaac.sunkes]

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.

[Apocalyptic0n3]

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.