Skip to content

Conversation

maksymmalyhin
Copy link
Contributor

  • public API
  • FIS instance config
  • basic tests


- (FIRApp *)createAndConfigureAppWithName:(NSString *)name {
FIROptions *options = [[FIROptions alloc] initInternalWithOptionsDictionary:@{
@"GOOGLE_APP_ID" : @"1:1085102361755:ios:f790a919483d5bdf",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this real?

Copy link
Contributor Author

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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

123?

Copy link
Contributor Author

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

Copy link
Member

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 :)

FIRComponentCreationBlock creationBlock =
^id _Nullable(FIRComponentContainer *container, BOOL *isCacheable) {
*isCacheable = YES;
FIRInstallations *installations = [[FIRInstallations alloc] initWithApp:container.app];
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

@maksymmalyhin maksymmalyhin Jun 4, 2019

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.

Copy link
Contributor Author

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];
Copy link
Member

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

Copy link
Contributor Author

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:

  1. Will I need to configure a FIRApp to test singleton?
  2. Do we run tests concurrently?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. 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.
  2. Yes. Tests in other files run concurrently, but test cases in the same class run synchronously.

Copy link
Contributor Author

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:

Copy link
Contributor

@charlotteliang charlotteliang left a 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.

@maksymmalyhin
Copy link
Contributor Author

@chliangGoogle Good point! I am going to add it later on.

}

- (void)installationIDWithCompletion:(FIRInstallationsIDHandler)completion {
completion(@"123", nil);
Copy link
Member

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
Copy link
Member

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.

Copy link
Contributor Author

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.

FIRApp *app = [self createAndConfigureAppWithName:appName];
FIRInstallations *installations = [FIRInstallations installationsWithApp:app];

XCTAssertEqualObjects(installations.appID, app.options.googleAppID);
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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

@maksymmalyhin maksymmalyhin merged commit 422f5c4 into mm/fis-master Jun 5, 2019
@maksymmalyhin maksymmalyhin deleted the mm/fis-api branch June 5, 2019 18:02
@firebase firebase locked and limited conversation to collaborators Oct 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants