Allow nickname to be specified in subscription request

I wanted to add an XEP-0172 nickname (distinct from XEP-0144, such helpful naming eh :wink: ) to subscription requests. The method to sendSubscriptionRequest is in Smack Core however, and the Nick ExtensionElement in Smack-Extension, meaning I could not simply import it.

I got around this by creating a setter which could be called in the client code with knowledge of all of Smack to set a global setter for this method:

    public interface RosterPresenceStanzaEnhancer {
        void addNick(PresenceBuilder stanza, String nick);

    public void setRosterPresenceStanzaEnhancer(RosterPresenceStanzaEnhancer stanzaEnhancer) {
        rosterPresenceStanzaEnhancer = stanzaEnhancer;

where the enhancer is called within sendSubscriptionRequest like so:

if (rosterPresenceStanzaEnhancer != null) {
            rosterPresenceStanzaEnhancer.addNick(presenceBuilder, nick);

Needless to say this is pretty ugly. Is there an existing paradigm for knowledge of non Smack-Core classes?

I assume you mean smack-im, instead smack-core, since sendSubscriptionRequest(BareJid) is part of the Roster class, which is in smack-im. :slight_smile:

What you want is to create a method.

Roster.sendSubscriptionRequest(BareJid, Collection<ExtensionElement> elements)

we could even consider (potentially additionally) creating

Roster.sendSubscriptionRequest(BareJid, Collection<SubscriptionRequestExtensionElement> elements)

where SubscriptionRequestExtensionElement is a marker interface for extension element that are supposed to be added to the subscription request.

I did mean smack-im :upside_down_face::upside_down_face:

Yeh, keeping it general is cleaner than fudging knowledge of the Nick class specifically, and the calling code will have the global Smack knowledge. Great. I’ll look to get that changed in our fork and upstream.

I have 3 open PRs on Smack at the moment, do you need anything from me to progress?

I am sorry, but I am currently overloaded with work. I suggest you pick the PR of yours with the best effort/benefit ratio and we focus on this PR first. Then we pick we next one and handle one PR at a time this way.

That’s fine, no real hurry but good to get these in. :slight_smile: I think I’ve responded to all your comments on Xep 0249 support by MF1-MS · Pull Request #535 · igniterealtime/Smack · GitHub , so I’d just need to squash to a single informative commit message and merge if you’re now happy with it.

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.