-
Notifications
You must be signed in to change notification settings - Fork 1.7k
FIS Public API #3135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FIS Public API #3135
Conversation
maksymmalyhin
commented
Jun 4, 2019
- public API
- FIS instance config
- basic tests
…into mm/fis-keychain
|
||
- (FIRApp *)createAndConfigureAppWithName:(NSString *)name { | ||
FIROptions *options = [[FIROptions alloc] initInternalWithOptionsDictionary:@{ | ||
@"GOOGLE_APP_ID" : @"1:1085102361755:ios:f790a919483d5bdf", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this real?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. It might be because I took it from another Firebase test. I'll better replace it with an obviously fake value
} | ||
|
||
- (void)installationIDWithCompletion:(FIRInstallationsIDHandler)completion { | ||
completion(@"123", nil); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
123?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a placeholder so far. Real implementation will be added in next PRs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding a TODO would be good in that case to keep track and make it more visible for reviewers :)
FirebaseInstallations/Source/Library/Public/FIRAuthTokenResult.h
Outdated
Show resolved
Hide resolved
FIRComponentCreationBlock creationBlock = | ||
^id _Nullable(FIRComponentContainer *container, BOOL *isCacheable) { | ||
*isCacheable = YES; | ||
FIRInstallations *installations = [[FIRInstallations alloc] initWithApp:container.app]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See the other comment I left below - we could pull out the information needed here to inject into the FIRInstallations
initializer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ryanwilson I would rather keep both initWithGoogleAppID:appName:
and initWithApp:
initializers, so the 2nd one uses the 1st. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a particular reason you want to keep the initWithApp:
initializer? I'm not sure what benefit there is outside of not having to change the initializer here in the component creation if it ever changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just would prefer to keep the logic (in this case extracting info from FIRApp
) outside of the block used by a very specific method. If we can initialize an instance with a FIRApp
, then having a convenience initializer sounds logical to me.
Not too strong opinion here, I am fine with initWithGoogleAppID:appName:
only if there are downsides of having both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ryanwilson I pushed the version with 2 initializers just because I had it before your response. Let me know if you have a strong opinion to remove initWithApp:
FIROptions *options = [[FIROptions alloc] initInternalWithOptionsDictionary:@{ | ||
@"GOOGLE_APP_ID" : @"1:1085102361755:ios:f790a919483d5bdf", | ||
}]; | ||
[FIRApp configureWithName:name options:options]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
configureWithName:options:
has some internal state associated with it that may affect tests running concurrently that can lead to flakes. Using the [FIRInstallations installations]
singleton can do the same. I mentioned a way to get around this in the other file about the initializer, then no FIRApp is necessary for most
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. I have couple questions here:
- Will I need to configure a
FIRApp
to test singleton? - Do we run tests concurrently?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Yes, that is required. There are ways to do it without explicitly calling
configure
but if it's a single test case that's probably okay and reduces the surface for flakes due to global state. I believe we have some other code to have the container properly initialized without global state but I'll have to find it if needed. - Yes. Tests in other files run concurrently, but test cases in the same class run synchronously.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kept the logic for the singleton tests but other tests use initWithGoogleAppID:appName:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, we should have a test app calling your API for end to end testing, which could potentially be used for integration testing as well.
I have something similar setup inside google3.
@chliangGoogle Good point! I am going to add it later on. |
} | ||
|
||
- (void)installationIDWithCompletion:(FIRInstallationsIDHandler)completion { | ||
completion(@"123", nil); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding a TODO would be good in that case to keep track and make it more visible for reviewers :)
NS_SWIFT_NAME(InstallationsTokenHandler); | ||
|
||
NS_SWIFT_NAME(Installations) | ||
@interface FIRInstallations : NSObject |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do also need a + (FIRInstallations *)installations NS_SWIFT_NAME(installations);
for the default app instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ryanwilson I'll add it in following PRs if you don't mind.
FirebaseInstallations/Source/Library/Public/FIRInstallationsAuthTokenResult.h
Outdated
Show resolved
Hide resolved
FirebaseInstallations/Source/Library/Public/FIRInstallationsAuthTokenResult.h
Outdated
Show resolved
Hide resolved
FIRApp *app = [self createAndConfigureAppWithName:appName]; | ||
FIRInstallations *installations = [FIRInstallations installationsWithApp:app]; | ||
|
||
XCTAssertEqualObjects(installations.appID, app.options.googleAppID); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this should fail right now based on the information in the setUp
method and the helper FIRApp
method below. Perhaps having a FIROptions
creation helper would help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ryanwilson It's not failing now, though, I think it is worth to understand why :) Why do you think it should fail?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops nevermind, you're right. I was thinking this was comparing against self.installations