We have an iOS app and we were asked to also support tvOS. All our UI is done in .xib files, but the problem is that all the sizes for views, margins, text, etc. are in points. That was totally fine for the iPhones and iPads, as the points are pixels multiplied by a scale to get them to look the same on all resolutions.
But when we built the app for tvOS, all our views are small and in the center of the pages. I read that this is caused because the resolution for tvOS is 1080p, with a scale of 1x. See article here.
For the UI to look the same, I would like to multiply everything by a scale of 4. By everything, I mean again: view size, text size, margins, spacing, etc.
Is there a way of doing such a thing without completely rewiring the UI?
Related
I've been working through tutorials in order to get the hang of using auto layout. I'd like to start designing more interfaces in code versus using the basic options available in storyboard. However, before I explore this idea, I'd like know if the iOS coordinate system is equal across all devices?
I know that most of the latest and greatest iOS devices have improved retina displays but I'm not sure if that affects the coordinate system.
If the above is true then a second part to this question would be what x and y values can I go up to in the coordinate system before the view is no longer visible?
Obviously different sized devices have different sized screens. The old 3.5" iOS devices were 320x480 points. Then the 4" device were 320x568. And of course all the newer devices are bigger yet. Most iPads are 768x1024 but then there is the iPad Pro, etc.
And there is the difference between points and pixels. Only worry about points. This hides whether the device is the old non-retina, 2x retina, or 3x retina.
But none of this is relevant. You don't need to know any of these sizes. That's the whole point of autolayout and constraints. Even with code, you don't need to know absolute sizes. Ask a view its size. Make decisions based on that size. Apply layout based on the size at runtime without any hard coded knowledge of screen sizes.
I'm new to Xamarin and I'm actually developing an Android App. I've tried to run the app on different Android phones, but the fontSize appears either too small or large. Programmatically, how can I scale the FontSize of texts so that it can be adjust according to the device's screen?
Firstly, make sure you are using sizes in dp not px (or in, mm etc.) as these will factor in the screen density.
If you still have an issue, look at Screens support in the Android Docs, especially Using configuration qualifiers. Examples can be found here.
Basically you would need to provide a different resource file for each screen size. You should have a file something like res/values/dimens.xml where you store sizes for all your components. Make sure your font sizes are declared and referenced from here. You can then create a series of folders/files for the different screen sizes
res/values/dimens.xml
res/values-sw320dp/dimens.xml
res/values-sw720dp/dimens.xml
res/values-sw1024dp/dimens.xml
where each of these folders define the smallest width screen that that file will be used for.
In my iPhone app, I have a control that takes on quite different sizes on different screens. For example, (in the iOS point coordinates)
3.5 inch devices (iPhone 4S): 242x295
4 inch devices (iPhone 5 series, SE): 242x383
4.7 inch devices (iPhone 6 series): 297x482
5.5 inch devices (iPhone 6 Plus series): 336x551
As you can see, these control sizes are not proportional.
The problem
This control has an image as its background. That particular image is important for brand identity and the custom appearance that my company's designer wants to go with. The image gives the appearance of a material and has a texture. It also has shadows within itself. I would like to apply this image on to controls of different screen sizes (my control sizes are determined at runtime according to available space, as Apple may come up with new screen sizes anytime).
My current solution
The designer makes separate PNGs for me for each screen size and I hard code it with onto my control using an if-else for screen size (after determining the size mathematically before hand). As you can probably tell, this is a horrible approach for robustness. I'm also looking to expand to iPad and having a better scaling system will certainly help.
An idea
I take an image that's the smallest unit of the repeating texture and apply it to my control with the scaling option that repeats it throughout to obtain a final image.
HOWEVER, I lose my shadows and rounded edges this way. (I tried simply using the largest image as well and the disproportionate scaling makes the rounded edges horrible)
I tried looking for solutions and most resources do not deal with such images. I simply cannot lose any part of this image and it should be fully applied to the control, shadows and corners included.
I apologize if any or all of this is naive or if I didn't look for answers using the correct words. This is my first time posting here at Stack Overflow, and I'm looking forward to hearing from you guys.
Thanks!
p
Edit:
This is applied to a custom UIButton based control to give the appearance of a card.
Edit 2: Wain seems to have suggested a perfect answer. I will try it and let everyone know the results.
I'd use tiling as you describe, and I'd combine that with changing the view layer corner radius and applying a shadow offset. In this way you can separate the important part of the image and make it nicely reusable and you can leverage the capability of CALayer.
Note that when you set the shadowOffset of the layer you should also look at the shadowColor, shadowRadius and shadowOpacity.
You can used Assets.xcassets for managing images in ios. you can make image in 1x,2x and 3x scale.
For example you want an icon of size 50x50 pixel then 1x should be 50x50,
2x should be 100x100 and 3x should be 150x150. then ios automatically take appropriate image from this set.
Hope this will help :)
The aspect ration of iPhone 5, iPhone 6 and iPhone 6P are almost same. however the aspect ration of iPhone 4 is different.
Here is the steps which helps you.
So you need one image which image is suitable for iPhone 5 and its
#2x, and #3x image and iPhone 4 and its #2x image,
i.e if you have image with 242x383 for iPhone 5 then you need images
with its #2x, and #3x images. and you need image which is compatible
with iPhone 4 size.
You need to set UIImageView's contentMode as aspectFit.
So the idea is, make iPhone 5's image and its #2x, #3x images and iPhone 4's image differently. or you can put all things in UIScrollView and for iPhone 4 set contentSize of scrollView is 568. and make different image for iPad.
As of yesterday I had an app using mostly static sizes to fit an iphone 5 screen (320 points width). It was working fine in iphone 6 as well thanks to the system scaling up automatically.
Then I decided to add a retina hd launch image and everything became a lot smaller on iphone 6. So I decided to modify my whole application to use dynamic sizes and fonts so that it would fit the two iphone types the same way. And now it is working quite good.
But after these few hours of extra work, I keep asking myself the same question... what was the point? Why would you want to use dynamic sizes that fit both iphones when you can make it work for iphone 5 and let the system scale up automatically?
the use is: more screen estate. You can fit more on the screen.. at the least images or maps could be bigger while buttons retain there size -- they normally don't need to be bigger :) same for the keyboard.
you don't just get everything scaled but you can decide what is scaled and what isnt
I would like to ask a question about the highly confusing (at least to me) topic - Size Classes in Xcode 6. I have been trying to get a full understanding of how all this works, but it is still not clear to me.
Before Xcode 6 and the new iPhones, everything was very straightforward. To, Non-Retina and Retina, displays that enabled us to work with always same resolution 320x480 (or 568 for taller devices). Standard and #2x assets made perfect sense. Now however, we have the big ass screens with the same ratio (almost the same), but working area is not the same any more.
Size Classes are supposed to make things possible to fit all of it in one storyboard. But wait.. iPhone 6 uses #2x assets, which, in my understanding, means that the graphics will look smaller on that device than on iPhone 5/5S. And iPhone 6 Plus uses #3x assets, which again aren't gonna look the same. Seems like it is not possible to make, for example, a certain button always be of the same size in relation to, say, full width of the screen. Unless we code that of course, but that would make Size Classes useless.
Am I understanding things correctly or am I missing something? It would be great to hear how you all see it. Maybe you know some good tutorials? I haven't found anything that would explain my doubts.
Thanks in advance!
You can do much of what you're talking about here using a combination of different approaches:
Size classes for different types of devices to cover most large-scale changes in UI configuration (for example, differences between iPad and iPhone). You might use this to change whether a sidebar appears or not, for example.
Autolayout rules that are specific to individual size classes. You might add different autolayout rules for different size classes in order to tweak the layout (for example, you might switch between a horizontal row of buttons and a stacked column of buttons this way, since you can now have different Autolayout rules for different size classes). This technique is extremely powerful once you realize that you don't need to use the same autolayout rules for all size classes anymore.
Asset catalogs to switch out pre-rendered graphics for the different supported resolutions, etc, automatically. Note also that because many older devices don't actually support iOS 8, you don't need to include the really low-res versions anymore unless you need extensive backwards compatibility (and if you do, not all of the size class features are available anyway). I just made a new version of the app that only supports iOS 8, since users on older versions will just get the previous version of the app.
Resizable images: you can now specify resizable areas within images in order to control how they get stretched when applied to things like UIButtons, etc, that may change size according to Autolayout rules. (This is a feature Android has had for quite a while, so it's welcome on iOS.) This means that you can make things look good on a wider variety of screen sizes without having as many separate images or as much precise control over the size of the UI elements.
Programmatic code in the view controllers to tweak anything that you can't achieve any other way.
While it's true that you don't have quite as fined grained control over which devices show what exact layout with size classes, I found that this wasn't really as big a problem as you might think, as the size classes let your view controllers adapt to different devices very seamlessly. The combination of autolayout and size classes is particularly powerful. And it's actually potentially a good thing, because it means less new manual configuration whenever Apple comes out with a different screen size. It's a bit of a pain right now to convert, but probably worth it in the long run. You just have to think about how you set things up a little bit differently. It is a little bit more like Android, where they have long had to contend with lots of different device screen sizes and resolutions, but it's also the sort of natural evolution of the platform where you can't really precisely design for every single physical device as a practical matter (you should still test on them in the simulator, though).
Size classes are not there to just adapt to a larger screen size, they are there for completely different layouts. Like on an iPhone you might show one item and tap to get to the next screen for more information, but on an iPad you show both on the same screen.
For small adjustments, you use auto layout, with different layouts per size class, and the different screen sizes in each size class are handled by the auto layout.