Saved notifications: link notifications to devices

[mbargiel]

The Admin currently allows creating boardcast Notifications only since there's no way to push the notifications to a subset of all devices. It would be easy to link notifications to devices so the Push Now! button can send the notifications to specific devices rather than broadcasting.

[stephenmuss]

You are right about this.

Originally for me the admin was a feature for all the non developers who were responsible for sending notifications for an app. I wanted to keep it as simple as possible. I thought it would be easy enough for developers to plug in their own custom interface for a more controlled experience.

That said, I can see the benefit in restricting notifications to particular devices in the admin but it needs to be done efficiently without blocking the UI when large numbers of devices are involved.

If we go down this path I think it needs to be well thought out and certainly much more flexible than the current offering.

[mbargiel]

The use of raw-id-fields might be useful for that, even if that's not the most user-friendly thing ever invented (but at least it's scalable). It should also be possible to clearly distinguish broadcast notifications with "targeted" notifications (for lack of a better name).

[stephenmuss]

Agreed. raw-id-fields is generally the approach I take in this type of situation.

The idea of targeted vs. broadcast notifications should work well IMO.

[habfast]

What's the status of this? Would you mind if I implemented this and created a pull request?

[stephenmuss]

Hi @habfast you're welcome to implement it and open a pull request.

[stephenmuss]

@habfast I also just created issue #17 which is related to this one.

If you are interested you can try tackling that one too while you're looking into this one.

[stephenmuss]

@habfast I'd suggest perhaps just focusing on this issue at the moment. There is already a definite requirement for it.

As for issue #17 it seems that there is still some room for further discussion and debate. It would be better to keep the two separate.

So there is nothing to stop you working on this issue. Feel free to fork and implement a solution and open a pull request.

Cheers.

[habfast]

@stephenmuss Aggreed. However I'm using this project for professionnal reasons, and I'm a little short on time to be able to do this . On the other hand, I did implement some HTTP-based RPC to send notifications, so that the django-ios-notification can be run on an independent server, as this was part of my requirements. If you have some interest in that, I could do a little code-shuffling and create a clean pull-request.

[stephenmuss]

No problem if you don't have time. At least the activity on the issue has reminded me that there is still some work to be done here.

As for the RPC stuff it sounds cool, but I'm not sure I think we should bring it in as part of django-ios-notifications. I'm already thinking of removing the current REST API section of code (for registering devices etc) in future releases as I think it can be better handled by developers using django-ios-notifications to suit their own purposes. I think the RPC stuff would fall under the same category.