Better Message Field Documentation

[SarasArya]

I see there are too many message fields, but I don't see any documentation for the above. For example timeToLive. I understand what it means but from where, what is the time in seconds/ minutes/hours. What is that field? There are many such fields which require better documentation, as it not obvious. Hopefully, it will be addressed in the next release.

[SarasArya]

This is the document which metions everything. A quick mention in your comments won't hurt anyone.

[hypesystem]

You are absolutely right :smile: This is something we are working on. If you are interested you are very welcome to help :-)

[SarasArya]

Let me know in any way I could help. I would like to know how it works. Do you guys collect all issues address them in the next release or anybody could create a pull request. mention the changes and it is committed after it's peer reviewed ?

[hypesystem]

@eladnava and I have merge access, so everything is reviewed before it is merged.

We try to release as often as possible, so as soon as a PR is merged, re make a new release. There are too many issues to depend on solving all of them before a new release. The stuff that gets made first is the stuff that people contribute first :)

@eladnava has been talking about wanting to write some better documentation, too, so maybe you two could gang up and figure out what the best approach is? :smile:

[SarasArya]

@eladnava Haha... I know him, like I read his blogs and asked him for help with some Nginx issue. Will message him get in touch on this. Thanks :)

[hypesystem]

I think an FAQ would be very valuable. We do see the same questions quite often. For example, people using the old client-side code (they have not yet migrated to GcmListenerService) who have trouble displaying notifications with the notification field (because it isn't supported in that version).

[SarasArya]

An FAQ with what are the parameters that Google Accepts, what we are sending(in node-gcm in what format) and what parameters should be in their library which is accepting for it to work with. Comprehensive details on these I guess would go a long way.

[eladnava]

@SarasArya @hypesystem I think creating a table similar to this for documenting the GCM request params would be a great start.

Let me know if you have spare time for this @SarasArya, if not, it's definitely something on my to-do list.

[SarasArya]

@eladnava I completely work from home so time is not an issue. I think the table idea is good. We should do it. Also, list the features like I found out from the code that registration Id can only have keys named as registrationIds, 'registrationTokens, topic, notificationKey. Now I wouldn't know this if I don't read the source code, which I always do, so not an issue but for me but, for other less geeky users. We should definitely do this

[eladnava]

@SarasArya Absolutely. Let's see if @hypesystem has anything to say, if not, you've got a green light!

I think you can copy the Notification payload option table and add the new "Message option table" under Usage.

Please follow the writing conventions expressed in the rest of the README.md so that it fits in with everything. :+1:

[hypesystem]

I think this sounds super :+1:

[eladnava]

@SarasArya Did you get a chance to get started on this? If not, let me know, I may have some free time soon.

[SarasArya]

Yes, I did get a chance it was half done, completing it. Should I paste the table here itself so that it can be reviewed or somewhere else?

[eladnava]

@SarasArya The contribution should be submitted as a Pull Request so that we can merge it easily into the README.md.

However, if you'd like for us to review it first, you can paste it here.

[eladnava]

@SarasArya Did you get a chance to finish this? If not, let me know, I may have some free time soon.

[eladnava]

@SarasArya Pinging you one last time, do you think you'll have the chance to work on this?

[SarasArya]

@eladnava I don't think so. Been working on something entirely different. Sorry for wasting your time.