Skip to content

Conversation

@marcin-cebo
Copy link
Contributor

@marcin-cebo marcin-cebo commented Oct 15, 2025

feat: Added limit and offset parameters for hereNow

Added limit and offset parameters for hereNow. Number of returned users per channel by default is limited to 1000. Breaking change

fix: Single-channel hereNow with includeUUIDs=false now returns channel data

Single-channel hereNow with includeUUIDs=false now returns channel data in the channels map for consistency with multi-channel behaviour. Previously, the channels map was empty in this scenario, forcing reliance on totalOccupancy field only. Breaking change

fix: Removed possibility to use deprecated MPNS -Microsoft Push Notification Service. Breaking change.

fix: Added deprecation warning for GCP and old APNS PushType.

fix: In case FCM is chosen as PushType type REST query param gets fcm value instead of gcm.

}

@Test
public void testGlobalHereNowWithOffset() throws PubNubException {
Copy link
Contributor

Choose a reason for hiding this comment

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

Are you sure global HereNow supports limit and offset parameters?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, somehow it does.

return HereNowImpl(
jsPubNub,
createJsObject {
// todo handle limit and offset
Copy link
Contributor

Choose a reason for hiding this comment

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

Is additional work required due to this comment?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, additional work is required for JS and Swift part of KMP. But will be handled in separate PR

"Channel and/or ChannelGroup contains empty string which is not allowed.",
),

HERE_NOW_OFFSET_OUT_OF_RANGE(
Copy link
Contributor

@jguz-pubnub jguz-pubnub Oct 15, 2025

Choose a reason for hiding this comment

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

It’s better to use UInt for limit and offset to ensure they’re never negative, which eliminates the need for extra validations. Otherwise, keep them as Int and just document that the values must be greater than zero. No need for defensive checks.

Copy link
Contributor Author

@marcin-cebo marcin-cebo Oct 17, 2025

Choose a reason for hiding this comment

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

Good point. Uint could solve validation problem but we don't use Uint because code is also used by Java users and in Java there is no Uint and it would not comfortable to convert int to Uint. Documentation contains info about them being greater than zero.

No need for defensive checks.

What problem do you see with those checks?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

After discussion on Daily I will remove some validations.

@jguz-pubnub
Copy link
Contributor

Change the PR title that reflect the scope of changes

@marcin-cebo
Copy link
Contributor Author

@pubnub-release-bot release kotlin as v11.0.0

@marcin-cebo marcin-cebo merged commit 5d711bc into master Oct 21, 2025
8 of 13 checks passed
@marcin-cebo marcin-cebo deleted the mc/gcm-byebye branch October 21, 2025 09:10
@pubnub-release-bot
Copy link
Contributor

🚀 Release successfully completed 🚀

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.

3 participants