Is there any indicator in xcode about the size of table cells and picker cells, so I can work out how big my images need to be in there, how much gap to leave for the edges etc. Just need some kind of guidelines indicator as to where my cursor is on the control I suppose. How do you guys deal with working out layouts?
Thanks (sorry if the question is a bit wooly).
Xcode does not provide any such guidelines to do so, but there are some other software that can be used.
You can use MockApp or omni graffle to design your apps. You can also use photoshop but it might be an over kill if your app is small or low budget or if you dont know how to use it.
Related
I am designing my first iOS app at the moment. Every view of the app needs to be available in portrait aswell landscape. Also all iPhone versions need to be supporrted.
As someone always working with windows and never owning any apple product it was a pain in the ass getting started but slowly things seem to work out. But before the whole design approach takes a wrong direction I rather ask here:
What I want to do is have constraints based on multipliers as much
as possible.
I will try to avoid constant values as much as possible since from
my understanding they arent scaling. I read that you can change them
programmatically but if possible I want to stay in the designer for
frontend related stuff.
Since the multiplier cant be changed based on the current size class
I plan to have a set of constraints for all kind of portrait size
classes and another one for landscape (using installed feature of
xcode)
To up and downscale labels and textviews I want to have a height
constraint to the superview with a very tiny multiplier (will
probably be complicated to keep all textviews the same height when
there are different parents across them?)
In theory this should produce views which up and downscale well and look the same on all kind of iPhone screens. Now I am curious what more experienced iOS designers think about my "plan":
Do you have different approaches?
Is there any book/tutorial/page you can suggest?
Thanks in advance! :)
I've been struggling with this issue for a while and hours of research and experimentation didn't produce any acceptable results.
I have a login screen that contains a lot of UI elements. The view looks great on iphone 7 and 6 variations but when I test it on SE or 4S the constraints fail to position the elements so they fit nicely on their tiny screen. Simply there is not enough room. I read that I must support all screen sizes but at this point I am not sure how can I get all the ui elements to fit in the smaller screens.
I watched hours of youtube videos and tried all possible ways including a vertical stack view but no matter what I try, it either looks good on 7 and 6 but terrible on SE/4S or vice versa (good on SE/4S but way too much white space on 7/6).
At this point I am not sure what else I can do. I know it is not possible to design a UI just for a specific screen size and vary for traits is not what I need because I only intend to support vertical orientation.
Any help or suggestion will be greatly appreciated.
As you have said in your own comment, you can restrict the device sizes indirectly by restricting the iOS version. However that is not a good solution: If you are creating the app for commercial reasons that will unnecessarily restrict your market (there are a lot of 4S users out there); If you are learning app development, now is a good time to work out how to manage GUI layout problems properly (there will always be a wide range of display sizes to cope with).
There are several tools available to assist:
Auto Layout
As others have said in comments, Auto Layout can help a lot. Don't just use it to position things though, but also to resize them to make best use of the available space.
Understanding Auto Layout (Apple)
Size Classes
Size Classes allow you to use different constraints and turn on or off controls depending on the general size and orientation of your user's device. For example, where space is restricted you could hide individual controls and instead display a single control to take the user to them elsewhere (another view or a popover for example).
Size-Class-Specific Layout (Apple)
Scroll Views
You can make part or all of your GUI a scroll view that on larger devices will show all the controls whilst on smaller devices initially show just the top ones but still give your users access to the others (don't forget to flash the scroll bars when the view first appears to show them that there is more to see though).
Separate Storyboards
Although you have not mentioned iPad support, you can also specify completely separate storyboards to help layout universal apps.
See this SO answer and it's linked reference for details.
New to iOS developing here. Basically I am creating a soundboard app. I have the app essentially working (aka buttons returning sounds).
However my app only looks proper on the iPhone 6. I just have one ViewController in my main storyboard. When I run the simulator for the 4S/5/6+ or iPads, my buttons are pretty much everywhere.
I tried playing with size classes/autolayout through Apple's documentation, but couldn't get it working properly. What's the best (easiest ;) ) route I can follow to have it basically looking the same on ALL devices?
PS: I have one background placed too, I don't mind if it looks different on all devices since it's pretty minimalistic, but if someone can shed some light here too, that would be great.
Thanks!
You have a few options:
1) Continue your plan spending time getting friendly with Auto Layout and Size Classes. This might be difficult at first, but it will really pay off later. You should use the Assistant Editor's Preview mode to let you see iPhone 4, 5 and 6 side-by-side as you work so you can make sure your layouts look great everywhere.
2) Use a component like UIStackView where layouts are automatically adjusted to fit various devices. If your soundboard is as simple as a grid of buttons, you can do that in just a few minutes using a stack view.
3) Use a component like UITableView or UICollectionView where content is designed to scroll. Using this method you design only one sound button of your app (i.e., enough to play one sound) then have iOS replicate that across all the sounds you want. When your interface is presented on a device of a different size iOS will just make the content scroll.
Very roughly, option 1 makes you do all the work; option 2 makes your layout shrink down until it fits the available space; and option 3 makes your layout stay the same size no matter what, but you should expect it to scroll on some devices.
There is no right solution; it's entirely down how you want your app to work.
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 developing non-standard rich text view to display output of some other program. I found it is very easy to do by just adding loads of UITextView into ScrollView, and then set various properties for each label. Like text size, color, transparency etc, etc. Some of them could be clickable buttons.
But now the logical question, how many TextViews iPhone can safely handle?
Of course, I can do some tests myself, (and will I do) but it might not be reliable, maybe someone knows better from experience or some documentation or calculations?
Maybe the question could be generalized to "how many views"? But I am interested mostly in TextViews so far.
I think you don't need to worry about the safe number of UITextView you can use. Because you know the screen of the iPhone is so small. Do you think you need so many UITextView on one screen that the iOS even can not handle?