I'm starting to think about how to solve the problem of developing an app for all iOS devices with different screens (resolution, ratio, retina, etc). I'm working with Adobe Air (AS3), but that really doesn't matter because I'm in a conceptual phase and I'm concerned about the patterns to use.
If I was only developing for iPad, the problem would be as simple as doubling measures and sizes to adapto to retina and non-retina devices. But I need to take into account iPhones, iPods, and eventually Android too with it's myriad of screens.
So far I see those possible options. I'm sorry if there's already some terminology for those options, but I'll just say in it my own words.
Intelligent views that have some sort of liquid layout, and also intelligent components that adapt to the space the view is assigning to them, and to the screen dpi for font sizes, and image sizes. For example: the view says "here goes a button on the bottom with this width/height". The button already knows what font size the text must be depending on the screen dpi.
Factorization with parameters of different UI view classes. So I'd have one view class for iPad, another for iPhone, etc. and there would be one class that would factorize the instantiation of the view depending on the device. Each of those classes could be hand tailored to be completely different from each other, but the underlying model and (hopefully) the controller would be the same on every device.
A middle way approach: One UI View class for tablets, another for phones, and each of those with some sort of liquid capacity to fine tune the position and size of elements (buttons, texts, images, etc).
External config files that give the View some parameters depending on the device. That would be some sort of custom CSS.
I'm sure I'm not the first person to find this rock on my path.
So how is this problem usually solved?
Is there some stablished pattern for those scenarios?
Is there some reference (book, article) I should read?
I haven't been able to find an in depth answer to this. If it's already been asked/answered please don't downvote. Post the link in the comments and I'll just delete this question.
You are describing Responsive Web Design. There are multiple approaches and ways to make you site responsive (i.e. capable of running on multiple screen sizes without having to modify or reconfigure the codebase or rely on user-agent to detect the browser info).
Start from here: http://msdn.microsoft.com/en-us/magazine/hh653584.aspx
Also consider various open-source CSS frameworks that will simplify your life. For example, Bootstrap and HTML5 Boilerplate. Both of those are fairly independent of your development platform and should work well with MVC.
Related
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.
I'm gonna create an app that supports both iPhone & iPad. Before proceeding, I just want to know the best practices about both app development.
Here is some points that I know:
Consider that I have a tableview that shows N number of records and say it as PAGE-1. When the user tapping on the cell, it will load the PAGE-2 to show details about the tapped record. This is more common scenario that used in every app.
For iPad, this is not the case. I can show PAGE-1 along with PAGE-2 in the same page.(Consider landscape mode)
So, iPhone's PAGE-1 will be displayed in the left panel of the iPad & iPhone's PAGE-2 will be displayed in the right side panel of the iPad.
Conclusion:
So, I can make a common class for both iPhone & iPad. That will handle the PAGE-1's common functionality to both iPhone & iPad.
The device specific functionality may separated into separate classes for both iPhone and iPad.
Other than that, network related methods, parsers, utility methods, categories, custom controllers can be written commonly for both iPhone & iPad.
The only addon to the iPad is, it should have a controller that will hold and handle PAGE-1 and PAGE-2. This make sures that the PAGE-1 does not hold PAGE-2 and they both are independent like iPhone's PAGE-1 & PAGE-2.
Refer the below attached image that will demonstrate clearly.
Questions:
Is this approach correct?
I really don't know about iPad's "Container" controller. Should I need it? Or is there any other better proposal to group the things effectively?
This may be a basic question, but I need a clarification for better code pratice.
Thanks
It doesn't sound like you need specific page 1 & 2 subclasses, though that depends on exactly what the differences are between the pages on each device. It may be that a collection view suits your needs better so you can simply set the item width and the layout will organise your content into columns where appropriate.
It sounds more like all you need is 2 different container classes for the top level which decides how to display page(s), or more specifically, how many pages to display and where they are on screen. For iPhone that's really simple, for iPad slightly more complex (mainly due to rotation handling).
Note also that if you create a new master-detail project in Xcode and ask it to support iPhone and iPad you will see that a split view controller is used, optionally, for exactly this situation. This bypasses the need for 2 container classes by having the app delegate decide whether to use a 'special' container or not (for iPad).
When creating an application is it possible to just get the dimensions of the device's screen and then to divide the dimensions by a number so that all UI elements will look similar on all devices?
I know that this can obviously be done, but is it something I should consider doing? Or should I consider creating multiple storyboard files to cover every single iOS device? Or is there a feature that storyboards have that allow you to do this and I just haven't discovered it yet?
If you set the sizes of UI elements to specific numbers (and not ratios) when you are programmatically adding the UI elements, the whole screen will look a bit off when you use a different device with a different screen size. So if I wanted to create user interfaces for all devices programmatically (without storyboards) would I have to write different code for each device? This is why I'm wondering if it would be better to just use ratios for the sizes. By doing that you will only have to write the code once.
Which way is best for designing for all screen sizes?
When creating an application is it possible to just get the dimensions
of the device's screen and then to divide the dimensions by a number
so that all UI elements will look similar on all devices?
No. It's proper only where it fits. Sometimes there's a situation which allows this scenario, but usually not. Because absolute size and proportion of devices are all different, and different layout needs different behaviors and interactions.
Think in users' perspective. Would you like to use such app? Well if you don't need UX quality, it's fine to do whatever.
There's no magic. Strictly saying, in worst case scenario, you need to always be prepared to write separated version of layout code for every each devices. If you have situations which can share a layout code (using whatever techniques), that's just lucky.
To optimize production, you can try to group devices in similar proportion. Apple calls this layout-idiom. Usually iOS devices builds two group --- phones and pads. In this case You need to make sure that all the UI components to support minimum range of flexibility in layout to deal with extra screen proportion fragmentation. Utilize
Manual programmatic layout
NSLayoutConstraint
for this.
In my experience, this is the most time-saving approach. Sometimes just making all version of layout is better, but this is rarely happen.
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'm working on building a universal iOS configuration application for the iPhone/iPad. But the layouts ('views') for the iPad are considerably different from that of the iPhone. Considering that only the appearance of the application ('views') change w.r.t the device, what is the most efficient design approach i could follow?
Things I've already looked at
I've looked at one strategy where different View controllers are loaded depending on the device in use. But this might be an overkill considering that the 'controls' are the same across devices and only the appearance of the application changes.
The use of functions to resize the view frames to layout views as needed automatically. This does not help me much because there is a need to not only change the size of the views but load different views altogether depending on the device.
To keep the viewController unchanged but configure the views inside the viewController differently. Right now this seems like the best way to do it, but the application is kinda heavy and it might become very messy in the long run. Or is there a very efficient way to do this?
Is there a design strategy for this?
Or is there any way i can accomplish this efficiently while optimizing effort?
The standard approach is to have different XIB files for iPhone and iPad, which the platform will select automatically if you name them right, e.g. myview~iPhone.xib and myview~iPad.xib.
You are concerned about inefficiency: I wouldn't worry about the file size as compiled XIB is quite compact.
In my apps I mostly use this approach, with some fragments of code to add or remove buttons for each platform. Simple views can just be set up to resize automatically using the standard struts-and-glue techniques.