this is the code i have taken form.....
- (void)willPresentAlertView:(UIAlertView *)alertView
{
[[[alertView subviews] objectAtIndex:2] setBackgroundColor:[UIColor colorWithRed:0.5 green:0.0f blue:0.0f alpha:1.0f]];
}
- (void) presentSheet
{
UIAlertView *baseAlert = [[UIAlertView alloc]
initWithTitle:#"Alert" message:#"This alert allows the user to choose between a 'safe' and a 'deadly' choice, indicated by button color.\n\n\n\n"
delegate:self cancelButtonTitle:nil
otherButtonTitles:#"Deadly!", #"Safe", nil];
UITextField *txtFld = [[UITextField alloc] initWithFrame:CGRectMake(60,10,240,31)];
[txtFld setDelegate:self];
[txtFld setBackgroundColor:[UIColor clearColor]];
[baseAlert addSubView:txtFld];
[txtFld release];
[baseAlert show];
}
my question is If it is allowed to change the basic Look and feel of the apple's provided UIControls, because I dont see any reason that apple should not allow this type of customisation.
Alert views have long been standardized to for the same reason things like fire extinguishers and safety signs are standardized i.e. you don't want people to have to puzzle out a new interface while something is going wrong.
In general, it is a bad idea to change something in the interface that has been highly standardized. What benefit will it bring to the end user? Will they think, "Damn, I lost all my data but the alert that told me that sure did look artistic!" More likely, they won't understand that the dialog is actually an alert but rather part of the apps normal functioning.
Having said all that, there is nothing to stop you from creating your own custom view and presenting it modally. That is a far safer and easier route than mucking about under the hood of the Apple API.
I don't know if Apple will reject an app for accessing undocumented subviews, but they certainly recommend against it. In fact, when I was at the iPhone tech talk last week a developer evangelist specifically said not to do this because the implementations will change and your app will break.
Related
I was wondering how to create and customize a UIAlert View Popup, like ones in popular games such as Angry Birds or Cut the Rope.
I just want to say can you please rate my game and have 3 options to choose from. I want to design it so the text font and color changes and the background color can change to a picture or something? Thanks in Advance! :)
If your UIAlert is short enough to fit without the inherent scroll bar of longer text, then this will work:
UIAlertView *alert = [[UIAlertView alloc] initWithTitle:#"Title Here" message:#Message here..." delegate:self cancelButtonTitle:#"Okay" otherButtonTitles:nil];
((UILabel*)[[alert subviews] objectAtIndex:1]).textAlignment = UITextAlignmentLeft;
((UILabel*)[[alert subviews] objectAtIndex:1]).font = [UIFont systemFontOfSize:12];
[alert show];
You should try subclassing UIAlertView using this tutorial. Such UIAlertViews can be achieved with either a subclass of UIAlertView or by creating a separate view all together that simulates the look and feel of a UIAlertView.
I would like to add a bunch of UILabels or NSStrings to the UIALertView since I have run out of space on my display.
UIAlertView *alertDialog;
alertDialog = [[UIAlertView alloc]
initWithTitle:#"random" message:nil delegate:self cancelButtonTitle:#"Dismiss" otherButtonTitles: nil];
//firstString=[[UILabel alloc]initWithFrame: CGRectMake(12.0, 70.0, 260.0, 25.0)];
[alertDialog addSubview:firstString];
[alertDialog show];
[alertDialog release];
I can tell you from experience that this is a bad idea. In earlier version or iOS there were tricks using undocumented behavior, Apple made changes to the underlaying code and it all broke badly. Just create a UIView the way you like. If you want to dim the rest of the screen just place a semi-transparenr view over the screen and under your view.
You can use a alternative implementation of an alert view. One, that is not a subclass of UIAlertView — so it is absolutely independent to any changes Apple may release. And you have the possibility to add any subview as a clean property.
TSAlertView is such an alternative implementation.
you can use uitextfield to do so ,
simply change textcolor to while , and change background color to clearColor
I want to submit an iPhone application, and I am concerned about the following line of code which add an Image to the UIActionSheet Button:
UIActionSheet *actionSheet = [[UIActionSheet alloc] initWithTitle:#""
delegate:self
cancelButtonTitle:nil
destructiveButtonTitle:nil
otherButtonTitles:nil];
[actionSheet addButtonWithTitle:#"Button"];
[[[action valueForKey:#"_buttons"] objectAtIndex:0] setImage:[UIImage imageNamed:#"yourImage.png"] forState:UIControlStateNormal];
does that compromise any of apple app sumbition rules? is it legal? please tell me if so.
Thanks.
It is not legal, since _buttonsis not a public API.
(I would say however that it would pass Apple's review since you are using KVC and they have no way to know that this is a private call. Still, play safe and don't use it!)
I've been racking myself on this one for a while, and can't figure it out.
It is an action sheet that bookmarks a page (for a safari like app) When I hit Okay, i get the
-[UIThreePartButton text]: unrecognized selector at instance XXXX
I can't seem to step through where my pain is.
- (void)actionSheet:(UIActionSheet *)actionSheet clickedButtonAtIndex:(NSInteger)buttonIndex
{
if (buttonIndex == 0)
{
UIAlertView *alert=[[UIAlertView alloc] initWithTitle:#"Bookmarks" message:#"Please enter the site name: \n \n \n" delegate:self cancelButtonTitle:#"Cancel" otherButtonTitles:#"Ok", nil];
alert.center=CGPointMake(160, 50);
alert.tag=1;
UITextField *siteName=[[UITextField alloc]initWithFrame:CGRectMake(20, 70, 245, 30)];
siteName.backgroundColor=[UIColor clearColor];
siteName.borderStyle=UITextBorderStyleRoundedRect;
siteName.autocorrectionType=UITextAutocorrectionTypeNo;
siteName.delegate=self;
siteName.clearButtonMode=UITextFieldViewModeWhileEditing;
siteName.text=[[mainDelegate.sitesArray objectAtIndex:tag] objectForKey:#"webSite"];
siteName.returnKeyType=UIReturnKeyDone;
siteName.tag=2;
[alert addSubview:siteName];
[alert show];
}
}
I realized that it dies on the alert view method below it:
if(alertView.tag==1)
if (buttonIndex==1)
{
if(((UITextField*)[alertView.subviews objectAtIndex:4]).text==#""||((UITextField*)[alertView.subviews objectAtIndex:4]).text==nil)
{
Spefically on the if(((UITextField*)[alertView.subviews objectAtIndex:4])
I have 4 buttons/action on that action sheet, and the rest are good to go...
Do not try to manually traverse the view hierarchy of a UI element that Apple does not otherwise document. Doing something like [alertView.subviews objectAtIndex:4] is dangerous, because you end up having to make a blind assumption of the internal structure of a UIAlertView.
In this case, you're hitting the wrong element (a UIThreePartButton) and crashing your application with an exception. Even if you do get the index correct on where your text field is right now, there's no guarantee that Apple won't change the view number or ordering in a future OS release, suddenly causing all installations of your application to crash.
To prevent this, hold on to a reference to your UITextField so you don't need to probe the view hierarchy on a UIAlertView.
Even better, don't use an alert view for text input, but a custom modal view. Alerts really should be reserved for infrequent error displays or other critical updates. From the iOS Human Interface Guidelines:
The infrequency with which alerts
appear helps users take them
seriously. Be sure to minimize the
number of alerts your app displays and
ensure that each one offers critical
information and useful choices.
As an FYI, you're also leaking your siteName UITextField in the above code, and potentially your UIAlertView.
If you have 4 buttons per action would your objectAtIndex not be 3 instead of 4? Seems like you are getting an out of bounds exception.
Specifically objectAtIndex:4 will generate an exception if there are 4 items in the array since the last valid index is 3.
I have taken this code from
Changing the background color of a UIAlertView?
UIAlertView *theAlert = [[[UIAlertView alloc] initWithTitle:#"Atention"
message: #"YOUR MESSAGE HERE", nil)
delegate:nil cancelButtonTitle:#"OK" otherButtonTitles:nil] autorelease];
[theAlert show];
UILabel *theTitle = [theAlert valueForKey:#"_titleLabel"];
[theTitle setTextColor:[UIColor redColor]];
UILabel *theBody = [theAlert valueForKey:#"_bodyTextLabel"];
[theBody setTextColor:[UIColor blueColor]];
UIImage *theImage = [UIImage imageNamed:#"Background.png"];
theImage = [theImage stretchableImageWithLeftCapWidth:16 topCapHeight:16];
CGSize theSize = [theAlert frame].size;
UIGraphicsBeginImageContext(theSize);
[theImage drawInRect:CGRectMake(0, 0, theSize.width, theSize.height)];
theImage = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
[[theAlert layer] setContents:[theImage CGImage]];
orginally posted by oxigen.
I am not very sure should I use this code in my app. Will apple have any issues regarding this hack (will they reject the app?)
The underscores as prefixes of the properties you're accessing (_titleLabel, _bodyTextLabel) clearly indicate that these are private properties and should not be tinkered with. Apple has recently started scanning all submitted binaries for access to private methods and properties, and those values by themselves within your application should be enough to get you rejected. It is never a good idea to use private APIs, rejections or no, because they are typically private for a reason and may break your application with future OS updates.
Additionally, you are violating the iPhone Human Interface Guidelines by changing the alert color:
You can specify the text, the number
of buttons, and the button contents in
an alert, but you can’t customize the
background appearance of the alert
itself.
Again, from the iPhone Human Interface Guidelines:
Because users are accustomed to the
appearance and behavior of these
views, it’s important to use them
consistently and correctly in your
application.
Only Apple can answer that question. And they won't answer it until you submit it and wait approximately 2 weeks.
If you really want it in and have 2 weeks to kill, try to submit it. But it might get rejected at an update later.
Are you using any undocumented APIs here? If you are, assume it will get rejected. If you aren't but you are doing something different, then the only answer to your question which is correct is "I don't know".
If you want to know if some programming technique will result in rejection, make a small app with limited functionality and use your questionable technique in it.
It takes 2 weeks to get an answer but at least you won't invest a ton of time upfront.
If they approve your test app, delete it from the store. If it has genuine utility, set the price to $0.99 and leave it.
This method is not foolproof, but it is low cost.