I want to make my app universal with one storyboard for all devices. I have now a view below my table view which should contain the iAd banner, unless the user has made the in app purchase to remove the ads. So now I want to place the iAd banner within this view, but I don't know how big this view must be? Very confused about all the information in the internet, since a lot of stuff has been deprecated with the universal storyboards...
Apple's own iAD Programming Guide does not cover the Adaptive Layout with Size Classes the last I checked. So, you may want to try and turn off Size Classes for your StoryBoard and use 2 StoryBoards. But, this will make defining Constraints more important to adjust for various device sizes.
iAd Programming Guide (check the Banner View Concepts section)
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/iAd_Guide/Introduction/Introduction.html
Related
I'm implementing a lock-screen page in iOS.
But the design for iPhone 6 requires text on top is pretty large, which causes the bottom in the page is hidden in devices equipped with small resolution screen like iPhone 4.
Do I have to define multiple xib for each device in this situation?
Or make some views smaller programmatically?
Or make some margins smaller programmatically?
Are there any references for this? I'm new to auto-layout.
I would suggest you to use autolayouts. From my understanding your app can be implemented with stack views.
So start with this document,
http://www.appcoda.com/introduction-auto-layout/
and
http://code.tutsplus.com/tutorials/ios-from-scratch-with-swift-auto-layout-basics--cms-25520
Then checkout the apple documentation for further understanding
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/
If the constraints are too confusing, try stack views
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/AutoLayoutWithoutConstraints.html#//apple_ref/doc/uid/TP40010853-CH8-SW1
Creating multiple xibs is not a solution. Make use of autolayouts :)
I want to integrate iAd in my app. My app is tab based application. Most of my views have TableView in it. What can be the best place to display banner, should I display bottom of the TableView or top of the TableView?
Bottom of the tableview is a good place to place the ads, as there are more chances the use will click on the ads when he/she wants to tap on the tabs. Check Other apps also. The app "FindHrr" I have developed has a similar design where we have placed the app below the tableview.
When you open a map with MapKit, it displays a small "Legal" link near the bottom which you can access for a lot of legal stuff. According to the guidelines, this link must not be interfered with to prevent it from functioning. I don't even know if it can be moved.
At the same time, the recommended placement of ads from iAd is at the bottom of the screen. Makes sense because that's where the fingers are. But placing the ad there will overlap the link and prevent it from being accessed.
I was wondering if anyone has set up iAds so that instead of overlaying the main screen, it reduces the size of the main screen, and positions itself "next" to it?
I'm thinking if I do this with other controls at the bottom, then would that inconvenience users who are trying to access the controls, only to have an ad slip underneath?
Would it be better to go against recommendation and put the ad at the top?
I suggest the simplest solution possible: set the canDisplayBannerAds property of your view controller to true; this should handle pushing display ads up from the bottom and resizing the existing views.
I've read around that Apple is hinting to developers at a larger-screen iPhone by pushing developers to use Storyboard and auto-layout. I understand why auto-layout would be useful, to organise items according to screen size, but what do Storyboards have to do with anything?
I may be missing an obvious advantage (in relation to larger screens), so any help would be much appreciated. :)
A. You say that there are some notice from Apple about the larger screen of the iPhone6: This is impossible because Apple doesn't release any information until the date of Keynotes and WWDC.
B. You can or not use Storyboard, and you can or not use AutoLayout: the 2 things are separate because you can also use AutoLayout in nib or programmatically.
C. What developers don't know, is that Storyboard are just a market move. I spoken directly with a my friend engineer in Apple about this and the information is real. The reason is also obvious. Is not the topic to speak about this but you can search on google and you will find a lot of information about the advantages to don't use storyboard.
Yes, storyboard are easy, but are not developer friendly if you think to work in a serious project with a big team. In a team you can use GIT, you can use shared repositories, you can export a part of code with the interface...in all this thing, Storyboard are BAD!
So i encourage developers to DON'T USE storyboard and use at max NIB file, or write the UI directly by code.
There currently doesn't appear to be any advantage to using storyboards versus XIBs or programmatic layout as far as multiple screen sizes are concerned. Auto-layout is definitely advantageous as it allows you to define your interface elements in relation to each other (and the screen), as opposed to using fixed numerical values for location and size. This would allow the UI to then easily adapt to varying screen sizes and aspect ratios.
The only potential reason storyboards could become useful for multiple screen sizes in the future is if Apple adds functionality to them to allow you to define entirely separate views based on device/screen size. So for example, they might make it easy to show a view with an extra sidebar on a larger screen, but show a separate view without the sidebar on a smaller screen (they might make it possible to configure this easily in a storyboard, versus writing a bunch of code to detect the screen size and load the appropriate view programmatically). As of now, though, no such functionality exists, but that could be a potential source of the rumors regarding storyboards being useful for multiple screen sizes.
I am planning to use a couple of picker controls and segmented controls (as a kind of control panel) embedded in a container view controller to control the contents of a second child view controller. However, according to Apple iOS Human Interface Guidelines, on an iPad a picker may not be presented in the main screen and must be presented in a popover:
On iPad, present a picker only within a popover. A picker is not
suitable for the main screen.
How strict is this rule?
Would it be ok in my case to have the picker on the main screen in order to provide the required interactivity?
Clearly the answer to your question really depends on Apple, not on anything we developers might think or say. Your screen design looks very reasonable to me, but the issue is really whether Apple will approve it.
It might be better to ask if anyone has had an app approved with pickers outside of popovers.
Alternatively, you could ask if anyone has had an app rejected for using Pickers outside popovers.
Apple rules and common sense have a high degree of overlap, but where they differ the only thing that matters is Apple. Either ask them, or just submit your app for approval and see.
Good luck!
Here is my experience regarding picker.
I had an app (say appAA) approved, which use picker view in a modal view, three pickers, one followed by another.
I had another app (say appBB) which basically copies the modal view of appAA. This app was rejected because of a functional problem which I could not reproduce. I debuted in Resolution Center, then the reviewer rejected again with additional reason, saying the pickers are not presented in popover!
I guess I have to put the pickers into the popover if I want appBB to be approved since the review mentioned so.
I think the answer is simply How ugly does it make the UI look?
The left/right edges of the picker were originally intended to be flush with the edge of the iPhone screen (and it was hardcoded to be 320px wide, which failed to work sensibly in landscape mode). On the iPad, the UIPopover lets it be flush with the frame. The obvious way to achieve this effect without using a UIPopover is to draw your own frame, instead of leaving a flat grey background between the pickers.
However, the easiest (and better looking, IMO) solution is to take the picker background (as a 1px-wide image) and use a UIImageView to stretch it behind all the pickers so they look like part of a continuous bar. Remember to check both retina and non-retina versions.