What's the difference between iOSView.ContentSize and iOSView.Size

Targets iOS
1

I"m trying to successfully figure out the usable screen area in an IOS view. I was going to try to do this by taking the overall height of the view, minus the height of the top and bottom layout guides. But I found a bug in that while top and bottom layout guides have height properties, you can’t access them. You get a compiler error.

Anyhow, I’m looking further in the docs and I see the ContentSize method. To me it looks the same as the Size method for a view. And so far, both are returning the same values.

What’s the difference?

2

ContentSize is a bit like AvailableHeight.

Without anything, ContentSize.Height is 480
With a navigation bar, 416
With a tab, 431
With Tab+Bar 367

3

[quote=204240:@Michel Bujardet]ContentSize is a bit like AvailableHeight.

Without anything, ContentSize.Height is 480
With a navigation bar, 416
With a tab, 431
With Tab+Bar 367[/quote]
That’s in iPhone 4s Portrait mode. It’s probably not prudent to expect Apple to keep these numbers consistent though. Autolayout also gives the advantage that if Apple changes things, your layout adjusts as well.

4

It was just for the sake of illustration. Results vary with screen sizes, of course.

I cannot say I ever used that. I tend to trust Auto Layout :slight_smile:

5

Auto layout is fine. However, it will not reposition controls if the width of the screen is too narrow to fit them. It will not create a new view if the height of the screen is not tall enough to fit them.

Until auto-layout is truly a tool that automatically lays out the controls, we have to have a way to be able to handle it ourselves dynamically.

6

[quote=204249:@Jon Ogden]Auto layout is fine. However, it will not reposition controls if the width of the screen is too narrow to fit them. It will not create a new view if the height of the screen is not tall enough to fit them.

Until auto-layout is truly a tool that automatically lays out the controls, we have to have a way to be able to handle it ourselves dynamically.[/quote]

What you describe of controls bumping into each other happens only If you set fixed width and height for controls or if you fixed constraints limits too narrowly.

If you let Auto Layout resize controls height and width, then it works just fine.

No automatic layout system is able to guess the user intent. I have the same issue with RubberViews. but tweaks are provided precisely to deal with edge cases. If for instance I decide a control is to keep its width no matter what, then I have to deal with possible issues with that.

Overall, if you compare with current desktop where you would have to manage every single dimension, Auto Layout is a huge improvement IMHO.

You can, however, dynamically manage things in the Resize event and do amazing things, just as I described many a time, to have different layouts in Portrait and Landscape, for instance. You can also there push new views if your think the aspect ratio of the device requires it.

The only problem is, after dealing with a manual system in desktop and web, you maybe a bit too hopeful of an automated system. It still requires tweaking and intervention if you want more than an average result.

7

Xojo auto layout (as iOS and OS X auto layout) is not a layout system with GridLayout, StackLayout, FlowLayout, etc. like Qt or Java AWT include. It is – as other have described above – not a system to automatically lay out controls but a system to adjust already layed out controls to different screen sizes and to the rotation of the screen.

8

Correct. It’s a system to adjust laid out controls, not a system that does the layout for you.

9

[quote=204281:@Michel Bujardet]What you describe of controls bumping into each other happens only If you set fixed width and height for controls or if you fixed constraints limits too narrowly.

If you let Auto Layout resize controls height and width, then it works just fine.
[/quote]

No, you don’t quite understand what I want to do and how I want to lay things out. I don’t want my control sizes to shrink or increase. I do want them fixed because the number of controls depends 100% on the user’s system that the app will be working to control. To large a system and the controls would be so small it would be unusable. To small a system and you have monster size awkward looking controls.

So I get it what auto-layout does. But as Eli described perfectly, it’s for adjusting controls already laid out and to allow for proper sizing when the screen is rotated.

But even then it’s really somewhat limited in its use. Sure it can adjust sizes. But if you use the same view for say and iPhone 6+ and an iPhone 4, then either the UI on the iPhone 4 will look highly shrunk or the iPhone 6+ will look highly expanded. Auto layout does not allow for a more efficient use of screen space and control placement with larger displays.

10

auto layout is not a Layout Manager like Javas - see GridBaglayout

And its got constraints much like auto layout does as well
And I dont know many Java users that like many of the layout managers - they try to do way too much and door it not very well
I’m sure someone will disagree but I always loathed using any of them and did it 100% manually

Autolayout is somewhere in between completely manual & a layout manager like Javas

11

[quote=204315:@Jon Ogden]So I get it what auto-layout does. But as Eli described perfectly, it’s for adjusting controls already laid out and to allow for proper sizing when the screen is rotated.

But even then it’s really somewhat limited in its use. Sure it can adjust sizes. But if you use the same view for say and iPhone 6+ and an iPhone 4, then either the UI on the iPhone 4 will look highly shrunk or the iPhone 6+ will look highly expanded. Auto layout does not allow for a more efficient use of screen space and control placement with larger displays.[/quote]

My point was not to say the current iOS Auto Layout is perfect. Having implemented my own in RubberViewsWE, I know all too well the limits of such a system.

I never said it was a layout manager, because indeed, out of the box, it is incapable to do the same.

However, I believe it is a major improvement over the manual layout, and I know from practice it can be made to manage dynamic layout, given careful implementation.

The case you describe of controls overly shrunk or expanded, for instance, can be managed in RubberViews or Xojo iOS by imposing minWidth, maxWidth, minHeight, maxHeight to controls.

In an ideal world, Xojo iOS would have as many features as Java tools that have been around for several years. In the real world, Xojo iOS is only 7 months old or so. I am convinced it will still evolve. Remember the beta version, it has already been vastly improved.

I admit that is not as powerful as GridBagLayout or other layout managers. But indeed, that is a huge progress as compared to what was available until now.

As a comparison, B4A for Android is just able to keep controls proportional to the resolution. It does not even manage rotation.