managing push notification payload

[wdcurry]

I read the other issue dealing with handling pushes, and respect the ideal of keeping this clean, but most new apps will have notifications, and as such, one tweak to manage this:

Allow one dictionary param to be set into the TW notice. Have it get sent to the completion so allow us easy access to the required data that the push represents.

I don't see this as diluting the focus at all.. just thinking aloud, determining if this is the way to go, as this is critical for my needs. Cheers.

[terryworona]

So you want a dictionary property added to each instance of the message view?

Perhaps I'm misunderstanding the need, but model/payload information shouldn't be included in any view-specific classes; basic MVC.

Model-specific logic can exist outside the "show" call and be referenced within the tap callback. Wouldn't this suffice?

[cdzombak]

I'd be interested in hearing more about the use case here; I suspect there's another way to solve your problem without adding model state to this view.

(For sake of argument, I've been trying for a few minutes to come up with a UIKit API that might provide some sort of precedent for this pattern, but I can't think of any.)

[wdcurry]

I think the use-case is quite standard for moderately complex apps. A push notification is received and processed, while the app is active. The user may or may not want to respond. So we toss out a notice. If the user taps it, we know they are engaging, thus we must act on the payload provided by the original push. I suspect a simple __block dictionary will manage this process. I think i was getting confused between reviewing a bunch of libraries today and had this one mixed with another that centralized responses rather than a local block.

So.. __block the payload dictionary, await the engagement and with the code block use the __block variable.. sound about right? (i am a moderate newbie to this platform)

[terryworona]

To re-iterate, model and view should remain mutually exclusive.

A MVC solution:

appDidReceiveRemoteNotification:(id)notification...{
     id payload = notification.payload;
     if (payload.notificationType == type1){
        [[TWMessageBarManager sharedInstance] show... callback:{
            // user clicked - we have all info we need from the payload
            [self presentViewOfType:type1 withPayload:payload];
        }];
    }
}

[wdcurry]

thanks terry, similar to what i described after i explained my brain-fart earlier. Only diff is that i was under the assumption only __block vars are accessible inside of callback blocks?

[terryworona]

@wdcurry correct, so just declare a few __block vars prior to presenting the message:

_block NSDictionary *payloadBlock = notification.payload;

[cdzombak]

Only diff is that i was under the assumption only __block vars are accessible inside of callback blocks?

No, __block doesn't have anything to do with accessibility. You can capture variables inside callback blocks without any special notation. See this Stack Overflow answer for some additional explanation.

[wdcurry]

thanks kindly cd.. i enjoy learning something new every day ;)

[cdzombak]

i enjoy learning something new every day ;)

As do I 😄