I am about to deploy my first React Native application to the iOS app store. I am having a problem however when it comes to layout. I am utilizing the flexbox system and currently designing for iPhone 6. I have done all the mockups and Sketch and have everything how I would like it to look.
I have run into a problem however whenever I try to run the application in iPhone 4. The design that I have implemented for the iPhone 6 does not fit with the constraints that iPhone 4 possesses.
I can try to redesign things for iPhone 4, but then things become too small / ugly on the iPhone 6. I really need things to look great on all of the screen resolutions (i.e., iPhone 4 - iPhone 7 plus).
I have seen on the web many different solutions: apply a constant to each stylesheet value, dependent up the aspect ratio of the device; check the device and render different components based off the device your are on; and make better use of flexbox in order to make the layout responsive.
The first solution doesn't seem like it will give an accurate representation on each screen size, the second solution seems to create too much excess code just for styling, and the third solution seems to not account for static sizes and font sizes.
I normally would begin to follow the third solution, but there are some things that can simply not be a percentage of the container (e.g., button height, font size, some margin and padding, etc.)
Therefore, I am asking the question: What is the best way to approach this problem in React Native? I really need a thorough de-facto answer that can explain the best way to go through the development process as well (e.g., should I design for the smallest screen size and then fit it to bigger sizes? should I design for all resolutions? etc.).
A big thanks in advance for those of you who have felt my pain and have discovered a great solution, please let me know what that solution is.
Ok, so I think i understand how to go about doing this now. It looks like the key for designing for multiple screen sizes in iOS is not to necessarily make things bigger on bigger phones and smaller on smaller phones, but to design for what works on the smallest screen size, and let the items look small on the bigger devices.
It seems that the idea behind this type of responsive design is that individuals with bigger phones desire to see MORE CONTENT, not blown up content. Therefore, if it works on small phones, it can also work on big phones.
Take buttons for instance: If a button at 40pt looks good on an iPhone 4s, it will also work well on an iPhone 7 plus. The benefit is that the user of the iPhone 7 plus is able to see more content, rather than just a bigger button.
This design also makes it to where multiple screen sizes are not necessary for styling.
There is still a role in determining the dimensions of the device you are on, but this is more to determine whether you are able to display more content (e.g., in the case of iPhone 5 vs iPhone 6, whether or not to display an additional tab button), as well as the layout (e.g., where should I place the menu).
You can see this type of design on most of the very popular web application native apps.
Images and videos are one of the only exceptions. It seems that it is helpful at times to automatically grow the images whenever the device and the design call for it. Fortunately, this is very simple by using a flexbox and responsive technologies as are included with react-native.
I hope this helps others and saves them some time. Note: this does not provide for the problem of landscape vs portrait. Under that situation, it is probably best to use some sort of varying styles.
I have felt your pain and choose a similar solution to your first one also similar to the blog post mentioned by Shukarullah Shah. In my style.js file first I obtain the device width and height using;
const x = Dimensions.get('window').width;
const y = Dimensions.get('window').height;
Then I divided each dimension, x and y, to 10, 20 and 40. For width, it become like;
const widthS = x / 40; // ~10 px
const widthM = x / 20; // ~20 px
const widthL = x / 10; // ~40 px
Then I use these values to define any size for margin, padding, image size etc. Also I use a common style.js file for each component I have. So that I define these constants once and I can see/compare every style piece I have easily. Of course you can improve these kind of definitions like in the blog post mentioned. But I am a developer not a designer so that I am not so edgy about perfect ratios.
I have read useful blog on medium about Responsive Design in React Native. I did not get time to try it but I think it will solve your issue, let me know how it works for you.
Related
Since it's a bit difficult to explain, I did a mockup to get across as much as possible visually:
http://sassmeister.com/gist/70624a740b1ca4ae7764
(If there's a better way to share a sass gist, let me know. First time using it)
Basically, this is the layout I want for a tablet in landscape mode. What I'm trying to do is make sure it fits perfectly on different tablets with different aspect ratios. Some things are fixed. The main content area is a 16x9 video, so that aspect is locked.
I have the header and footer (main column only) fixed right now as they need to be for portrait mode, but I could bring them into the regular flow if it's helpful for tablet landscape. Anyway, it's all basic responsive right now via susy2, and the sidebar is totally separate so it can scroll independent of the main content. What I would like is for the whole main area including header and footer to fit perfectly with even margins above and below vid, but then have the sidebar column change it's width to match the tablet.
So... if the tablet is wider, the teaser thumbnails go out to 16x9 ratio. If the tablet is narrower, the main column remains unchanged, but the teaser thumbs narrow down to squares.
If it's easier first to just figure out how to responsively shrink the right column only, so the aspect of thumbs is unchanged, that's ok. I just don't want the overall layout to get screwed up on one device vs another because of aspect ratio, so main focus is that the header hits top, footer hits bottom, main vid fits perfectly between them, then sidebar responds to fill in the rest (within reason).
thx for any input. First time making a website here, so lots to learn.
ps. I had vertical scroll enabled for the right column, but disabled it (by adding extra letter to to the scrolling class in scss column) since it's not actually letting me scroll. Not sure if that's because there's no actual content, or it doesn't recognize the empty padded cells as something worthy of scrolling.
You're biting off a lot for your first website, but Sassmeister is a great way to show what you are doing. I approve. :)
One of the problems you'll find is that CSS don't have the concept of aspect ratio built in, so the sort of layout you are attempting is non-trivial. CSS is best at handling widths, and letting everything overflow vertically. It takes some effort to make it handle height well.
If you can get away with it (depending on browser support), your best option is to use flexbox. Flexbox should make this much easier, but doesn't ave a lot of support yet. You could consider table-cells, which have more support, but can be harder to control.
In any case, you should ignore most of Susy for this — at least in laying out the large sections. If you want Susy to help you with grid calculations, ditch the mixins and just use the span() and gutter() functions to help you set widths. Something like this:
.flexbox {
flex: 1;
flex-basis: span(3);
}
.tables {
display: table-cell;
width: span(3);
}
// NOT THIS
.no {
#include span(3);
}
You can go back to using Susy mixins for simpler bits, like the items in the top navigation.
I have a fundamental question that I would like to get addressed. I'm almost done with my universal app and I was told that I need to specifically customize the UI controls for iPad screens (e.g) labels, buttons. So, for example, I have the following code in viewDidLoad event in one of my xibs.
if ([[UIDevice currentDevice] userInterfaceIdiom] == UIUserInterfaceIdiomPhone)
{
[_lblRandomDisplay setFont: [UIFont fontWithName: #"Helvetica Neue" size:100]];
}
else
{
[_lblRandomDisplay setFont: [UIFont fontWithName: #"Helvetica Neue" size:250]];
}
Here _lblRandomDisplay is UILabel IBOutlet property and I increase the font for iPad and reduce it for iPhone. Is this the way to approach the iPad screens or does iOS automatically scale the screen when viewed on iPad?. As a side note, I have named the xib filenames as filename~iphone.xib and filename~ipad.xib and it loads correctly based on the device selected in the simulator.
In those lines, I have a Settings screen (not using the Settings bundle) using UITableViews that I have designed for iPhone and programmatically load data from NSArray. When loaded on iPad using the settings~ipad.xib (copied the controls from settings~iphone.xib), I haven't adjusted the row height specifically for iPad to make it look bigger. The screen shows OK on the iPad but it looks smaller. Is this the right approach or what is the best way to approach this?
Please advise.
The advice that you have been given, to customise UIControls for screen size, seems wrong. UIControl sizes, and text sizes in general, should remain the same on all devices. These items are designed in sizes appropriate for readability and touchability, neither of which has any relationship to screen size.
iOS is designed with this in mind. If you make a universal project with iPad and iPhone xibs or storyboards, you will find that user interface widgets are the same pixel/point size regardless of the device (I am ignoring Retina/non-retina distinctions here for simplicity). For example, the default size of a standard button is 73 x 43 with a font size of 15pt in both cases. A Navigation Bar is 44 px/points high on both devices. This is as it should be. If we assume that reading distance on an iPhone, or an iPad mini, or an iPad is approximately the same, then there is no reason to adjust text size. The idea of redesigning for the iPad is really that you can get more information on one screen, not a bigger version of the same information.
There are two circumstances in which iOS "scales the screen":
is if you create an iPhone-only app and run it on an iPad. Then there is a user option to run it at double size. In this case everything including font sizes are scaled up, but this is done by pixel-doubling, so the effect is a big blur. Take a look at it - and you will understand that this is precisely the reason why you should not design in this way.
if you use a single xib/storyboard for both iPhone and iPad, and rely on autolayout (ios6+) or autoresizing masks (ios5-) to auto-adjust the layout for different screen sizes. This method can -depending on your settings - proportionally resize image content of views, but will not dynamically resize text content, if you wanted to do that you would have to adjust in code. This is not a good way of designing an app anyway, it is better to make a dedicated design for iPhone and for iPad in separate xib/storyboards as you have done.
I expect when you say the iPad "looks smaller" you mean, the UI appears smaller as it gets lost on the larger screen... but the answer is not to just enlarge the size of your data, it is to reconsider your layout to fit more data on each screen. That is why with the iPad Apple provided the SplitViewController and introduced the pattern of the Container ViewController.
I wonder if you are also raising a related, but separate issue of proportional sizing of views for graphic design purposes (you mention font sizes of 100 and 250pt, not usual sizes for UI controls labels). You may want the look of your app to scale with the screen, a bit like the so-called fluid web design approach to variable window sizes. So for example you may have a graphic device based on a huge letter 'A' that fills your iphone screen, and want that letter to similarly fill you ipad screen. In this case you may need to set font sizes as in your code example.
You are certainly doing the right thing by not altering the row height of your table cells for the different devices, but for the larger screen you can of course make your table height larger, and accomodate more table cells in your view.
All of these comments are a bit general, as you haven't posted enough detail of your problem. It often helps to post a picture or two...
This post is not about code-syntax but about work-strategy, before I start developing the site.
If I need to design the front-end of a mobile-site for smart-phones (Androids { 3 different sizes}, iphones {2 differents sizes}, and other non - smartphones phones) how shall I proceed? (MY DESIGN HAS TO WORK AND BE THE SAME FOR ALL THESE DEVICES)
1- shall I design my work following the idea about flexible images and fluid grids (flexible DIV:s).
or
2- set different media queries-sizes for every target model? (this solution might create more development-work isn't it?)
Thanks very much for yr thoughts...
Use fluid grids first. Then you can use media queries to do some final tweaks. Like e.g. float an image to the right if there is room (landscape mode).
This way you support nearly every device out there, and not just the big 2 (although Blackberry is bigger than Android I believe).
# YoniGeek; may be you have to use fluid layout.
For this just define screen width instead of device width & define css for maximum device screen size. So; you no need to define different css for different devices.
Read this article http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web-design/
Check this site for inspiration http://mediaqueri.es/ & look same in all devices.
It's a matter of preference really. You can use a fluid design, media queries (with css transitions) or a combination of all techniques.
On my most recent project, I went with media queries. Once I had the basic design done it took me less than an hour to have it working on varying resolutions from 240 pixels to 960 pixels wide. So more development work... it was not.
My previous recommendation on one of your prior questions still stands:
Design (ie: one design.css file or split up into multiple files such as fonts.css, typography.css, etc...) the site without positioning anything. You cam start with a HTML 5 reset, implement font faces, set the backgrounds, color the links, style the inputs but do not position anything (ie: if you have header, nav, content and footer sections, don't position them).
Use media queries (ie: layout-240.css, layout-960.css) to target your viewports and position each everything accordingly. They will generally contain less than 100 lines of CSS and take up less than 3 KB of diskspace but that's irrelevant.
My developer's box has a screen resolution of 1680 x 1050. I'm developing a full-screen Silverlight 3 application that I'm considering deploying to the Internet. So, I want to make sure the application looks good on a variety of screen resolutions. I just started testing on other boxes, the first one having a screen resolution of 1024 x 768. During the test I found some of the pages on the application were partially truncated. It seems the controls on the page didn't adjust for the lower screen resolution. So, I'm looking for some tips on how to make a Silverlight application, to the extent possible, adjust for screen resolution. For example, are there things one should or should not do on XAML to make adapting to screen resolution easier? Should I just optimize for a minimum screen resolution? Your thoughts and suggestions are welcomed.
You can easily enforce a minimum acceptable resolution by setting the MinHeight and MinWidth properties of your root visual. (Of course, this should be less than the minimum screen resolution to account for browser chrome.)
Try to specify absolute Width and Height only when necessary: for example, for images or icons of fixed dimensions, or for obvious cases like TextBoxes (whose width should reflect the average length of the data entered).
Grid panels are excellent for mixing scalable and fixed layout areas. The star sizing specification takes a bit of getting used to--it's not as simple as a percentage-based proportioning--but it's much more flexible, especially in combination with row/column min/max dimensions.
You don't really need to test on multiple resolutions unless you're interested in testing a range of dots per inch--just resize the browser to approximate different screens. Since there's always a bit of give and take depending on the user's browser configuration, you'll have to account for some variance anyway.
You can make your application scale with the Silverlight Toolkit ViewBox or make it strech with layout controls like the Grid, StackPanel, and WrapPanel. Make your main UserControl have a Width and Height of Auto (or remove the width and height entirely) and the size of the app will resize to the size of the parent div (the default HTML template uses 100%x100%). Then just resize the browser accordingly. IE8 has developer tools that can help you see your app resized to specific screen resolutions.
Testing on a variety of screen resolutions is always a good idea.
I covered the resizing of elements and making it resolution independent on another thread.
You can have a look here, there are multiple ways to sizing and resizing things automatically.
I have developed a 1024 *780 resolution screen in Windows Forms, but some say that it does not fit properly at higher resolutions. Is there any way to handle this?
Is there a way to make Windows Forms applications look the same at ALL resolutions?
My recommendation is not so much to "make it look the same" on all screens, but rather to design the GUI so it scales up and down more gracefully. Layout managers, docking, and anchors are your friends in Winforms. The TableLayoutPanel is quite useful for this sort of thing. Splitters also help...
Finally, this is one of those problems that WPF sets out to solve. WPF makes extensive use of layout managers. It feels much more like Java or GTK than Winforms or even VB (old school VB).
This is the sort of thing that makes you say "there's got to be a better way."
My solution for this one time was to declare a global ScalingFactor variable that was tied to the current screen resolution. Then, the sizes of every visual element were multiplied by that factor.
So, if I designed my form for resolution A, and resolution B is 1.2x larger, the width of window A will be with * 1.2, the fonts will be fontSize * 1.2, the textbox dimensions will be dimensions * 1.2.
Not fun.
There may be 3rd party tools that you can buy and will perform this scaling.
One other thing to check before you run down any of these roads is whether it is actually the screen resolution or the dpi settings that are causing it to look bad. Usually a higher resolution will only make it look smaller, but an atypical dpi, such as when the user selects "large fonts" will wreak havoc.
You can use anchor property of item, and autoScaleMode property of form set it equals 'None'.