I really need some help, since iOS 7 I have had nothing but trouble with UISwitch.
The Problem
After moving the view up when the keyboard is displayed and restoring it to original position, I then turn any UISwitch on/off it will work OK, however it will "Bounce Down" during the animation. this only seems to happen to UISwitch's that have the .thumbTintColor attribute. by that I mean self.borders.thumbTintColor = [UIColor redColor]; when the switch is off and self.borders.thumbTintColor = [UIColor greenColor]; when switch is on.
For clarity everything works well until the moving of the view (I can't not do this as you are not able to see the text field).
I have searched everywhere (including the class reference) and I haven't found anything helpful, or anyone else with this problem.
UPDATE
I have tried setting the UISwitch thumTintColor various ways, everything works fine until I move the view up to compensate for the Keyboard. if I drag the switch either on my iPad or via simulator on and off slowly the "bounce down" occurs halfway and when the color changes from green to red or red to green depending on state, I think this is an actual IOS7 UISwitch Bug. I really do not want to use a third part switch plug in on my app, so not sure what to do now, one would of thought that changing the tint color on the thumb would not have been such a huge problem.
I have tried turning off the animation from on to off - off to on makes no difference.
I have created a new UISwitch via code not IB and the same problem exists.
created a new test app with only a switch and text box to test and the same thing occurs.
Questions
1) My thoughts are this is a genuine bug. How do i log it with apple (never done it before) so if someone can point me to the correct place i would be grateful.
2) I am now thinking of using Buttons as switches, but feel that is not the way to go, are there any practical reasons not to do so i.e problems submitting the app to the App store etc?
I had the similar issue and found a solution. It's a bit hacky but it does the job.
Just need to add a small delay between setting isOn property to On/Off and changing the color of the thumb.
switch.isOn = true
DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) {
self.switch.thumbTintColor = .white
}
Answer 1: Logging a bug with apple can be done via the iOS Dev center (There's a link on the bottom of the page). You can also ask for technical support. Click on the "Developer Support Center" button, then go to "Technical Support (TSI)" (Please note you only have a limited amount that you're allowed to use per year, before you have to buy more).
Answer 2: I think that having two buttons would be a very bad User Interface decision. Apple may reject it because of that (but you never know). I would get the bug report in, and go from there.
Good Luck!
I found interesting solution may be it helps.
NSArray *array = [self.mySwitch subviewsWithClass:[UIImageView class]];
for (UIImageView *imageView in array) {
imageView.image = [UIImage imageNamed:#"Untitled-1.png"];
}
Hear I used method from UIView category
- (NSArray*)subviewsWithClass:(Class)class
{
NSMutableArray *array = [NSMutableArray array];
if ([self isKindOfClass:class]) {
[array addObject:self];
}
for (UIView *subview in self.subviews) {
[array addObjectsFromArray:[subview subviewsWithClass:class]];
}
return array;
}
Image size is {57, 43.5}. Circle radius is 15(with shadow)
I understand that it is not very good way to solve. But if you really need it helps.
Play with images little bit =)
Related
I have a LaunchScreen.storyboard which serves as the launch screen file. In this storyboard is a view controller with the class LaunchViewController.
In my LaunchViewController.m file I changed the view's background color and added a label with the FB shimmering effect (https://github.com/facebook/Shimmer).
_shimmeringView = [[FBShimmeringView alloc] init];
_shimmeringView.shimmering = YES;
_shimmeringView.shimmeringBeginFadeDuration = 0.3;
_shimmeringView.shimmeringOpacity = 0.3;
[self.view addSubview:_shimmeringView];
_logoLabel = [[UILabel alloc] initWithFrame:_shimmeringView.bounds];
_logoLabel.text = #"Shimmer";
_logoLabel.font = [UIFont fontWithName:#"HelveticaNeue-UltraLight" size:60.0];
_logoLabel.textColor = [UIColor whiteColor];
_logoLabel.textAlignment = NSTextAlignmentCenter;
_logoLabel.backgroundColor = [UIColor clearColor];
_shimmeringView.contentView = _logoLabel;
But when I ran it there's only an empty white background displayed as the launch screen. Also I find that he LaunchViewController looks fine when used as a regular view controller. How to make it display the same effect when used as launch screen?
You can't use code inside a launch view controller nib. Whether it is a storyboard or a separate nib. The code is not executed. The only thing that works is what is in InterfaceBuilder like auto layout and stuff. No code is loaded. This would defeat the purpose of using a launch file. The launcfile is loaded before the app has had chance to load.
No app, no code. Only the launch file.
I've had similar problems, and based on your code, it may be similar to mine. First off, I don't understand your question as much as I would like to. You said, "The LaunchViewController works fine when not used as launch screen." Does that mean that it looks the way you want it to look like when viewing on Xcode, but not on the simulator? I will try to provide possible solutions, and some trouble-shooting tips.
It could be something as simple as your background(or something) is at the front of the screen, blocking the rest. If so, you have to reconfigure the order of your items on your launch screen in your xib file in your application.
It could be an error on your part. Some of my programmer friends develop their launch screens using the Xcode interface: I find that easier to use, and it may have less errors.
It could be an issue with the iOS simulator. This is not likely to be true, but it could be. Try running the app on your device and see if it is fine there.
Troubleshooting: In order to trouble shoot your code, comment out your code, and load in all the elements of your launch screen one at a time, checking the iOS simulator and the console in between. You will eventually find the problematic code, and be able to fix it. From looking at your code, I don't see anything wrong (but don't take my word on it, I'm not familiar with coding the launchscreen/storyboard in swift. Good luck, and I hope my tips work. Also, if your launch screen is appearing fine inside Xcode, it is a programming error or an error on the iOS simulator. A picture or a description of your launch screen could also help future people who will answer this question.
Here is my very simple code for creating a UITextView.
UITextView *textView = [[UITextView alloc] initWithFrame:self.view.bounds];
textView.editable = NO;
textView.text = #"Using iOS 3.0 and later, VoiceOver is available to help users with visual impairments use their iOS-based devices. The UI Accessibility programming interface, introduced in iOS 3.0, helps developers make their applications accessible to VoiceOver users. Briefly, VoiceOver describes an application’s user interface and helps users navigate through the application’s views and controls, using speech and sound. Users familiar with VoiceOver in Mac OS X can leverage their experience to help them quickly come up to speed using VoiceOver on their devices.";
[self.view addSubview:textView];
Given that I could not possibly do anything wrong here I am just wondering if this is an expected behaviour or a bug perhaps somebody also faced:
With voiceover enabled I expect the entire text view to be “highlighted” on tap, then its accessibilityLabel to be read to a user and after they double tap, the entire text view’s text to be read.
But what is happening is that a small portion of the text view is highlighted (usually 2 lines), accessibilityLabel is not read, but the first “highlighted" line and the first letter (!) of the second line are read instead and only after a user double taps the entire text is read.
Especially reading the first letter in the second highlighted line confuses me. Plus shouldn’t accessibilityLabel be always read in the beginning?
This looks like a big to me but Apple has always paid so much attention to accessibility, so I’m having doubts if I should report it, may be the meant it to be this way.
Another question: is there a way to achieve the following behaviour (without subleasing UITextView) when voiceover is enabled: user taps UITextView -> accessibilityLabel and the entire text are read?
In case someone else has this problem here is the answer:
textView.accessibilityTraits = UIAccessibilityTraitStaticText;
Combining the other two answers from this post has the desired effect. i.e.
textView.isAccessibilityElement = true
textView.accessibilityTraits = .staticText
Also if you are setting the attributedText property on the UITextView make sure you DO NOT set the accessibilityLabel (on the UITextView). Doing so will cause VoiceOver (Xcode 12.5, iOS 14.4.2) to read the text twice.
textView.isAccessibilityElement = true
This Works
I've worked with Xcode and iOS on a few personal projects and have always used non-object-oriented designs for everything... just because I've been doing mostly learning/experimenting with things.
Now I've been trying to implement some object oriented design into one game I've made previously. The idea is, I have a space ship that can shoot bullets. In the past I basically added the UIImageView to the storyboard and then connected it to the .h file and from there did things on it like move it around or whatever (using CGPointMake).
The idea now is to make a method (and a whole other class soon) that will create a UIImageView programmatically, allocate it, add it to the superview etc... I've got this working so far, easy stuff, but the next part is a bit harder. Where do I store this local variable "bullet"? I've been saving it to an NSMutableArray and doing the following:
(actually here are the methods that I have)
-(void)movement {
for (int i = 0; i < [array1 count]; i ++) {
UIImageView *a = [array1 objectAtIndex:i];
a.center = CGPointMake(a.center.x + 2, a.center.y);
if (a.center.x > 500) {
[array1 removeObjectAtIndex:i];
[a removeFromSuperview];
}
}
}
-(void)getBullet {
UIImageView *bullet = [[UIImageView alloc] initWithFrame:CGRectMake(ship.center.x + 20, ship.center.y - 2, 15, 3)];
bullet.image = [UIImage imageNamed:#"bullet2.png"];
bullet.hidden = NO;
[self.view addSubview:bullet];
[array1 addObject:bullet];
}
(by the way, array1 is declared in the .h file)
and theres a timer that controls the movement method
timer = [NSTimer scheduledTimerWithTimeInterval:0.5 target:self selector:#selector(movement) userInfo:nil repeats:YES];
first question is: what is the correct way of doing this? Storing a bullet for example until it is removed from the superview, should I store it another way?
and another question is, when I remove a UIImageView from the superview, does that remove it from memory so its not using up system resources?
Thank you for the help!
(will update if I Think of other questions
UPDATE
I would like to point out that currently this is not functioning correctly. When I click on a "shoot" button that I have created (which basically calls the getBullet method) the bullet appears but does not move.. not sure why. This is part of why I'm asking this question as well.
I offer you a totally different solution. Instead of using the built in UIKit to perform graphics calculation and move things around the screen, try using an external framework other than UIKit. The UIKit framework is really good at its intended job, which is more oriented around a touch based user interface than game development. The following is pulled from the UIKit documentation from Apple.The UIKit framework provides the classes needed to construct and manage an application’s user interface for iOS. It provides an application object, event handling, drawing model, windows, views, and controls specifically designed for a touch screen interface.As you can see, UIKit was made for the purposes of slick user interfaces, not animating sprites (spaceships, bullets) around the screen.
The best alternative is to look down another path. The first thing to go to would be SpriteKit. Made by Apple and already included in Xcode, SpriteKit is the perfect tool for your job. Made specifically for game development, it has the ability to seamlessly animate many sprites on screen at a time (bullets in your case) and has a built in physics engine. It is very easy to learn, and has the potential to turn you idea into a great game.
The link to the SpriteKit documentation can be found here.
I am using a UISwitch to call a subview to screen in my app. However, the switch only works about 60% of the time. To test my code I hooked the switch to another IBAction to write the state of the switch to the console. Both functions are not responding to the state of the switch at certain times, i.e., both functions are ignoring the state of the switch simultaneously some of the time. Has anybody else experienced this behaviour with UISwitches in iOS7?
- (IBAction)showHideSomeSubView:(UISwitch *)sender {
if (_mySwitch.on) {
[self.view addSubview:someSubView];
}
else {
[someSubVew removeFromSuperview];
}}
Edit:
The same switch is connected to the following action:
- (IBAction)switchToggled:(UISwitch *)sender {
sender = _mySwitch;
if ([sender isOn]) {
NSLog(#"On");
} else {
NSLog(#"Off");
}}
Both actions respond in the same way to the switch.
I confirm that weird behaviour with you!!!!
Just drag the little circle of the switch around and around, you will see the action called multiple times (in my case up to 403 :D )
I am really not sure that is what Apple engineers intended to do, because I have not found any documentation about this new behaviour, BTW, if you find one, please let me know too.
Thank you very much
I'm using several UISwitches in an iOS 7 app, I have had no problem at all responding to the Value Changed action. The switch consistently reports its value correctly. You should unhook the switch from its action in IB and then reconnect, making sure you are connecting the Value Changed action.
Yes, with a UISwitch in the iOS 7 iPad simulator, I am seeing 1-12 callbacks to my equivalent of your switchToggled: method. On the last callback, the value has in fact changed. On the previous callbacks, it hasn't. What I am doing is caching whether or not the switch is on. Then in the switchToggled: method, I check whether or not the value has in fact changed. If it hasn't, I ignore the callback. This seems to make things behave correctly for the user.
The problem does also happen on the device, though apparently less often. The same work-around seems to work there.
I want to start by saying that i would post this question on the Apple Dev Forums but because of the hacking attempt fiasco , or whatever that was, the forum has been offline for almost 2 weeks now and i need a solution for this as soon as possible.
In iOS 7 the UIDatePicker looks like this :
and a client asked to look like this :
(basically inverted).
I've tried a few things:
Setting the background to black and looping through all the view's subviews until i reach the labels that show the date itself and change their color to white. The problem is that The view has only one subview, and that subview doesn't have any subviews of it's own. So this solution doesn't work. (it did in ios6).
Applying a filter to the view's CALayer. The thing is that this is only possible on OS X not on iOS, for some unknown reason.
Playing with UIApperance protocol. From what i've read this should work but what i've tried didn't and i don't have extensive experience with this to figure out why not.
Any ideas what i can try? Is this even possible? Did i made a mistake in my approach of the problem?
Try this out :
Put this code in -(void)viewDidLoad
[datePicker setValue:[UIColor whiteColor] forKey:#"textColor"];
Swift:
datePicker.setValue(UIColor.white, forKey: "textColor")
Don't know if this is still relevant but on Swift 3 / Xcode 8 you can simply do this:
let datePicker = UIDatePicker()
datePicker.datePickerMode = UIDatePickerMode.date
// Sets the text color
datePicker.setValue(UIColor.white, forKey: "textColor")
// Sets the bg color
datePicker.backgroundColor = UIColor.black.withAlphaComponent(0.6)
textField.inputView = datePicker
I spent quite a bit of time struggling with the same problem. At first, I've put a UIDatePicker on a black background and was wondering why it is invisible...
I ended up placing a white UIView as a background for the date picker, so while the whole view is black, the date picker is white. It actually looks okay, although thankfully I don't have a client who would dictate the design.
One possible argument for a client: the old, pre-iOS7 date picker, also had a predefined non-customisable background.
What you want is possible, but it will be called Custom Date Picker.
Below is the link where you will find what you wanted.
https://www.cocoacontrols.com/controls/simpledatepicker
If you need more, take a loot at below link.
https://www.cocoacontrols.com/search?utf8=%E2%9C%93&q=datepicker
Well I understand your frustration, but iOS7 is under NDA. Usually this kind of views are made using layers, beacuse of sublayerTransform that can make perspective giving the idea of 3D. I would check sublayers if you don't see subviews.
The other poin is that I would not hack too much views/layers hierachy, ios<=6 to ios7 transition shown that hacking isn't a good idea.
UIAppereance protocol is probably the way to go, becauase it makes you change what you can change (without screwing that in the future), maybe you can set a backgroundImage, try to set a 1x1pixel of a blck color png, you should also see an attributed string property, or text property.
I dont think its possible to do that directly by changing the properties of the default UIDatePicker , although you can use custom controls to do it.
This might help,
MWDatePicker - https://github.com/mwermuth/MWDatePicker (Found it in cocoa controls -https://www.cocoacontrols.com/controls/mwdatepicker)
according to the iOS Design Resources:
You cannot customize the appearance of date pickers.
I would suggest one of the below:
Redesign your UI to use the black text
Use a customer datepicker
You should tell your client that his suggestion is against the design principles of iOS 7, which indeed it is. I am not a great fan of iOS 7 myself, but we should all give it a go. Your client should accept the standard iOS 7 UI provisionally, until he is in a position to make an informed judgement. Designing an app based on his initial impressions is a recipe for disaster.