I'm running into an issue with my swift 2 conversion of an Apple provided example for displaying an AVMutableComposition. This is a really useful project if you're trying to visualize your AVComposition to see what might be going on under the hood.
Update: I added print statements to each function to see the order they are being called, and who is calling them, in comparison to the Obj-C project.
Two Issues that I'm seeing that seem pretty important:
synchronizePlayerWithEditor() is not getting called after buildTransitionComposition(_:andVideoComposition:andAudioMix:)
observeValueForKeyPath(_:...) is NOT being called in the same order as the Obj-C project
Posting the snippet here to get the calling function as it's kind of useful
Obj-C
NSLog(#"%d %s %#", __LINE__, __PRETTY_FUNCTION__, [[NSThread callStackSymbols] objectAtIndex:1]);
Swift
func functionnYouWantToPrintCaller(yourNormalParameters..., function:String = __FUNCTION__){...}
print("\(__LINE__) \(__FUNCTION__) \(function)
Here is Apple's AVCompositionDebugViewer project I'm working from: https://developer.apple.com/library/mac/samplecode/AVCompositionDebugViewer
My github repo:
https://github.com/justinlevi/iOSAVCompositionDebugViewerSwift
I think the issue might be stemming from something in the keyValueObservation code although I'm not entirely sure at this point.
The issue ended up being in SimpleEditor.swiftbuildCompositionObjectsForPlayback` method. There were some global variables that were being defined incorrectly.
Everything seems to be working as expected now.
https://github.com/justinlevi/iOSAVCompositionDebugViewerSwift
Related
Here is my customized NSLog.
#define NSLog(fmt, ...) printf("🌳🌳🌳%s,%d\n %s\n\n", __PRETTY_FUNCTION__, __LINE__, [NSString stringWithFormat:fmt, ##__VA_ARGS__].UTF8String)
This log is work good on another project, but it occurred 4 error when compiler time in current project. If using __VA_ARGS__, like #define NSLog(...) NSLog(__VA_ARGS__), it's going to compile successful. I think that maybe caused in Building Setting.
It's anyone has any idea to help me to solve this.
Check that the header file declaring this imports Foundation. Check that you don't have NSLog defined somewhere else as well and finally, really not a good idea to redefine NSLog. You're probably better off adopting a logging framework or defining your own like this:
#define MELog(fmt, ...) NSLog("🌳🌳🌳%s,%d\n %s\ ....
I am using a third party library in my Objective-C project that has an enum defined as:
typedef NS_ENUM(NSUInteger, RJBEvent)
{
RJB_EVENT_OK = 1,
RJB_EVENT_ERROR=2,
RJB_EVENT_START = 4,
};
Then in Objective-C, I can do the following:
[self.rjbLib listenForEvents:(RJB_EVENT_START|RJB_EVENT_OK|RJB_EVENT_ERROR)];
As an exercise to teach myself Swift, I'm porting the app. All's well until I run up against using this enum. There's a ton of info out there about how (or how not to) use enums in Swift, but very little to describe this bitmask-style usage. I've got this, and it compiles, but I'm not receiving the expected event notifications.
let rjbEventsMask : UInt32 = UInt32(RJBEvent.RJB_EVENT_OK.rawValue |
RJBEvent.RJB_EVENT_ERROR.rawValue |
RJBEvent.RJB_EVENT_START.rawValue)
I do see a suggestion on NSHipster that I may need to change the third-party header file to use NS_OPTIONS. I'm going to try that, but changing the developer's provided .h file is a bit dangerous, so it's not my preferred approach.
Any guidance is appreciated.
Thanks!
Rob
My app gets stuck on splash screen in iOS 9 both on iPhone and simulator. I can run it on iOS 8 or lower on device and simulator with no problem. My colleague working on the same app has exactly the same problem.
There is no error or anything, just hangs on splash screen. If I stop it on xcode and try to run it from the phone or simulator directly, it would run without any problem.
By the way, I don't see didFinishLaunchingWithOptions or willFinishLaunchingWithOptions getting called!
In your "answer" you include the code:
+(void)initialize
{
titles = #[NSLocalizedString(#"CODE", nil), NSLocalizedString(#"ERROR", nil), NSLocalizedString(#"TROUBLESHOOTING", nil)];
}
This is indeed the source of your issue. It's wise to be very careful when implementing +load or +initialize. #bbum has a great article on exactly that topic.
+initialize is invoked the first time the class (or category) is touched - when the class is initialized +initialize is called by the class loading mechanism. There is no guarantee of when in the class loading process this may happen, which is part of your problem.
In your case you are using NSLocalizedString - which under the hood can be fairly heavy. It has dependancies on several other classes (NSString, etc) and can potentially access the file system. As #bbum points out in his article, that can lead to serious trouble. In your case, this may be a nasty deadlock.
Move your titles = #[NSLocalizedString... line to a more appropriate place in your object, like an initializer, awakeAfterUsingCoder:, etc. and your immediate problem should be solved. After doing so you should check your entire codebase for instances where +initialize and +load are implemented and audit them to make sure those uses are in line with #bbum 's recommendations.
OK I found the problem. It sounds ridiculous though!!
I am using UITabBarController and inside the first controller I have a UITableViewController with a customised datasource class which would initiate a hard code table header and these headers are localised!!
+ (void)initialize {
titles = #[NSLocalizedString(#"CODE", nil), NSLocalizedString(#"ERROR", nil), NSLocalizedString(#"TROUBLESHOOTING", nil)];
}
After I traced the stacks, I realised the process gets stuck right there with no trace and error! I still don't know why!
So I came up with a workaround:
+ (void)initialize {
titles = #[#"Code",#"Error",#"Troubleshooting"];
}
And only retrieve the localised value when returning the text:
- (NSString *)titleAt:(NSInteger)index {
return NSLocalizedString(titles[index],nil);
}
I have both debug and release set to NO
You sure "any SDK" also has arm64?
Ok, I think I found the answer.
You have to specify arm64 in all "Valid Architectures".
If you don't specify arm64 or forget one the app won't start and stays on the splashscreen.
Just verified this.
Is this an Xcode 7 bug?
I'm getting this error:
/Class/GData/OAuth/GDataOAuthViewControllerTouch.m:116:22: Expected a type
That line is:
authentication:(GDataOAuthAuthentication *)auth
Inside of this block of code:
- (id)initWithScope:(NSString *)scope
language:(NSString *)language
requestTokenURL:(NSURL *)requestURL
authorizeTokenURL:(NSURL *)authorizeURL
accessTokenURL:(NSURL *)accessURL
authentication:(GDataOAuthAuthentication *)auth
appServiceName:(NSString *)keychainAppServiceName
delegate:(id)delegate
finishedSelector:(SEL)finishedSelector {
NSString *nibName = [[self class] authNibName];
I'm a newb XCode developer. So far I've created and compiled a calculator app based from an online class but that's it.
Is this a library that is not being included?
Background: The previous developer abandoned the project and the owner sent the project code to me. I'm trying to replace the existing graphics with new graphics and recompile it with support for iOS 6, which I thought I should be able to do without any coding, but have run into this error and many others when I opened the project. I have the latest XCode.
The :22 (and the position of the caret within the editor) tell you exactly where on the line the error is. In this case it's telling you that where it sees GDataOAuthAuthentication it was expecting a type. So, implicitly, it doesn't recognise that GDataOAuthAuthentication is a type.
Objective-C still sits upon compilation units ala C — each .m file is compiled in isolation then the lot are linked together. You use #import (or #include if you want; #import just guarantees the same file won't be included twice) to give each individual file visible sight of any external definitions it needs.
So, that's a long-winded way of reaching the same conclusion as Rick did five minutes ago: you've probably omitted a necessary #import.
A few things to look for:
Did you #import the file where the GDataOAuthAuthentication type is defined? (e.g. #import "GDataOAuthAuthentication.h")
Is there a variable named GDataOAuthAuthentication which is causing the compiler to think GDataOAuthAuthentication is a variable not a type?
I'm trying to use CoreBluetooth's retrievePeripheral :
- (void)retrievePeripherals:(NSArray *)peripheralUUIDs;
The documentation says peripheralUUIDs should be a NSArray of CFUUIDRef. In the Apple sample project temperatureSensor, it is called as :
[centralManager retrievePeripherals:[NSArray arrayWithObject:(id)uuid]];
(uuid being a CFUUIDRef)
When I use the exact same code in XCode 4.5.1, IOS6, I'm getting a error :
Cast of C pointer type 'CFUUIDRef' (aka 'const struct __CFUUID *') to Objective-C pointer type 'id' requires a bridged cast
I would say (though I'm far from sure) that the reason it works in TemperatureSensor and not in my project is because TemperatureSensor seems not to use ARC whereas my project does.
Xcode suggests 2 ways of solving the problem : adding a __bridge or using CFBridgingRelease(). I tried them both and I'm under the impression that the function does not work [Edit] because the delegate methode didRetrievePeripheral: never gets called [/Edit] (my understanding is that these operation would change the C-style structs into objective-C-objects thus creating a NSUUID, and the method can't use it, but, again I'm really not sure)
So what should I do ? I've been searching on google for examples of retrievePeripherals using ARC, but without success.
In the temperature sensor change this line and run
LeDiscovery.m
-(void) startScanningForUUIDString:(NSString *)uuidString
{
[centralManager scanForPeripheralsWithServices:nil options:0];
}
change the word nil and assume 0.
If you want more check this link.
I hope its useful for you.
Turns out the problem was much simpler than that. I copied/pasted some code from TemperatureSensor, specifically the DidRetrievePeripheral. But it turns out, there's an error in this code (it's DidRetrievePeripheralS), so the delegate method never gets called. I think the bug is already reported.
Thanks/sorry