Hide Statusbar

Is there a supported (or non-hacky) way to hide the status bar? Making the time, battery and carrier status, etc. disappear is very common in iOS apps. Currently it seems possible using method swizzling, but that is definitely unsupported.

This is what I am doing now:

[code]Sub HideStatusBar(mView as iOSView)
declare function object_getClass lib “/usr/lib/libobjc.A.dylib” (cls As Ptr) As Ptr
declare function NSSelectorFromString lib FoundationLib (aSelectorName as CFStringRef) as Ptr
declare function class_addMethod lib “/usr/lib/libobjc.A.dylib” (cls as Ptr, name as Ptr, imp as Ptr, types as CString) as Boolean

dim viewControllerClass As Ptr = object_getClass(mView.ViewControllerHandle)
if not class_addMethod(viewControllerClass, NSSelectorFromString(“prefersStatusBarHidden”), _
AddressOf impl_prefersStatusBarHidden, “b@:”) then break
End Sub
[/code]

Private Shared Function impl_prefersStatusBarHidden(pid as ptr, sel as ptr) As Boolean Return True End Function

Is there another way?

Thank you for sharing that method, Jason.

From what I see, there is a statusBarHidden boolean property at https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplication_Class/index.html#//apple_ref/c/tdef/UIStatusBarStyle Maybe it is more straightforward ?

In the iOS Human Interface Guidelines, at https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/Bars.html they have an interesting discussion about the status bar appearance.

They warn about hiding it because it can prevent the user to check connectivity or see the time, but say it is OK for application that need full screen.

I just tried to implement your method in a button with HideStatusBar(self), it crashes :frowning: I must be missing something.

Hi Michel, unfortunately setting this property no longer works in iOS 7+. I tried that already :wink: And yes I understand that there can be inconveniences associated with hiding the status bar, but I need it for a full screen portion of an app.

I added them to the App class, I don’t think it will work if it is added to a view. Also make sure you note that the impl_prefersStatusBarHidden function is a Shared method. It must be a shared method for it to work.

this works in objC (iOS 8.1)

  • (BOOL)prefersStatusBarHidden { return YES; }

and this works in SWIFT

override func prefersStatusBarHidden() -> Bool { return true }

and you can use this to make light or dark status bars

override func preferredStatusBarStyle() -> UIStatusBarStyle { return UIStatusBarStyle.LightContent }

Leave it up to Jason to do the rest… :slight_smile:

Oh and they have to be in the VIEWCONTROLLER… not subviews

OK. So added to the app class. But then what do you pass to it ? Care to give an example ?

[quote=155901:@Dave S]this works in objC (iOS 8.1)

  • (BOOL)prefersStatusBarHidden { return YES; }

and this works in SWIFT

override func prefersStatusBarHidden() -> Bool { return true }

and you can use this to make light or dark status bars

override func preferredStatusBarStyle() -> UIStatusBarStyle { return UIStatusBarStyle.LightContent }

Leave it up to Jason to do the rest… :slight_smile:

Oh and they have to be in the VIEWCONTROLLER… not subviews[/quote]
Thanks, Dave. The ObjC code that you posted is exactly what the Xojo code I posted does. Unfortunately overriding a function in this way is frowned upon by Xojo (at least on Xojo desktop). I’m just trying to figure out if there is a way it is supposed to be done or if method swizzling is the only way.

OK. Passed an instance of the start view, it works :slight_smile:

If you add those methods to the app class then you just need to call

app.HideStatusBar(self)

in the open even of your view.
Also I just noticed that FoundationLib is a constant included in the code. If you don’t have it defined it should be defined as

const FoundationLib = "Foundation.framework"

Edit: glad it works for you now.

[quote=155909:@Jason King]If you add those methods to the app class then you just need to call

app.HideStatusBar(self)

in the open even of your view.
Also I just noticed that FoundationLib is a constant included in the code. If you don’t have it defined it should be defined as

const FoundationLib = "Foundation.framework"

Edit: glad it works for you now.[/quote]

I noticed you had both FoundationLib and WrFoundationLib that seem to be synonymous with the Foundation constant I have in the wrapper, so I duplicated it, and now it works fine.

One issue, though, is that if you hide the statusbar in a view and pushto another one, the status bar remains invisible. It would seem necessary to have a ShowStatusBar method to reinstate it.

Yes that is the problem with the method swizzling. Since Xojo seems to use the same superclass for all of the view controllers, method swizzling like this edits the common superclass and the StatusBar is hidden for all views. If you want it customizable then you could set a boolean property and change that property depending on whether you want it to be visible or not, then you just have to return that property instead of returning true in the impl_prefersStatusBarHidden function.

I tried to return False in impl_prefersStatusBarHidden, it does not reinstate the statusbar. There must be something else.

How about calling

[quote]setNeedsStatusBarAppearanceUpdate
Indicates to the system that the view controller status bar attributes have changed.[/quote] after you changed the properties?

Anybody got a working example of this being able to turn it off/on that they would be willing to share?

Sorry for the bump but this conversation has valuable information in it. We can hide the status bar - it would be nice if we could complete the story by figuring out how to show it again.

As an example, in my initial View, I’d like the status bar to be hidden. My initial View is mostly one of a number of full-screen photos and it has no navigation bar.

Next, the user can touch a button to pushto another View. This View does have a navigation bar. In this View, I’d like the status bar to be visible again.

Finally, of course, I’d like the status bar to become invisible again, when the user goes back to the original View.

[quote=156103:@Ulrich Bogun]How about calling
[quote="setNeedsStatusBarAppearanceUpdate
Indicates to the system that the view controller status bar attributes have changed.][/quote]
after you changed the properties?[/quote]

My understanding is that if we’re modifying the status bar visibility within the same View, then we do need to do this. But if we are moving to a new View, iOS supposedly checks the value of prefersStatusBarHidden and cleans things up itself.

If anyone has figured out how to programmatically show the status bar again, I’d love to hear from you. Like @Michel Bujardet and presumably others, I have tried returning false in impl_prefersStatusBarHidden with no success.

in the iOS world (not that of Xojo) there are two things… a ViewController and a View
the statusbar style is controlled by the “preferredStatusBarStyle” event of the ViewController
and its visiblity by “prefersStatusBarHidden()”

So if what Xojo calls a VIEW is really the equivalent of a ViewController, then I’d suspect there are declares that can handle this.
Even if Xojo flips UIViews inside the same ViewController it can be done , just a bit trickier

One needs to be careful saying “iOS does or does not do this or that” when it might be “Xojo for iOS does this or that”… especially since there are so many things that iOS can do, that “iOS for Xojo” cannot

[quote=365162:@Dave S]in the iOS world (not that of Xojo) there are two things… a ViewController and a View
the statusbar style is controlled by the “preferredStatusBarStyle” event of the ViewController
and its visiblity by “prefersStatusBarHidden()”

So if what Xojo calls a VIEW is really the equivalent of a ViewController, then I’d suspect there are declares that can handle this.
Even if Xojo flips UIViews inside the same ViewController it can be done , just a bit trickier

One needs to be careful saying “iOS does or does not do this or that” when it might be “Xojo for iOS does this or that”… especially since there are so many things that iOS can do, that “iOS for Xojo” cannot[/quote]
Coming from many years of iOS development in Objective-C (and some in Swift), I can say with assurance that I totally agree.

This particular issue is odd because hiding the statusbar does work fine. The issue is that I can’t understand where it breaks down and doesn’t show it again.

Can somebody implement the example code here
link text

Steve… perhaps you didn’t read my post above… What I described is exactly what the article is talking about…
The problem is that article is based on what iOS can do, not what “Xojo for iOS” can do