This function fails with runtime error:
-[UIWindow viewForFirstBaselineLayout]: unrecognized selector sent to instance 0x7fb9dae257d0
Anybody encountered the same?
UPD:
Fails on simulator iOS 8.1/8.4. 9.3 works fine.
UPD2:
UIWindow is created like:
window = UIWindow(frame: UIScreen.mainScreen().bounds)
window?.rootViewController = RootViewController.rootVC
window?.makeKeyAndVisible()
I got the view debugger working again by placing the following fix in my project:
#ifdef DEBUG
#import <UIKit/UIKit.h>
#import <objc/runtime.h>
#implementation UIView (FixViewDebugging)
+ (void)load
{
Method original = class_getInstanceMethod(self, #selector(viewForBaselineLayout));
class_addMethod(self, #selector(viewForFirstBaselineLayout), method_getImplementation(original), method_getTypeEncoding(original));
class_addMethod(self, #selector(viewForLastBaselineLayout), method_getImplementation(original), method_getTypeEncoding(original));
}
#end
#endif
When your project loads, the load method will execute, causing viewForFirstBaselineLayout and viewForLastBaselineLayout to use the viewForBaselineLayout implementation if they are not currently implemented, so view debugging gets iOS8 flavor the behavior it was looking for.
To add this to your own project, create a new empty Objective-C file in your project and paste the contents in. You can name it whatever you want. I call mine "UIView+FixViewDebugging". If you are in a pure Swift project you do not need to create a bridging header. The file will be compiled into your project and you don't need to reference it.
Note this will only work for debug builds because of the #ifdef DEBUG. You can remove it but then you may accidentally compile this into your release builds (though it should have no ill side effects). If this method isn't working with these lines, check that your target has DEBUG=1 in Build Settings > Apple LLVM - Preprocessing > Preprocessor Macros > Debug.
Looks like Xcode 7.3 uses viewForFirstBaselineLayout property to draw the UI. But this property is marked as available since iOS 9.0.
[UIView viewForFirstBaselineLayout] method should be used for the version prior to iOS 9.0. It seems the guys from Apple didn't consider this case.
Yes. when click the debug view hierarchy button ,the page has nothing, and print "[UIWindow viewForFirstBaselineLayout]: unrecognized selector sent to instance 0x7fb9dae257d0" .
To solved it, just be sure you are using the iOS systom not below iOS 9.0 and you will still use that function freely.
Related
I'M trying to integrate Google Analytics to my Xcode project. I've added obj-c classes by using bridging header and then I've set some options in AppDelegate. After AppDelegate commands I got the following errors. How can I solve that one?
Note: Xcode recognises GAI class.
Error causing code:
GAI.sharedInstance().trackUncaughtExceptions = true
GAI.sharedInstance().logger.logLevel = .Verbose
GAI.sharedInstance().dispatchInterval = 20
GAI.sharedInstance().trackerWithTrackingId("UA-XXXXXXX-Y")
Errors:
Quick fix(works for me) - Delete the 'Google Analytics' references,not "remove to trash" option from your project navigator, and add them again. Should work out
I just forgot to libGoogleAnalyticsServices.a file.
I have 2 test classes in a XCode 5 project:
ABCDataModelTests.{h,m}
- (void)testAlwaysPassing { ... }
ABCDataModelListColorsTests.m which inherits from ABCDataModelTests.
- (void)testNumberOfListColorsGreaterThan7 { ... }
When I ran the test, I noticed that there is a symbol "rT" underneath the subclass's tests as shown in the picture.
What does "rT" stand for? Note that the subclass inherits the test method "testAlwaysPassing."
I can't find anything in the Apple documentation for "New Features in XCode 5/5.0.1" Is there any documentation for what all the symbols stand for?
I found this information on some forums:
The standard way to do things in SenTestingKit/OCUnit/XCTest is to declare your tests in code. If you do, Xcode will discover them statically (ie. not at runtime) using the index. Once Xcode these tests are discovered, they show up in the test navigator with a "t" icon. So far so good.
Now, the SenTestingKit/OCUnit/XCTest frameworks also allow you to create tests on the fly at runtime. Some of our users make creative user of this capability, perhaps to wrap an external testing system or to create tests to represent a dynamic set of data. Xcode cannot discover these tests statically, and only find out about their existence when they are returning resutls during a test run. When discovered, they will show up in the test navigator with a "rT" icon. "rT" being short for "runtime discovered tests".
Finally. If there's anything wrong / unusual about your project that prevents indexing from completing or from properly parsing your test classes, then your tests wouldn't be statically discovered. You may still successfully build and run them, in which case Xcode would end up treating them as runtime discovered tests, and give them the "rT" icon.
Interesting. I have been very annoyed by the same problem with a test class I created by duplicating another file in the IDE. I have duplicated other test files before so that doesn't seem to be the problem.
The test class has only a single test inside it and another side-effect of the purple icon and classification of it as a runtime test is that you can't trigger the test with the little triangle icon offered in the test runner for the other tests or test classes.
The contextual menu in the test explorer offers Test "testBlah" which seems to exercise the test.
Quitting XCode, deleting the xcuserdata folder and rebuilding made the test recognised again as a normal test.
I am getting reminders of older Visual Studio versions which used to have caching problems and needed regular deletion of their local context data!
I agree with what #everyday_productive said
"rT" usually means something wrong with indexing, to fix this go to terminal and type the following:
$ cd ~/Library/Developer/Xcode/
Make sure your Xcode is terminated then delete "Derived Data" folder.
Deleting derived data didn't help me to get rid of running these tests. So I've created a small category on XCTestCase and it worked:
#import "XCTestCase+TestCaseSwizzling.h"
#import ObjectiveC.runtime;
static NSMutableSet* alreadyRunTests = nil;
#implementation XCTestCase (TestCaseSwizzling)
+ (void)load
{
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
alreadyRunTests = [NSMutableSet set];
Class class = [self class];
SEL originalSelector = #selector(invokeTest);
SEL swizzledSelector = #selector(swizzledInvokeTest);
Method originalMethod = class_getInstanceMethod(class, originalSelector);
Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
method_exchangeImplementations(originalMethod, swizzledMethod);
});
}
- (void)swizzledInvokeTest
{
NSString* selectorString = NSStringFromSelector(self.invocation.selector);
if (![alreadyRunTests containsObject:selectorString])
{
[alreadyRunTests addObject:selectorString];
[self swizzledInvokeTest];
}
}
#end
Delete the references to the files from the project, then re-added them.
Using the built-in testing framework provided by Xcode, is there any way for application code to determine whether it is being run by the test runner, as opposed to running as the app?
In other words, I'm wondering whether it is possible to do something like this in the application code:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// ...
if (IsUnitTestRunning()) {
[self useDefaultSettings];
[self showDefaultViewController];
}
else {
[self restoreUserSettings];
[self restoreUserInterface];
}
// ...
}
I know I could create a new configuration that defines some precompiler macros and set the Xcode scheme to build and use that configuration when running a test, or I could set some sort of global variable in my app to YES when running a test, but I'm wondering whether there is already something built into OCUnit or Xcode to handle this.
On the Macintosh, there's a way to pass along some options during debug from Xcode that make it into the "int main(argc, argv)".
I suspect there's similar functionality on the iOS side. You should be able to catch options being passed in via "int main(argc, argv)".
Here's where you make the modification on the Xcode side of things:
Another option might be to look in the options dictionary passed in via "didFinishLaunchingWithOptions:" and see if there is something different about launching from Xcode versus launching it on the device or on the simulator (without being launched from Xcode).
I am receiving a lot of "sematic issue" errors when trying to test my iPhone application after installing my provisioning profile from Apple.
It has worked perfectly during the development period, however since I set up my provisioning profile, each time I try to build I receive the errors below (80 when my physical device is selected and 10 when using simulator):
RKRequest.h: error: Semantic Issue: Redefinition of 'RKRequestMethod'
RKRequest.h: error: Semantic Issue: Redefinition of enumerator 'RKRequestMethodPOST'
...
I retrieved the version of RestKit from its git repository about a month ago and it has been working perfectly until now.
Here is a sample from the error detail:
In file included from /Users/nick/Library/Developer/Xcode/DerivedData/MyApp-
bpcvkhxzjupqmibdvvipchdfecpi/Build/Products/Debug-
iphoneos/include/RestKit/CoreData/../ObjectMapping/../Network/RKClient.h:21:
I have tried clearing this directory but the problem persists and have included a screenshot below:
Here's an example of how RestKit is used in the app:
MyViewController.h
#import <RestKit/RestKit.h>
#import <RestKit/CoreData/CoreData.h>
#interface MyViewController : UIViewController<RKObjectLoaderDelegate, MFMailComposeViewControllerDelegate, UIActionSheetDelegate, SelectTranslationDelegate>
...
MyViewController.m
#interface MyViewController()
{
}
#end
...
#implementation MyViewController
...
My Linked Libraries
Does anybody have any suggestions as to why this might be?
From the screenshots and our chat conversation i can tell you are using an outdated version of RestKit. Recently, they significantly simplified the build process and submitted a number of iOS5 fixes so the update is worth it.
run git pull in the RestKit directory
remove #import <RestKit/CoreData/CoreData.h> from your files. Just #import "RestKit/RestKit.h" should do the trick
Remove all RestKit libs from "Link Binary With Libraries", be sure to add new libRestKit.a and libxml2.dylib
Try building the project, if you see any errors try removing derived data in Organizer.
As a starter, check your project 'Build Phases' in Xcode and make sure you have't got more than one entry for each of the RESTKit .m files (or a stray .h), in the 'Compile Sources' list.
Since I upgraded from Xcode 3.2.3 to 3.2.4 and iOS 4.0.1 to iOS 4.1 SDK, when I set a breakpoint in my code and single-step over instructions, at each step, the debugger will spit one or more of that line:
Assertion failed: (cls), function getName, file /SourceCache/objc4_Sim/objc4-427.1.1/runtime/objc-runtime-new.m, line 3939
It doesn't happen on a specific line or for a specific instructions. I have a few breakpoints in my code and each time I hit one of those, the debugger starts spewing those messages. It doesn't seem to have any detrimental effect as the program works correctly. It's just very annoying to retrieve the information in the console when there are tens of those lines. I'm sure they're not displayed for nothing but I haven't found what the problem might be and what instruction might cause it. If I don't hit a breakpoint, then I don't see any of those lines. I did clean and rebuild my project multiple times to no avail.
Does anybody have any idea what this is?
I ran into this - and here's the reason mine happened: I had used
+localizedStringFromDate:dateStyle:timeStyle: in my code. Worked fine on the iPhone, but it's not available pre-4.0 SDK, so it coughed on the iPad. See if you're calling some routine that's either no longer available in the SDK, or available only in later versions. Frankly, I can't wait for 4.1 on the iPad!
-Owen
I'm also having this problem, in an iPad app originally written in Xcode 3.2.4 using the iOS 3.2 SDK, now being debugged in Xcode 3.2.5 using the 4.2 SDK, but only when I set the simulator to the 3.2 iOS Deployment Target (so I can run in the 3.2 simulator). Every stop at a breakpoint in the debugger, I get this assert repeated eight times. Single-stepping over a line gets two more.
What I can't understand is I haven't added any code to the project since I last run it in Xcode 3.2.4 and iOS SDK 3.2, so I can't have added any calls that were not present in that SDK or else it wouldn't have compiled.
Until someone finds an answer to this, I think the only workaround (so I can continue debugging my code in a 3.2 environment) is to reinstall Xcode 3.2.4 and use the 3.2 SDK and simulator.
I had this problem when I was running on simulator "iPad 3.2 simulator". This problem disappeared when I switched the simulator to "iPad 4.3 simulator"
I have exactly the same issue. I know it's not the complete answer but here's what I could find.
The relevant function getName looks like this:
/***********************************************************************
* getName
* fixme
* Locking: runtimeLock must be held by the caller
**********************************************************************/
static const char *
getName(struct class_t *cls)
{
// fixme hack rwlock_assert_writing(&runtimeLock);
assert(cls);
if (isRealized(cls)) {
return cls->data->ro->name;
} else {
return ((const struct class_ro_t *)cls->data)->name;
}
}
So gdb is complaining that the assertion assert(cls) is failing. Which means that getName somehow gets a NULL pointer as an argument.
Which is kinda funny, where could we be asking for the name of a NULL class?
Hope this helps...
I also have the same problem; I don't have a solution but I'm able to work around it. In short, I suggest you add more breakpoints...
I noticed in the call stack that it's actually the debugger that is misbehaving. The function gdb_class_getClass calls getName, presumedly this is passing NULL instead of (say) MyClass. The code that I'm trying to debug is a method of MyClass. So, thinking that the debugger has a problem with MyClass, I set a breakpoint at a line outside of any code of MyClass (ie the line that calls the method on MyClass) and hit continue when the program breaks. This seems to resolve the problem in my case. (Note that auto-continue doesn't work.)
To be clear:
//Set breakpoint here
[myClassInstance buggyMethod];
My buggyMethod is actually in another file:
...
-(void)buggyMethod {
//This is where I set my 'real' breakpoint
Hope that helps.
I'm having a similar problem, but mine is with creating a custom view with Core Text in it. As soon as my view's drawRect calls the line
CTFontRef titleFont = CTFontCreateWithName(CFSTR("Baskerville"), 40.0f, NULL);
It hangs the app, whether in the simulator or on the device. Bizarrely, I can rectify this by alloc-initing another UIKit text component in the View Controller's viewDidLoad method... I don't even have to add it as a subview. It's like it needs some common text elements loaded before Core Text can load in fonts.
- (void)viewDidLoad
{
[super viewDidLoad];
UILabel *l = [[UILabel alloc] initWithFrame:CGRectMake(0, 0, 0, 0)];
}
Weird.