Re: Device/Resolution independent positioning of GUI items on iOS
Re: Device/Resolution independent positioning of GUI items on iOS
- Subject: Re: Device/Resolution independent positioning of GUI items on iOS
- From: Alex Zavatone <email@hidden>
- Date: Mon, 19 Mar 2012 17:50:37 -0400
FWIW, I agree. This would allow any programmer (or even a non programmer) to lay out their screen, then switch to the rotated view and simply drag the items to where they think they should be.
Viola. Both orientations are laid out.
Sort of an approach of, "portrait is the default orientation and we automatically look for a layout coords file that handles landscape - if it exists, we use it."
Sure does sound nice.
On Mar 19, 2012, at 5:46 PM, Brian Lambert wrote:
> Imagine now if someone at Apple working on Interface Builder conjured up the notion of adding "modes" for a view design.
>
> This is the coolest idea ever for Interface Builder. :-) And I don't even think it would be *all that hard* to do.
>
> I add a new UIViewController subclass to my project, select "With XIB for user interface", and enter the designer. Once there, I set the view's orientation to "Portrait" and name this first, default mode to be "Portrait".
>
> I then add my controls and views to the view. Connect everything up to my controller. Write all my code. Happy times.
>
> Next I decide I want to have a totally different layout for the view in Landscape mode, one that autosizing won't do for me. (Right now I do this in code...) So, I create a new mode for the view, call it Landscape, and set its orientation to Landscape.
>
> In Interface Builder, I would then see two views, one in portrait mode, one in landscape mode, each with the EXACT SAME set of controls and connections. Then I could simply move all the controls around on the landscape mode view, and everything would "just work".
>
> This generalized "mode" feature could be used for the German layout, too. :-)
>
> I think this would be insanely cool. It would allow one to build ONE XIB with N modes for iPhone Portrait, iPhone Landscape, iPad Portrait, iPad Landscape, LTR, RTL, and so on, all sharing a base set of controls, views, and connections to outlets and actions.
>
>
> On Mon, Mar 19, 2012 at 2:20 PM, Brian Lambert <email@hidden> wrote:
> In Interface Builder all coordinates are expressed in terms of a non-Retina device, and scaled on Retina devices. So running a XIB on non-Retina and Retina "just works". The same holds true for doing it in code (generally).
>
> I'll give you an example. One of the projects I'm working on right now is a universal app that runs on iPhone, iPhone Retina, iPad, and iPad Retina.
>
> I am using only 3 sets of images and two XIB's to cover all devices.
>
> On the iPhone, I use the iPhoneFoo.xib, which is designed with Yada.png images. When the application is run on an iPhone Retina, the email@hidden images are used in places of the Yada.png images automatically. All coordinates scale automatically. It just works.
>
> On the iPad, I use the iPadFoo.xib, which is designed with email@hidden images. I simply use the iPhone's @2x image set as the default set on the iPad for non-Retina devices. When the application is run on an iPad Retina, the Yada@email@hidden images are used in places of the email@hidden images automatically. All coordinates scale automatically. It just works.
>
> This has saved me a bunch of work, and a bunch of binary app space. I'm pretty pleased with how iOS works in this department.
>
>
>
>
>
>
>
> On Mon, Mar 19, 2012 at 2:04 PM, Alex Zavatone <email@hidden> wrote:
> Well, let's put it this way; there are other things that need to be cleaned up - like 900 lines of code that are called on viewWillAppear in one class, 8 printed pages of warnings as well as a mix of XML, JSON and comma delimited data structures that are fetched ala http on startup.
>
> Looking at all the other cases of how stuff is put together in this app, I thought it safest to ask the people who have been doing this longer rather than just proceed along thinking everything's just fine with this approach.
>
> Ya, I've actually gone in and modified the XML before to reposition elements and wasn't sure I had the full grasp on how Xcode/Cocoa does it. I thought it might be relative to a base coordinate system and then at runtime, a 1.x multiplier might be applied to the plane that the controls are drawn upon. But, I never had the time to rip through it all and get to the bottom of it all.
>
> So, sweet. Thanks a bunch.
>
>
>
> On Mar 19, 2012, at 4:22 PM, Brian Lambert wrote:
>
> > Hi Alex,
> >
> > Regarding you having to "repair" code where "UI elements that have been hardcoded in place with the approach of: Just define the CGRect and we're all good." I think you're seeing things as being "gross" when they are not.
>
>
>
- Alex Zavatone
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden