Summary:
It's weird but `@_exported import` does not seem to work when archiving with SPM on Xcode 12.5. This means that symbols are not re-exported under the library names that SPM defines but instead are only available in the underlying `FBSDK`-prefixed modules.
## Some context:
The SPM targets with the `Facebook` prefix (ex: `FacebookCore` are by and large just hacks to help people avoid importing dependent frameworks and libraries such as `Accelerate` and `z`. Essentially they are just wrappers. We were using `@_exported import` so that you could use the symbols from the 'wrapped' framework as though they were coming from the original framework.
This works in Xcode13 but does not work for archiving on 12.5.
If you change the import to be `FBSDK` prefixed, you can still reference all of the symbols you need when using 12.5.
Additionally this changeset fixes the need to explicitly include `FacebookAEM` and `FacebookBasics` in your project.
Reviewed By: jawwad
Differential Revision: D31840198
fbshipit-source-id: 145a904c1408cb8fda3123db185d161485c4607c
Summary:
Pull Request resolved: https://github.com/facebook/facebook-ios-sdk/pull/1796
Gaming Services will be structured similarly to CoreKit where there are three modules.
`LegacyGamingServices` - the ObjC code that is currently in `FBSDKGamingServicesKit`
`FacebookGamingServices` - the Swift code for gaming services. At some point this will contain the entire implementation and `LegacyGamingServices` can be removed.
`FBSDKGamingServicesKit` - an ObjC interface **Written in Swift** that will allow for backwards compatibility for ObjC users.
Total Work:
[x] Update module structure for SPM
[x] Update module structure for xcodebuild
[] Update module structure for CocoaPods
Reviewed By: jamestouri
Differential Revision: D29654040
fbshipit-source-id: 0578bba1102705ec13fce0ecb03974616894fd43
Summary:
This extension was doing basically nothing. Removing it does not change any behavior or APIs.
This does make the logging behaviors closed which is fine since there is no good reason at present to have this be extensible for Swift.
Reviewed By: jawwad
Differential Revision: D28649182
fbshipit-source-id: bc6c9862c0d51f1d56d71d957e0a7810c73ab59a
Summary:
Pull Request resolved: https://github.com/facebook/facebook-ios-sdk/pull/1744
Making the BridgeAPI files public broke the SPM integration. This fixes it by getting rid of modular import statements at the top level.
Reviewed By: jingping2015
Differential Revision: D28335156
fbshipit-source-id: f0543a2f625c2856ac3c2cc351dcf68b5345e89a
Summary:
Our Logger was written to be easy to use with untested Objective-C code. It formats Strings and creates underlying instances to use in its class methods.
This changeset aims to break these patterns by introducing a logging factory so that types will request logger instances from the factory and then use those instances for logging where needed.
Additionally, variadic Objective-C parameters will translate to Swift but it's kind of a pain and there really isn't a compelling reason to include this helper function in any protocol that will be used in defining Swift types. This changes existing ObjC callsites to format their own strings before passing them to the logger since this is how it will work in Swift.
Next steps for cleaning this up:
Get rid of the following class methods:
```
+ (NSUInteger)generateSerialNumber;
+ (void)singleShotLogEntry:(FBSDKLoggingBehavior)loggingBehavior
logEntry:(NSString *)logEntry;
+ (void)singleShotLogEntry:(FBSDKLoggingBehavior)loggingBehavior
timestampTag:(NSObject *)timestampTag
formatString:(NSString *)formatString, ... NS_FORMAT_FUNCTION(3,4);
+ (void)registerCurrentTime:(NSString *)loggingBehavior
withTag:(NSObject *)timestampTag;
+ (void)registerStringToReplace:(NSString *)replace
replaceWith:(NSString *)replaceWith;
```
Get rid of the following instance methods since they are only used in GraphRequestConnection. There should be a more specific type to use here instead of forcing all loggers to have / expose these:
```
- (void)appendString:(NSString *)string;
- (void)appendFormat:(NSString *)formatString, ... NS_FORMAT_FUNCTION(1,2);
- (void)appendKey:(NSString *)key value:(NSString *)value;
- (void)emitToNSLog;
```
Inject settings so that Logger does not rely on global state.
Reviewed By: jamestouri
Differential Revision: D28108603
fbshipit-source-id: feb50591fe8596c6fa26850b080d10d46c608200
Summary:
Reorganizes to set us up for a Swift rewrite.
One thing to note about this rewrite is that we cannot simply replace arbitrary files. The dependency graph is extremely important because Swift Package Manager does not support mixed Swift and Objective-C source files.
The high level goal is to maintain backwards compatibility for users importing FBSDKCoreKit while still moving the implementation to Swift under the hood.
To do this, we will need to introduce a new module, LegacyCoreKit which will serve as the source of existing ObjC files.
The existing Swift Package Manager module, FacebookCore, will depend on LegacyCoreKit and will host the top-level Swift files. Top-level in this case refers to those files with the fewest callers from inside the SDK itself; a prime example of this is ApplicationDelegate.
To maintain backwards compatibility for the interfaces, the existing module FBSDKCoreKit will be repurposed to provide wrapper interfaces for FacebookCore.
At the modular level, the dependency graph will look like this:
LegacyCoreKit the original ObjC implementation undergoing the rewrite
↓
FacebookCore the rewritten native Swift files
↓
FBSDKCoreKit backwards compatible ObjC interfaces
There's still work to do for this including:
* Update CocoaPods to use follow the same structure of relying on an underlying module for the original ObjC implementation
* Update the Xcode targets to follow the same structure and use an underlying module for the original ObjC implementation
* Remove OCMock so that we are forced to restructure the dependencies to be injectable
Reviewed By: Oliverccccct
Differential Revision: D27855791
fbshipit-source-id: f3b5fbbe67492d3a131d475688e91ee8ab51ae6b
