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 protected]>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 protected] 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 protected]. > 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 protected] images are used in places of the > [email protected] 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 protected]> 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. >> >> > _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
