I want to move a UIAlertView's frame because I am adding a UITextFied to it and when the keypad is hiding the Cancel and Ok buttons that are apart of my alertView
Do you just want to move the entire alertview around or move the views inside the button around? If the former, UIAlertViews are a UIView subclass. Just use the .frame property.
If its the latter, I would recommend against doing so. Instead, I'd probably suggest a modal view of some sorts. And to file a radar with Apple about making this possible.
Basically, you'd have to subclass UIAlertView to change the view itself. However, it needs pointing out that UIAlertViews are very fragile (the buttons in the view are a private class and, IIRC, the internals have been changed around before).
But if you must, as it stands right now, you're going to need to use a hack. UIAlertView is a UIView subclass and that you can iterate through the subviews as needed. There are only going to be three kinds of views in your view—and two kinds of views (message and title labels, textfields you add in) are public classes that you can check against with - isKindOfClass:.
Alternately, there's also "Make the alert have a message that takes up two lines and add the alertview in so that it covers that subview" at the expense of having a mssage in the alert. Just as hacky, in a different way.
Related
I want to add more than 8 buttons in UIAlertView but when I am adding buttons, they are covering each other and not scrolling. The title is also hiding.
How can I resolve this and add some scrolling in the alertview ??
Seems like this kind of question comes up at least once a day on StackOverflow, but if you want to mess around with the various components within a UIAlertView, the short answer is: DON'T.
If you look at Apple's documentation for UIAlertView, within the first screenful of text it states:
Subclassing Notes
The UIAlertView class is intended to be used as-is and does not
support subclassing. The view hierarchy for this class is private and
must not be modified.
This means that there's a decent chance that any mucking around within UIAlertView hierarchy could catastrophically break your app in future iOS release.
So if you want to add scroll bars or bells & whistles, you really should create your own custom UIView (which looks like a UIAlertView, but is wholly of your own creation)
If you have more buttons then UIActionSheet is the best option than using UIAlertView. If you dont want to use UIActionSheet there is always a custom View to your rescue!
You should really rethink your UI if you need more that 8 button in a UIAlertView. 8 button is the maximum the standard alert view can handle.
Either build your own alert view or use a normal view controller with a table view.
Not sure if it's necessary but as an alternative, you can present another ViewController/ModalVC that will have all the attributes that you may require....
Just move ahead with CustomView, Otherwise not possible with UIAlertView to meet up with your requirement :
Reference links :
http://iphonedevelopment.blogspot.in/2010/05/custom-alert-views.html
http://iosdevtricks.blogspot.in/2013/04/creating-custom-alert-view-for-iphone.html
https://stackoverflow.com/a/6965828/434898
If you want to add many buttons you can use a custom implementation for the alertView.
A nice example is FUIAlertView
Or you could use WEpopover and add to it a table view.
I do understand how to go about making the UIKeyboard push up the UIView if the active UITextView is blocked by the UIKeyboard as per this question: How to make a UITextField move up when keyboard is present?.
What I'm wondering is, from a design perspective, how do you go about implementing the keyboardDidShow and keyboardDidHide methods so that all of the views in your app, whether they be a UIView, UITableView, or UIScrollView all have this functionality and so you need to implement these methods only once?
The only way I could think of would be to have the view property of the UIViewController always set to a UIView, and if you have a UIViewController that needs a UIScrollView or UITableView, just attach it as a subview to this. Then if the UITextView is being blocked, just move the parent UIView up so it will move all of the views that are attached to it.
Does this sound like a good plan, or is it even worth it? Anyone else have any other ideas?
This is a little old, but it's a great article about using firstResponder methods to tell views to slide up. I, personally, like to put my UITextField in a parent container and move it all up. However, I do NOT suggest putting everything in there and moving it all up, because the UITextField "feels" better just above the keyboard. But I do like the background or certain items to move up with the UITextField.
See below: http://cocoawithlove.com/2008/10/sliding-uitextfields-around-to-avoid.html
This is a nice implementation that moves the field up based on the section of the screen it's in (upper, middle, lower). Works very well. May need to be updated for newest SDK, but should be pretty easy.
In experimenting with this, I noticed that if you want to make a BaseViewController that implements this functionality to work for everything that inherits from it, you have to attach another view on top of the UIViewController's view property in order to get it to work. Reason is, if you push the UIViewController's view property up when the keyboard appears, then it resets itself if the app comes back from being active and it's messy.
The problem with this however, is now in all of your child classes you have to attach your subviews to this new view property instead of the regular view property. Also, you probably have to make a custom UITableViewController which will inherit from your BaseViewController class so it can inherit the keyboard notification methods.
Ultimately, I've found it's not the worst idea to have another view on top of the UIViewController's property for a bunch of different scenarios. Making a custom UITableViewController isn't that big of a deal either. So if you have a lot of text fields in your app, this might not be the worst way to go.
I want to make a small area to present some information in the middle of a UIToolbar and was wondering what the best way to do this is.
I need to show some text and a graphic, both of which need to be updated (around every 3 seconds) as new information arrives. The graphic is similar to the iPhone signal strength indicator, so it can be either custom drawn or selected from one of 3 graphics (low, medium, high strength).
I'll probably use initWithCustomView: to create a UIBarButtonItem, although I would like the view to be clickable (to allow the user to change the information shown).
What's the best way to make that view? Can I use a NIB, or do I need to do custom drawing in the view? What's the best way to update the buttons? I'm assuming that I'll have to remake the toolbarItems array each time and set it when the information changes. Is there a cleaner way to do this? Thanks.
Using initWithCustomView: sounds like a good way to go. You can create your custom view any way you want: with a NIB, by drawing it, even using images. It can also have its own subviews. It can be any object that inherits from UIView. (So, if you wanted, you could even make it actionable by using a UIButton, a custom UIControl, or a custom UIView with a gesture recognizer attached.)
You shouldn't have to remake toolbarItems (or, for that matter, do anything with it after you've added all your button items) if you just keep a pointer to your custom view UIBarButtonItem. It could be an instance variable. Then, to update the custom view, you could access it as you would any other view. I've never actually tried this, but I can't see any problem with doing it.
You sound like you had it mostly figured out. Hope this is helpful.
I needed the same solution and was hoping for some code examples from you. So I ended up doing it all in IB and the steps are here as follows:
Create UItoolbar in IB with no Items. (A Bar Button Item will be added again once you add the UIView)
Add UIView as subview of UIToolbar
Add UILabels to subview of UIView that is already a subview of the UIToolbar.
Create IBOutlets from UIToolbar, UIView and each UILabel and then you can reference the labels in your app.
I did set the backgrounds to clearColor so the text appears on top of UIToolbar without any box or borders.
And the text updates dynamically which was the desired outcome.
Hope this helps someone as this has been eluding me for a while.
Is it possible?
I have a UINavigationBar that I'd like to have an 'edit' button next to the 'back' button. From what I've read you can only have one or the other, which makes no sense as they are separate properties of the navigationItem object(backBarButtonItem and leftBarButtonItem).
I'm assuming you have to somehow insert a custom UIView into the UINavigationBar. I'm looking into this option and if no better solution is given then I'll outline this method.
The short answer is:
Yes, you have to add your own UIButton views (or other UIControl subclasses) to the navigation controller, yourself. So, ignore the custom *ButtonItem properties and roll it yourself.
A little more involved answer is:
Apple makes it very easy to follow their HIG guidelines, but you're on your own if you want to break them or customize. In this case, only one button is allowed, because the actual hit region is bigger than the size of the displayed button--much easier to hit from a usability standpoint.
Extraneous:
btw, there is a subtle distinction between left/rightBarButtonItem and backBarButtonItem. left/right is specified on the current UIViewController. However back is specified by the previous UIViewController.
Using a custom view is indeed your only option here. The UINavigationBar is not terribly flexible. What you will need to do is create a UIView that contains UIButtons. Be sure you realize that if you use a custom view, you gain none of the automatic behaviors of the backBarButtonItem; you have to create your own IBActions, and the graphics for the buttons as well.
On a related note, I'm not sure this is the best idea. It's usually wise to stick to Apple's UI guidelines; is there no where else you can put the edit button? The right side of the bar, for example?
While #Kelvin's answer works for pre iOS 5, if you're using iOS 5+ there is now a leftBarButtonItems array property. Note that you also must set leftItemsSupplementBackButton to true.
alt text http://www.davidhomes.net/question.gif
I'm farily new to iphone dev (<3 months on my free time) and I'm starting development of my second app.
From the image, I'm adding a number of UIViews as subviews to my main UIViewController.view, the number of Views to add varies based on user selectable data.
Each view contains several controls, a label, a UITextField and a Horizontal UIViewPicker.
For simplicity I put a (VERY ROUGH) mock-up here with only two buttons.
Because I want to improve the GUI, I want to overlay an UIViewImage as the top sub-views of the added UIView, something like in the image.
The question is on passing through the events to the objects below it. I've read somewhere that one way was to use clipping, but the actual shape is more complex than just an oval frame.
Somewhere else I read that one could add four UIImages, one at each border, which would let the events pass through this hole. Seems like a dirty solution to me (Although I'm sure it would work)
Any ideas about the best way to do this? Any links to a tutorial or recipe online?
Your help is appreciated
thanks
david
Have you looked at protocols? You can define protocols for your views or objects, and the users of that object (the subviews underneath for example) can implement the protocol, set itself as the objects delegate and when actions happen they will notified through the protocols. So for example
An AboveView will declare a protocol that declares methods when a certain gesture was senced by that view so something like
-(void)didMakeCircleGesture...
as a property the underneathview will have a delegate, so in your method that actually sence the gesture youll have at the end something like
[delegate didMakeCircleGesture];
in turn the delegate is the view underneath or something, and it will conform to the protocol defined by the AboveView, and as part of it it will have to declare the method didMakeCircleGesture, so as a result when one makes a circle gesture in the AboveView the underneath view that conformed to the protocol will be told of the event and it can take appropriate action