Skip to content
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

Removing SubscribeSessionFactory and SubscriptionConfiguration #162

Merged
merged 15 commits into from
Mar 28, 2024

Conversation

jguz-pubnub
Copy link
Contributor

@jguz-pubnub jguz-pubnub commented Mar 19, 2024

refactor(subscribe): removing SubscribeSessionFactory with SubscriptionConfiguration
refactor(subscribe): making SubscriptionSession class an internal

Copy link
Contributor

@parfeon parfeon left a comment

Choose a reason for hiding this comment

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

It looks like there is some place for small improvement and some question about URLSession lifetime in container.

private extension DependencyContainer {
func resolveSession(session: SessionReplaceable, with operators: [RequestOperator?]) -> SessionReplaceable {
session.defaultRequestOperator == nil ? session.usingDefault(requestOperator: MultiplexRequestOperator(
operators: operators.compactMap { $0 }
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a private extension and can be sure of what we are passing, do we really need to map values again? We did it once when called resolveSession.
Can we leave compactMap only in resolveSession and just pass arrays from defaultHTTPSession, httpSubscribeSession, and httpPresenceSession?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed, you're right. I will send you the updated version shortly.

Comment on lines +48 to +50
container.register(value: session, forKey: DefaultHTTPSessionDependencyKey.self)
container.register(value: subscribeSession, forKey: HTTPSubscribeSessionDependencyKey.self)
container.register(value: fileSession, forKey: FileURLSessionDependencyKey.self)
Copy link
Contributor

Choose a reason for hiding this comment

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

Actually, this one bothered me for a pretty long time: what further actions should be done if session will get invalidated (there are numerous non-manual reasons for it)?
Same with session which is stored in container by default, how invalidation handled for it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The concrete type for subscribe session, presence session, and regular session is the HTTPSession class. These values are retrieved from DependencyContainer in the PubNub's constructor . HTTPSession is a class (reference) type, so there's the same reference in the DependencyContainer and later in the PubNub class after assigning any session to the appropriate field. And also, what I'm considering right now after your comment is to store weak references in DependencyContainer and checking what's the impact. The idea is that you have to keep the value you resolved under the strong reference. For example, this is what happens in PubNub class.

You're right that for example, current networkSession used for regual requests different than subscribe/heartbeat is exposed as a public property. It means that the caller might invoke invalidateAndCancel() method that was designed in SessionReplaceable/HTTPSession and the consequence is that you cannot reuse such a session. On the other hand, this happens only on explicit caller's request and we can't do anything about it. They should be aware that creating the PubNub client from scratch is necessary in this use case.

@jguz-pubnub jguz-pubnub requested a review from parfeon March 25, 2024 12:33
Copy link
Contributor

@parfeon parfeon left a comment

Choose a reason for hiding this comment

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

LGTM!

@jguz-pubnub jguz-pubnub merged commit 34bcc9f into master Mar 28, 2024
21 checks passed
@jguz-pubnub jguz-pubnub deleted the feat/di-injection branch March 28, 2024 10:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants