In my application I am using a subclass of the UINavigation controller and UITabBarController to override some of the orientation functions.
Is it App Store safe to use a subclass, or could my app be rejected?
You can subclass these. Generally you wouldn't but if you want to you can and you won't have any problems.
In fact in iOS 6 which introduced a new logic for autorotation, Apple says in their documentation for UINavigationController precisely this. It's also mentionned for UITabBarController.
This class is generally used as-is but may be subclassed in iOS 6 and
later
You will not be rejected just for subclassing these two classes. I've done it myself in several apps.
Related
Is there a way to add or remove these components programatically?
No, not exactly. You need to set up all the possible user interface orientations your app's view controllers MIGHT support in info.plist. Once you've done that there are view controller methods the system calls to see what orientations an individual view controller supports. (See supportedInterfaceOrientations in the docs.)
As of iOS 8 we're not supposed to use rotation methods any more, so check the docs carefully. It looks to me like supportedInterfaceOrientations is still supported, but the willRotate..., willAnimateRotation..., didRotateFromInterfaceOrientation, etc, are deprecated.
I suggest reading about user interface rotation in the UIViewController class reference (in Xcode or in Apple's online documentation on the web.)
I am creating an application using Apple's new swift language.
Application is universal, so that I created XIB with '~' operator. Like "MyView~iphone.xib" and MyView~ipad.xib" . But sometimes, even when my application is running in iPad it loads iPhone nib.
I have tried lots of option but still facing the same issue.
People may think this never happens but I am facing this issue.
It would be better to see the code but i guess your solution is like this
BOOL isPad = (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad);
UIViewController *myViewController = [[UIViewController alloc] initWithNibName:isPad?#"MyView~ipad.xib":#"MyView~iphone.xib" bundle:nil];
Hey try using size classes in Interface Builder and you won't need different xibs for both iPhone and iPad. You can take advantage of size classes and setting constraints in storyboard for each of the size class. I recommend you watching WWDC 2014: Session 216.
I have had an issue like this objective C but that was way back in iOS 6, I don't know whether this could fix your issue but
Try renaming the files as
MyView~iphone.xib for iPhone
MyView.xib for iPad
Instead of
MyView~iphone.xib
MyView~ipad.xib
I would advise you to use Size classes since it is future proof.
I'm creating application for iOS7.0 and higher versions. But due this i must use iOS8 SDK. But since iOS8 UISplitViewController delegate method "shouldHideViewController" is deprecated. So basically APPLE removed any known to me method to hide masterVC for iOS7 users..
Please tell me is there any way to solve this problem?
You can set the preferredPrimaryColumnWidthFraction
property on the detail VC.
self.splitViewController.preferredPrimaryColumnWidthFraction = 0;
I have a sample program which I was interested in emulating in building my main application, but that sample program does something which I think is probably not permitted. I found some forum posts which suggest Apple will reject an app from the app store if it does this:
#interface MainTabBarController : UITabBarController <XXCustomAccessoryDelegate,UIAccelerometerDelegate> {
I'm relatively new to iOS development, and I'm not 100% certain about this. I have googled a bit and found some information suggesting "not to do this", but not a firm "you should not do this".
The UI tab bar controller class that this person has subclassed has IBOutlet and IBAction connection points, and these are a central part of the application, but it does not override the painting code. Do I need to rewrite or adapt the code if I want to reuse part of it, before Apple will permit it in the App Store? Or is it simply overriding to access the view and modify the painting code that Apple does not permit?
The docs have changed between ios5 and ios6.
ios5: " This class is not intended for subclassing."
ios6: "This class is generally used as-is but may be subclassed in iOS 6 and later."
So I'm creating and showing a custom window in my iOS app because I'm writing a dynamic alert view that also functions like a growl/toast alert. It works AWESOMELY in ios6 (Hopefully I can open source this baby and you can all check it out)
But anyway, when I run this in ios5, the window that my alerts exist on doesn't seem to rotate with the device/simulator. No matter what, my custom window stays in portrait mode.
The UIWindow is just a UIView subclass, so there's no nice 'shouldRotate' delegate method.
I'm kinda stumped on why this is happening in ios5 but not 6. Any help would be GREATLY appreciated ^_^
My window has a rootviewcontroller, which I completely forgot about. I just needed to implement
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation{
return YES;
}
To get it to work.
:-D
It's usually not recommended two use multiple instances of UIWindow in one iOS app. The only valid reason to do so is to support external screens. You should use a UIView instead, ideally managed by a UIViewController.
I assume, (since you didn't provide any code, I can only assume) the reason why your window doesn't 'rotate' is, that it's simply not getting any notifications about device rotation. Only the keyWindow receives them by default.
I would highly recommend to redesign your app to use a properly managed UIView instead. If you desperately don't want that for some reason, you would have to register your instance of UIWindow to receive the UIDeviceOrientationDidChangeNotification and then (in the handler) evaluate what the new orientation is and change the window's frame accordingly (plus maybe other things that need to be done in response to the orientation change)