I'm writing an iPhone app (which will be my first ios app) that has about 50 screens, each of which has the same background - where the background is an image covering the entire screen real estate and another image at the top as a banner.
Each screen will have some text along with 0, 1, 2 or 3 buttons appearing beneath the banner image.
What is the best design for putting this together?
The options I could think of were (in every each I was planning on having a root controller which is responsible for displaying each view as appropriate).
1) Have 50 separate screens as xibs (and associated view controllers), each of which contains the two background images plus however many buttons each particular screen needs.
2) Have 4 superclasses as xibs - (representing no buttons, 1 button, 2 button, 3 buttons) and have each of those contain the background images and as many buttons as appropriate. Then have 50 subclasses which simply just set the text and button content as appropriate using the superclasses instance variable outlets.
3) Have the root controller have a view which contains the two background images which is there permanently, and each of the 50 views displays its text and buttons on top of that.
4) (If this is possible, I need to check if a window can have images). Same as 3, except the root controller doesn't have a view, the main window displays the background images and each class displays its text and buttons on the top of this. So each view controller would have to load and display the text and button objects using code (in which case there's not much point to have xibs for them).
Is there another solution? Is one of these the "best" solution?
If I went with 3 would it not be possible to define the position text and buttons in a xib? (because in order to do so they would need a parent view in order to position them in interface builder, but if that were the case then when the view is drawn the background wouldn't be visible).
If 4 is possible, then the root controller has no view, therefore does it still need to be descended from UIViewController, or could it simply be descended from NSObject?
I think at the moment I am leaning towards option 2) as that way I can design all the views visually as xibs, but there are only 4 of them. Unless there is a better more elegant solution.
TIA
What you can do, is one XIB with all the buttons and then you would set then hidden accordingly. Although it would tie you up a bit. The 2) option is more flexible. The 3) is ok too. You could have one rootViewController, just to hold the images and then you could something like this:
[rootViewController.spaceForMyChildView addSubview: myNewViewController.view];
The "spaceForMyChildView" would be a view that would hold your child views.
I would do fusion between 2) and 3) probably.
UIWindow inherits from UIView, so can have anything within it. So (4) is feasible, though you're starting to get into tricky water if you want to support any sort of view rotation.
I'd think an inverted (2) would be the easiest thing — have a single superclass that upon viewDidLoad adds the background and top banner programmatically. Have your specific controllers inherit from that and design them graphically to contain whatever you want, mindful that the image and banner will subsequently be added.
That said, if your views are really as simple as a single text area and up to three buttons, always with fixed positions, then it sounds like a single view that repopulates its fields from a data source, as Jacky Boy suggests, is probably the smartest thing.
Related
All my views/pages in apps so far have been full screen UIViewControllers that i push and pop from the stack.
I see some apps create a new view/window that appears about the 1/3 the size of the full screen on an iPad, containing tables of items to select or other UI elements. They are commonly used to allow users to filter the current view they were on.
Seeing them in apps, I guess that they are just adding a UIView to there current screen and change its frame depending on where on the screen they want it to appear.
Or am I wrong? Is there another/better way to do this?
I guess you are talking about UIPopovercontroller. There are several tutorials to build the same.check this. Hope that helps you.
It's a little unclear from your question what the view looks like.
If the view is "attached" to a UI element (has a little triangular arrow connecting it to, e.g., a button) and goes away if you tap outside it, then it's a view presented from a UIPopoverController.
If the view overlays everything and dims the content behind it, is likely a model view controller presented with a presentation style of ether page sheet or form sheet.
Both are common and easy to set up. See the class documentation I have linked.
In most cases, these are probably normal modal view controllers whose modalPresentationStyle property is set to either UIModalPresentationPageSheet or UIModalPresentationFormSheet.
Yes you can make your own UIViews and just add them as subviews. Another option for iPads specifically is with the UIPopoverController class.
I have designed a custom tabbar and the developer says the design I created can't be done.
The screen is made up of a usual background with a tabbar. I'd like my tabbar to look a little different to the usual iPhone style. I would like at the bottom of the tabbar a grass illustration (transparent) and on top would sit all the separate buttons and on top of those would be the icons. All of these images (as seen in link below) are separate .png files.
When the user scrolls the content, it will scroll under the transparent grass. The buttons of course will be clickable and have a different view for an active state.
Please see the link below to see a mock-up of the image:
http://www.stuartkidd.com/dummy.jpg
I'd appreciate if the community could explain to me if this could be done and if so, how. I thought it would have something to do with 'creating a custom tabbar'.
And a further question, if it can be done, can also the tab buttons be horizontally
scrollable with a swipe action?
Thanks,
It all can be done but you are going against the Iphone UI guidelines. You won't be able to leverage the UITabbarView to do what you want so you'll basically have to write the whole thing from scratch. Your tab bar would be a scroll view with a row of buttons representing each tab. When a button is clicked you load in the appropriate view. The UITabBar controller gives you a lot of functionality for free and I suspect once you start working towards this you'll see exactly how much extra work this will end up costing you. Going against the way Apple does things can be a slippery slope.
Another idea might be to keep a hidden UITabBar to manage the tabs and call it from your custom tab bar. This would free you from a lot of the hassle of swapping views/controllers in and out.
You can create a row of custom buttons and have 2 subviews. One for the bottom navigation bar and one for the content view where you will be swapping your content based on what is pressed.
You can have a state which maintains what was clicked. Based on that you can set the button enabled state for every button in your bottom bar.
button.selected = YES
It will be easy to handle the touch up inside events and properly load appropriate views in and out of the bigger subview as they will be part of the same view controller.
I have implemented a similar functionality and it works well but still in process of submitting it to the app-store.
Need help with the following. I am creating two different combinations of view/controllers that allow me to add/edit a set of information , think tasks or some type of to-do. I have all the data capture/store functionality working.
I decided that it would be nice to have an icon associated to these tasks. So the icon would show up in the UITableview. I commissioned 18 customer 44x44 icons that would be added tot he table.
But there is where I'm stuck:
I was to add/edit views to have the capability to select an icon to attach to the tasks. In order to do so, i added a 44x44 round-rect button with one of the images as a default. I wanted to have that button trigger another view with the 18 icons so the user selects one and it passes control back to the main view and updates de selected icon appropriately.
I created this little 18 icon view together with the main view, which is based on a scroll view. I configured the little icon view to be hidden.
But I have no idea if the little view should be a subview of the main view, who should be the file owner, how do I make it appear hidden as the main view is displayed and toggle t as needed...
I am stumped. Anyone done something like this? Ideas? Things I completely messing up, you can think of?
Thanks in advance
Probably the easiest way to hide and show the view is to adjust the "alpha" property on the view. If you set the alpha of the little view to 0 it will be hidden, and when you set it to 1 it will be showing. So in your awakeFromNib function (or wherever you are doing initialization) you can add the littleView and set the alpha to 0 so it starts hidden. I suggest adding the littleview to your mainview unless for some reason the little view will have any part of it outside of the mainview. Then, when the user selects the icon to change it, you can set the alpha to 1. Finally, when the user chooses from the view, you would set the alpha back to 0.
Note:
This is not the most efficient use of memory because the view is technically always around. So if you think that you will be low on memory I would suggest creating the view programmatically when needed and removing it from mainview when the user is done. (But only do this if you think it will be an uncommon task because creating the view with a bunch of images will probably be a relatively expensive operation).
I am working on a project when client wants UITabBar lookalike toolbar (icons and titles) at the bottom of some views.
The tab bar needs to have 1 item at the left, empty space, and then 2 items at the right.
Do I have to use 2 extra UITabBarItems (and put them at second and third position) and hide and disable them to accomplish this, or is there a more straightforward solution?
I would like to not to use UIToolBar for this as customizing its height is a pain and causes unexpected behavior in some cases (especially when one uses modal view controllers).
I think you have the right idea. Customizing UITabBar to do stuff out of the ordinary is often quite hard and it is better to just write your own. But in your case you should be able to just as you proposed. One way would be to add the view controllers directly in IB and then set title to an empty string and untick enabled for the second and third view controller.
I have an idea about an application that I want to build and Im new to iPhone/iPad development (but not new to development in other languages/frameworks such as .NET and Java). I want to layout some views on the screen so that they animate (slide in) from different directions into their places.
The question is about the strucuture of the application, if I have say 4 rectanglular areas on the screen that contain business data, such as contacts (name, photo, etc...) and they all take up different widths of the screen (say the first contact takes up one row of the screen, but the next 2 take up half the width of the next row each, and so on).
Should I create a custom view for the different sized contact views, (i.e. LargeCustomView and SmallCustomView, and any other special type that I make) or should it all be one type, say, CustomerDetailsView which could be stretched to fit at design time?
Also, if there were, say, 3 different instances of the same custom view on the one screen, are there 3 instances of the view controller also? Im a little confused about powering the data behind a view, can someone shed some light on this for me? Do I just set the properties (say an instance variable ContactForView) on the view controller for each instance?
Thanks for any help you can give
Cheers,
Mark
Should I create a custom view for the different sized contact views, (i.e. LargeCustomView and SmallCustomView, and any other special type that I make) or should it all be one type, say, CustomerDetailsView which could be stretched to fit at design time?
I think only you can answer that question. If UIView autoresizing masks are enough to accomondate both layouts, you should probably go for just one class. If that's not enough, you can either override layoutSubviews to account for different sizes or perhaps go with a common superclass to contain the logic and two subclasses to do the different layouts.
Also, if there were, say, 3 different instances of the same custom view on the one screen, are there 3 instances of the view controller also?
Because of the way UIViewControllers work, Apple generally recommends not having more than one view controller per screen. From the docs:
You should not use view controllers to manage views that fill only a part of their window—that is, only part of the area defined by the application content rectangle. If you want to have an interface composed of several smaller views, embed them all in a single root view and manage that view with your view controller.
Otherwise, things like device rotation can get tricky as a view controller that is not full screen should probably react differently to such events and Apple's UIViewController is not written to do that. However, nobody stops you from writing your own view controllers (derived from NSObject, not from UIViewController) so that's what I would recommend: if the view is quite complex, write a custom controller class for it but stick to one UIViewController per screen.