Summary: Updated the Podspecs and Package Manifest for the artifacts to be released.
Reviewed By: samodom
Differential Revision: D31380729
fbshipit-source-id: c7caf5d9cc16e37a350b7d13ad2cb3888e5b2f1c
Summary: Actually moving the files. Needs to go in a separate commit so that HG doesn't consider them to be additions. There may be an hg command that handles symlinks more gracefully but I don't know what it is.
Reviewed By: jawwad
Differential Revision: D30522433
fbshipit-source-id: de5ee14ee982c69203d19fcdb9f0468ddb640333
Summary:
In these stacked diffs, we are going to abstract AEM logic inside FBSDKCoreKit to an independent module called FBAEMKit.
In the end state, FBSDK, MMP and S2S will rely on the same AEMKit.
In this diff:
1. add `FBSDKAEMNetworker` to adopt `FBAEMNetworking`
2. in `FBSDKAEMNetworker`, we still use `FBSDKGraphRequest` to fire a graph API request
3. replace `FBSDKAEMReporter` with `FBAEMReporter`
4. update BUCK
5. added cocoapod support
Reviewed By: joesus
Differential Revision: D29274621
fbshipit-source-id: baa4dd86df358cd56d867745fd741caab5f1c586
Summary: The issue is that we have a mismatch between how basics is consumed. In terms of BUCK, SPM, and Xcodebuild it's a true module. In the case of CocoaPods it's a "subspec" which is not actually a module. This means we have differences in import statements, and general inconsistencies between our build processes which slows development and is a general pain to manage.
Reviewed By: jawwad
Differential Revision: D28522118
fbshipit-source-id: 953629bd5f365af1fcc064e0f7b6fcf0a07ab48d
Summary:
FBSDKCoreKit_Basics is currently a module for Swift Package Manager and BUCK but not for CocoaPods or Xcodebuild.
This aims to bring the four in line by separating it into its own module for Xcode builds.
Reviewed By: dreamolight
Differential Revision: D28312787
fbshipit-source-id: b31136de9eb98b31d061d289cd0ea7116acf1c14
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:
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
Summary:
The end result is the final product ends up converting the strings files from the current text format to a minified binary plist format.
Size change:
Before
246,293 bytes (365 KB on disk)
After
133,039 bytes (184 KB on disk)
Nice ~100KB win for installed app size.
I decided to leave the bundle alone instead of breaking out the strings into their own folder because I didn't know if anything else was using the bundle currently. It doesn't look like spm is using it, which is probably a bug.
Also I'm not sure if these strings have test coverage or not, but if not I can help make sure various translations are still working correctly. Not sure where exactly these strings are used.
To help us review the request, please complete the following:
- [x] sign [contributor license agreement](https://code.facebook.com/cla)
- [x] I've ensured that all existing tests pass and added tests (when/where necessary) Wasn't sure how to run them all, I assume PR process has CI that will run them.
- [x] I've updated the documentation (when/where necessary) and [Changelog](CHANGELOG.md) (when/where necessary)
- [x] I've added the proper label to this pull request (e.g. `bug` for bug fixes) I can't add labels.
Pull Request resolved: https://github.com/facebook/facebook-ios-sdk/pull/1713
Test Plan:
Create a new iOS project called `CocoaPodsTranslations` and point to the local pods:
```
// Podfile
target 'CocoaPodsTranslations' do
# Comment the next line if you don't want to use dynamic frameworks
use_frameworks!
# Pods for CocoaPodsTranslations
pod 'FBSDKCoreKit', :path => '/Users/joesusnick/fbsource/fbobjc/ios-sdk'
pod 'FBSDKLoginKit', :path => '/Users/joesusnick/fbsource/fbobjc/ios-sdk'
end
```
Adds localizations for a few languages by hitting the '+' under Localization in the project settings. (You'll need to make sure something is checked in the boxes so just accept whatever the default suggestions are)
Then change the schemes's locale in the 'edit scheme' as shown in the video and run.
{F609517560}
Complete flow to show logout alert dialog:
{F609518875}
Reviewed By: khp
Differential Revision: D27881169
Pulled By: joesus
fbshipit-source-id: 0dcb3d641e639a229020012a8b54ee7248ce9098
Summary: It makes sense to wait until we have more pressing breaking changes to release a major version.
Reviewed By: KylinChang
Differential Revision: D26796073
fbshipit-source-id: f01d622bb7f8451a67309d8c3f62284ceda9a678
Summary: Updating major version to match Graph API release.
Reviewed By: linmx0130
Differential Revision: D26711406
fbshipit-source-id: 2ba166ff86b0d97aececa630e6ee4585ff520aae
Summary: Minor cleanup - Removes some paths in `public_header_files` that were being clobbered anyway by `private_header_files`.
Reviewed By: Oliverccccct
Differential Revision: D26429454
fbshipit-source-id: 6d84edc48b74e9bf35e366b0c659b155b12007b6
Summary:
The main goal of this diff is to remove OHHTPStubs from the FBSDKAppLinkResolver test code.
The easiest way to do that has been to extract the request building part from FBSDKAppLinkResolver to it own class.
These allows us to:
- Assert correctness over some parts of the request independently
- Inject a builder mock in FBSDKAppLinkResolver so we can control the FBSDKGraphRequest and inject the response we want, without having to mock the http layer at all.
Reviewed By: joesus
Differential Revision: D24077192
fbshipit-source-id: 54141fe1a0533bc97503e7a241387c0d0c4da5e3
Summary:
Pull Request resolved: https://github.com/facebook/facebook-ios-sdk/pull/1367
Bumping version to 7.0
Bumping Graph API version to 7.0
Reviewed By: jingping2015
Differential Revision: D21405159
fbshipit-source-id: 7ee479aff3ed663210ae0adb13840280d373d9da
Summary:
Thanks for proposing a pull request!
To help us review the request, please complete the following:
- [x] sign [contributor license agreement](https://developers.facebook.com/opensource/cla)
- [x] I've ensured that all existing tests pass and added tests (when/where necessary)
- [x] I've updated the documentation (when/where necessary) and [Changelog](CHANGELOG.md) (when/where necessary)
- [x] I've added the proper label to this pull request (e.g. `bug` for bug fixes)
## Pull Request Details
Updates for v7.0.
Main change is that the SDK can not be developed using Swift. Default will be to build and distribute with Xcode11 using Swift5.
**Migration Concerns**
* CocoaPods
If you were using the 'Swift' subspec of CocoaPods, ex:
`pod 'FBSDKCoreKit/Swift'`
you can now simply use:
`pod 'FBSDKCoreKit`
* Carthage
You will need to use Xcode 11 or later but no other changes should be necessary. The binaries will include the enhanced Swift interfaces by default.
* SPM
No changes
* xcodebuild
No real changes. The '-Swift' targets are deleted. ex:
target `FBSDKCoreKitSwift-Dynamic` is gone. You can simply use `FBSDKCoreKit-Dynamic` and it will include Swift files
* BUCK
Buck will continue to exclude Swift files for the moment. This is an ongoing effort.
Pull Request resolved: https://github.com/facebook/facebook-ios-sdk/pull/1355
Test Plan: CI and extensive manual testing to make sure we haven't broken any channels.
Reviewed By: dreamolight
Differential Revision: D21239951
Pulled By: joesus
fbshipit-source-id: 325e2049c5fb1b55769c066998dd4b50e0ccaccc
Summary:
Pull Request resolved: https://github.com/facebook/facebook-ios-sdk/pull/1268
Not sure why we were weak-linking core location. I am assuming this was related in some way to the deprecated PlacesKit but am not positive.
Reviewed By: Oliverccccct
Differential Revision: D20167000
fbshipit-source-id: 4b8e69d3e263667cb29ac6ecebb87c0da3ba93bb
Summary:
Pull Request resolved: https://github.com/facebook/facebook-ios-sdk/pull/1220
Bumps sdk version to 6.0.0
Bumps api version to v6.0
Reviewed By: jingping2015, ZebingZong, KylinChang
Differential Revision: D19698716
fbshipit-source-id: 165ad3f3ac0f5c686e965f521e9d807f9f21d523
