Am using Xcode 8.1 with cocos2D V3 for developing a board game.
The game runs in the Landscape mode, which is set in the AppDelegate.m,
[startUpOptions setObject:CCScreenOrientationLandscape forKey:CCSetupScreenOrientation];
In the Deployment Info, (under 'General' tab), I had checked only the 'LandscapeLeft' and 'LandscapeRight' checkboxes. But while validating the Archive, it threw an error, : for iPad, all the orientations need to be checked.
Now the problem happens when I check the 'Portrait' checkbox. The game starts to run erroneously. An in-game timer does not run, (the update callback does not get called), a few animations do not run/get stuck. All this happens while the 'Portrait' checkbox is checked.
Any idea why this would be happening? Again, I might have overlooked / made a mistake somewhere? (Please see image)
Help Much appreciated !!!
Well strange as it may seem, the issue was this :
I had a small mistake in a function call in AppDelegate.m
- (void)applicationDidResignActive:(UIApplication *)application {
[[GameStats sharedGameObject] saveData];
}
while the method call should have been applicationWillResignActive ..
This spell mistake in the function call never threw a compiler error, and I had been testing on Simulators.
This solved the matter. Strange but clueless as to what went wrong under the hood ! !
Related
Ok, have no idea what is going on here but from what I understand from other questions
(XPC connection interrupted in Xcode 7 for iOS 9) , XPC connection interrupted means theres a storyboard problem. Per a similar answer I opened the storyboard as source code and looked for repeated
<keycommand>
tags, but there aren't any. I had to copy and paste a storyboard from another project since something changed, and I believe this caused it. What are my options here? What could be causing this freeze since there aren't any weird tags that I can see?
Same problem, getting the XPC error when tapping in a (SwiftUI) Text Field. Different solution:
Simulator > Device > Erase All Content and Settings
As described here,
The problem came from the keyboard that wasn't showing up. And I am not really sure why, I probably pressed a command that disables it.
To get it to work I have restarted the simulator. In the simulator menu, Hardware > Erase All Content And Settings
Now when I tap in a UITextField, the keyboard shows up and I don't get the "XPC connection interrupted" error anymore. Everything works fine.
This error was incredibly frustrating because there is no crash report, just a one-line "XPC connection interrupted" and the app freezes. And, to complicate things, it's apparently possible to get this error from some wildly differing causes -- various discussions have cases of VPN's, Bluetooth, and threading generating this. And of course -- Murphy's law -- I started getting the error after having implemented something utterly unrelated, but which has me troubleshooting threading & Core Data issues, all to no avail.
Hopefully this can help somebody else with the quick fix.
The problem for me was that there are two storyboards, the main storyboard and the launchScreen storyboard. If you go to the top left of Xcode and click on the Xcode file, it will bring you to a screen about the file. You then scroll to deployment info and switch the main interface to whichever storyboard you use. I think that since you copied and pasted the code is not linked up to the storyboard.
i am making a very complicated app with a lot of classes.
my app worked great and i worked on it for the last month.
the last time i worked on it i added a function and it worked great, i saved the app and ran it a few times since and it worked. the last time i turned my computer on, it prompted me that an update for xcode is available. i updated it, and since then every time i run my app it runs with no errors but on ios simulator it shows a black screen. what can i do? i worked really hard on that app. thanks for the help in advance.
There's few issues that could happened, withou detailed description of this issue, you can try following solutions:
reset simulator
check if your initial controller is set up in storyboard(select controller and press attribute inspector, select is initial view controller):
if you're setting initial view controller programmatically, check if that controller is not nil in app delegate
another tip - try to use UI debugger, that helps a lot:
Any debug messages in the Xcode output? That usually will give a clue.
One thing I can think of, is that in your
- (void) applicationDidFinishLaunching:(UIApplication*)application
delegate, try setting the window's root view controller to your view controller. Example:
[window setRootViewController:viewController];
[window makeKeyAndVisible];
Again, the Xcode debug output will confirm if this is indeed the case though.
I'm writing an app in Swift 2.0. The app works fine in every aspect, beside one.
When I tilt the screen of both device and emulator the orientation change animation is missing. Instead of a smooth rotation I get a clunky orientation change. Portrait -> Landscape. Nothing in between.
Giving the fact that the animation should be the default, I would like to know if anybody knows the possible solution to this problem. I searched everywhere and apparently nobody has this problem, instead people try to disable that animation!
After some tests and thanks to Zell.B, I moved the code from didFinishLaunchWithOptions to applicationDidBecomeActive and everything works fine.
Deleting the applicationDidFinishLaunching method from the app delegate class can also cause the lack of animation problem. Adding it back in can fix it.
So I've been working on this bug for about a week now, and for the life of me I can't figure out what's happening.
Due to confidentiality issues I can't post too much code, but I'll do my best to explain everything.
What's happening is that we're populating a UITextField via code, and initially have the text greyed out. The user then can do one of two things:
1) Tap a button which says "commit" and a method is called which does the following method we'll call "commitData". It does the following:
Registers the commit with an undo Manager
Changes the text from grey to black
Register with our application that the text field has been updated and needs to be saved upon application close
2) Tap on the text field with the greyed out text, which then calls the following default apple method textViewShouldBeginEditing. From here we call our "commitData" method listed from option 1 like so:
-(BOOL)textViewShouldBeginEditing:(UITextView *)textView
{
if ([[self box] hasGreyedOutText])
[[self box] commitData];
[self setActiveTextView:textView];
return YES;
}
The issue we're having is that tapping the button to commit the greyed out text works perfectly fine, and we run into no issues.
HOWEVER
When we tap into the text field and trigger the textViewShouldBeginEditing method, our iPads can freeze up and make the user wait for a couple of minutes before finishing. When I mean freeze, I mean the entire iPad freezes. The iPad clock won't even update while this is happening.
When this happens, we get an error code in the console which says:
!!! _NSLayoutTreeLineFragmentRectForGlyphAtIndex invalid glyph index 2147483647
We can get the error code above to display from all of our hardware when following the steps above, but can only reproduce the freezing on an iPad 2(with 100% accuracy however).
A note on this, my co-worker has found through diagnostics that we only have about 8MB of free RAM when this error occurs. We only ever hit this little of RAM on the iPad 2 however, so this could just be a coincidence.
I have a feeling that this could be related to threading and that we might need to somehow call our method after returning YES from the textViewShouldBeginEditing method, but I'm not quite sure how I should be going about that.
If anybody has any ideas on how to fix this, or even ideas that could point me in the right direction, I would be incredibly grateful. I've looked everywhere I can possibly think of, and none of the solutions I've found relating to the error code have ended up working.
I can't debug, so in my guess it may caused by non-main thread UI operation. So, my suggestion is to make sure your UI code is in mainThread. Try this:
-(BOOL)textViewShouldBeginEditing:(UITextView *)textView
{
dispatch_async(dispatch_get_main_queue(), ^{
if ([[self box] hasGreyedOutText])
[[self box] commitData];
[self setActiveTextView:textView];
}
return YES;
}
i'm currently working on an ios project with some people, one of us decided to use ARC in a part of the app.
Unfotunatly, we are currently experiencing some crashes when coming back from background.
Here are the steps we follow to crash the application, we perform them with the ios-simulator:
start the application
get on a ViewController A (coded with ARC)
get on a ViewController B (not coded with ARC -to be honest i don't
know if it's relevant-)
put the application in background.
simulate a memory warning (thx to the simulator)
start again the application, we'll be on the ViewController B
go back on the Viewcontroller A
the application crashes pointing the main function with an
EXC_BAD_ACCESS
We did try to use NSZombieEnabled to YES, but when we do it, the application doesn't crash and keeps running perfectly, so we wonder if it might be possible that NSZombieEnabled doesn't work well with ARC?
if anyone could give me a quick and clear insight about ARC and NSZombieEnabled that would be apreciated, i think i know how all of it works, but apparently i must be missing something.
Thanks anyway for your help and time.
Better than using the NSZombieEnabled, you should Profile the project, and use the Zombie instrument. When you do the same thing it should stop and say "zombie messaged", where you can click an arrow to see the class that is a zombie, and where it was allocated/deallocated.
I don't think the crash has to do with ARC, instead in viewDidUnload you are deallocating something, and then not setting a reference to nil - when you come back it tries to use the invalid reference.
Probably you would be better off if everything used ARC as it really helps to cure issues like this (the bug is very likely in the non-ARC code).