Since iOS 6 release, there are some iAd properties and methods that are deprecated like :
currentContentSizeIdentifier
requiredContentSizeIdentifiers
ADBannerContentSizeIdentifierPortrait
ADBannerContentSizeIdentifierLandscape
So what's the best way to implement iAd now on both orientation ? Should we now resize the banner view frame manually ?
I have my application only support Landscape mode(should work for Portrait mode also), and have iAd showing up on the top of the application. And to make this work with ios6 I had to do this:
In Monotouch
storesAdBannerView = new ADBannerView();
storesAdBannerView.AutoresizingMask = UIViewAutoresizing.FlexibleWidth;
For objc (which I dont use), I think it might be
[storesAdBannerView setAutoresizingMask:UIViewAutoresizingFlexibleWidth]
It seems that landscape ads are somewhat phased out.
See: http://www.iphonedevsdk.com/forum/iphone-sdk-development/108118-landscape-iad-banners-in-ios-6-edit-landscape-phased-out-completely.html
It need further confirmation, as I could not find any Apple document regarding that change.
I sAw 2 workaround there : http://www.touch-code-magazine.com/iad-code-is-broken-in-ios6/ Tested the first solution:
easy temporary solution – you can quickly get your app to compile again by using a cheap cheat, add explicitly #import to the files where you are accessing currentContentSizeIdentifier and the size name constants. That should get you going until you alter your app to use the new auto-layout features.
It works ok on xcode 4.5 (banner test ok).
Related
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 always have an app requirement to support both iOS6 and iOS7. But because of iOS6 support, I can't use some feature of iOS7.
For example, I have to do UIView bounce animation, in iOS6 I have to do it with CAKeyframeAnimation or UIView animation, but iOS7 has UIKit dynamics which provide me UIDynamicAnimator class and I can do with it.
So should I always use older methods like CAKeyframeAnimation or UIView animation because it supports both iOS6 and iOS7 or write both by checking iOS version?
Ruthlessly strip things from the iOS 6 version that require ios7 features to work, particularly if they are cosmetic things like bouncing animations.
When challenged about this, tell your client they can spend 80% of their dev budget supporting an ever-shrinking pool of unconcerned users, or they can get real. API compatibility is only one headache between 6 and 7. The layout issues are far harder. Any new app being written today needs a really, really good reason to support 6, particularly with 8 just round the corner.
I believe the best way is to check iOS version and implement both variants of code.
Yes, maybe, it's quite a lot of work but in majority of cases newest features provided in new iOS releases are more flexible and simple to understand/integrate. In most cases they are also more plain in support. They are supported by Apple with more care and there is a small possibility of their deprecation.
You can use Foundation runtime variable NSFoundationVersionNumber and NSFoundationVersionNumber_iOS_6_1 macros to divide your code:
if (floor(NSFoundationVersionNumber) > NSFoundationVersionNumber_iOS_6_1) {
// write iOS 7+ code here
}
else {
// write iOS 6.1- code here
}
Note, sometimes some recent released API can be quite raw. In such cases you should take a decision individually whether you really need the migration immediately.
You can use class API to check for availability of classes.
if ([UIPrintInteractionController class]) {
// Create an instance of the class and use it.
}
else {
// The print interaction controller is not available.
}
For more information see link below Advanced App Tricks
I've been working a little with the new UI options in iOS 7, and the automaticallyAdjustsScrollViewInsets property in UIViewController is really freaking me out. the thing is, either you don't set it, but then you will have to position your scroll views differently in iOS 7 and other iOS versions. the alternative is to set it to NO only for iOS 7 and use the same positioning. I don't understand why apple implemented this property at all, in my opinion, good practice would be always having it to NO (not having such a property at all), just like it was before. I understand that it is easier to use if you are lazy, but this seems like a really bad programming practice in my opinion. am I missing out on something or do you agree?
I don't see any problem. iOS 6 SDK does not contain this property. You just should use following code:
if([self respondsToSelector:#selector(setAutomaticallyAdjustsScrollViewInsets:)])
{
self.automaticallyAdjustsScrollViewInsets = NO;
}
[I know this has been done to death, and I'd ask follow up questions on an existing question were it not for not having enough stackoverflow points to make one:(]
I'm after an App Store valid way of forcing an existing UI to re-orientate without having to destroy the main ViewController or View. We work in fullscreen mode, so I'm assuming I can't use any of the toolbar approaches normally quoted. Finally I'm only interested in iOS5.
For iOS6 I have a solution based on the answers in How to change the device orientation programmatically in iOS 6. I used the solution which includes ForcePortrait, with the variation that I changed it so I can supply the required orientation as a parameter.
For iOS5 I have experimented with the suggestion of:
[UIDevice currentDevice] performSelector:NSSelectorFromString(#"setOrientation:") withObject:(id)UIInterfaceOrientationPortrait];
from How to set device (UI) orientation programmatically?. This works well but I'm worried that it would be rejected by App Store (complete no no for us).
Has anyone used this on something that has App Store approval and/or got a better suggestion?
Check this out: Force Rotate UIViewController.
Maybe it will work. This is however very hackish.
[Found a solution, at any rate. Not sure if it the best.]
Got the temporary UIViewController approach to work by adding shouldAutorotateToInterfaceOrientation. The meaning of this is overloaded by iOS5 to discover not only should it autoRotate but also should it start in a particular orientation to start with - I guess that is why it is replaced by several methods at iOS6.. Thus we return true in orientations that are OK.
Perhaps should have realised that before.
Not quite as neat as the setOrientation hack. Key glitch we've noticed is that when you then rotate the device around to the proper orientation you still get a rotation animation. This does not occur on iOS6. Oh well, you win some, you lose some.
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)