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?

[isaac.sunkes]

By all means I hope Adobe puts a lot of hard work into solving the issues you are having.

[Apocalyptic0n3]

As a quick update, the latest AIR SDK release (AIR 3.9.0.1210) does not fix this bug.

[mikatalk]

As a quick update, the latest AIR SDK beta release (AIR 4.0) does not fix this bug.

[Apocalyptic0n3]

The latest 4.0 beta release (available Nov 26, 2013. Don't have the full version number handy) does not fix this issue

[phonefusionryan]

Honestly I was hoping it wouldn't fix it and many of the other current bugs I've found. Because if it did, that would make me lose complete faith in their bug base, as all the bugs I'm waiting for to be fixed have recieved no updates from adobe whatsoever.

[mikatalk]

It seems that fix might possible with use of ANE see Anton Azarov comments on https://bugbase.adobe.com/index.cfm?event=bug&id=3633422 I will keep the thread posted if any progress.

[esDotDev]

Speaking of ANE's, has anyone tried the Distriqt ANE? Looks like it will allow you to control this:

http://distriqt.com/native-extensions#application

[mikatalk]

open source solutions would be prefered.

[esDotDev]

For some, not for all. I'm running a business, and am happy to spend a small amount of $$$ for a robust solution, rather than a potentially buggy/unmaintained solution for free.

Anyways, just thought I would throw it out there, so maybe someone can test and report back.

[Apocalyptic0n3]

Very true. You get what you pay for, right? Anyway, Distriqt is one of the top AIR developers out there. Their ANEs are, for the most part, the very best available. They're expensive, sure, but they fill in most of the areas that AIR falls flat on. Worth the money in my opinion.

[Apocalyptic0n3]

The Apache team has added support for this in the latest nightlies of 4.12. You can now set osStatusBarHeight on Application.

https://issues.apache.org/jira/browse/FLEX-33860

@media (application-dpi: 160) AND (os-platform:"IOS") AND (min-os-version: 7)

{

    Application {

         osStatusBarHeight: 20;

    }

}

[isaac.sunkes]

Well... guess it turns out its a Flex thing, not an Adobe bug to be fixed in the AIR SDK.

[Apocalyptic0n3]

Still not sure about that. There are still issues with going fullscreen and using ANEs that cause issues. I haven't tested this yet to see if it fixes those, but I'm not sure Flex was the source of those issues.    

[mikatalk]

Turns out to be an iOS7 issue, the bug ticket was withdrawn:

https://bugbase.adobe.com/index.cfm?event=bug&id=3633422

You need to account for the status bar in your own code - native iOS developers are running into the same problem - only native iOS apps using opaque UINavigationController or UITabBarControllersee are unaffected. See this from Apple:

https://developer.apple.com/library/ios/qa/qa1797/_index.html

If you are not able to accomodate the design and need to recreate the status bar from Starling, here is how I'm doing it (for now):

-app.xml:

<systemChrome>standard</systemChrome>

  <transparent>false</transparent>

  <maximizable>false</maximizable>

  <minimizable>false</minimizable>

  <resizable>true</resizable>

  <fullScreen>false</fullScreen>

  <autoOrients>true</autoOrients>

  <aspectRatio>landscape</aspectRatio>

  <renderMode>direct</renderMode>

  <visible>true</visible>

  <softKeyboardBehavior>none</softKeyboardBehavior>

in your Starling Root:

private function resizeStage():void

{

                              var viewPortRectangle:Rectangle = new Rectangle();

                              viewPortRectangle.width = stage.stageWidth;

                              viewPortRectangle.height = stage.stageHeight;

                              var iOSVer:String = Capabilities.os.substr(10,1);

                             switch(iOSVer){

    case "7":

      // iOS7

      viewPortRectangle.height -= ( 20* AppConstants.scaleAssetsRatio );

      viewPortRectangle.y = ( 20* AppConstants.scaleAssetsRatio );

      break;

    default:

      // others...

                              }

                              Starling.current.viewPort = viewPortRectangle;

                              Starling.current.stage.stageWidth = stage.stageWidth;

                              Starling.current.stage.stageHeight = stage.stageHeight;

                              AppConstants.scaleToScreen = Math.min( Starling.current.stage.stageWidth / AppConstants.SAFE_WIDTH, Starling.current.stage.stageHeight / AppConstants.SAFE_HEIGHT );

  AppConstants.remainderWidth = ( stage.stageWidth / AppConstants.scaleToScreen ) - AppConstants.SAFE_WIDTH;

  AppConstants.remainderHeight = ( stage.stageHeight / AppConstants.scaleToScreen ) - AppConstants.SAFE_HEIGHT;

}

Later, if you need to do screen captures, use stagewebview, native text or native stage, you will need to take this new offset into account by adding to the y properties:

Starling.current.viewPort.y / AppConstants.scaleToScreen

Finally set the swif background color to whatever color you need your status bar to be:

[SWF(backgroundColor="#000000")]

Voila, now when user switch app to vertical from camera roll, the app is not stuck to vertical with half the screen cut off.

It's not a perfect solution but in my case it works. Hope it helps others running into the same problem.

[jadams602]

Well the unfortunate issue is that the bug and various discussions like this one, mix different propblems for people who want the status bar accounted for, but also users that have been doing fullscreen apps, and now see the status bar show up only after some UI interaction like CameraRoll is used.

It is unfortunate that Adobe chose to withdrawl that bug without properly addressing and breaking down all the specific cases.

yes there are workarounds for some people, depending upon how they want or dont want the status bar.

The following specific case still seems unresolved:

Where you launch a Stage3D AIR app in fullscreen (successfully not showing any status bar at all on startup).

Then later use CameraRoll (causing not only nasty Context3D lost context) but then the status bar text shows up where it didn't before.

Yes, we have a 'workaround' (NOT a fix) for this by manually resetting fullscreen mode again after CameraRoll use.

(Causing yet a second Context3D lost context). (none of this happens on previous iOS versions, no lost context included)

Manually accounting for a status bar area is not a fix for fullscreen apps. It actually undoes what Apple's true intentions were for this new look. They want your app to use the fullscreen and show its contents behind the status bar if present. Shortening the stage viewPort is a workaround but not even the desired result Apple was intending with this feature change.

When you see comments like "You need to account for the status bar in your own code".

Thats fine, but in this particular case, we started out with no visible status bar, so the "You" in this statement still seems to be Adobe's native code for CameraRoll. 

I guess now we are forced to try and see if there is a way to use some existing ANE code for Image selection for iOS and see if there is a way to possibly keep the Stage3D view from changing size (avoiding a lost context).  If this can be done with an ANE then maybe this will convince Adobe to try and fix this particular use case in their CameraRoll implementation.

Otherwise if this can't be done, then we chalk it up to an unpleasant new sideeffect for iOS7 and Stage3D...

[esDotDev]

Agreed, it's annoying that such a simple bug has been confused and totally missed through all the noise in this thread 😕

I've started a new ticket, describing specifically what is still broken, hopefully this is clear enough for Adobe:

https://bugbase.adobe.com/index.cfm?event=bug&id=3680222

Please vote

[Nimisha1]

Hi esDotDev,

This bug happens in the native iOS app as well so is not an AIR bug, we have logged an Apple radar bug for this same issue.

Thanks,

Nimisha

[jadams602]

No its not just a Flex thing, Stage3D based AIR apps need solutions to this issue too.

[sharkhack]

https://github.com/sharkhack/IOSStatusBarAne is my solution.

[Santanu_Karar]

The bug seems persistent with AIR 4.0 as well. Though I'm not sure if Adobe could do something with API like CameraRoll etc. (beside waiting for Apple)