Add updated_at field about fcm-django HOT 21 OPEN

For sure @mohitCodepy. Essentially, it is a datetime field which updates automatically with a new datetime everytime an FCMDevice entry is updated

from fcm-django.

Seems that date_created is enough for tracking expired tokens. Or @nachov99 is there specific case where that field could be helpful to have updated_at?

Maybe better instead of bloating models for all users that use that app, we could allow override models to users who needs that? It could be done with swapper. In the same way as it was done for django-cities

from fcm-django.

If you name the fields created and updated they will even be the same as TimeStampedModel from django-model-utils!

But is there's a reason for that? I though:

1. there's no needs to everyone who would like to use that package to pay extra to store data that not required in their DB.
2. and shouldn't be a limitation to store extra data if it's required according their business requirements

from fcm-django.

Yes, that would be a welcome addition. Pull requests welcome

from fcm-django.

@xtrinch , May I work on this ? If yes, please assign this issue to me and provide some description about the issue.

from fcm-django.

Tracking in #239, let's go with an override-able device model

from fcm-django.

On the other hand, it takes one param to DatetimeField to save the model creation date or modification date automatically: https://docs.djangoproject.com/en/4.2/ref/models/fields/#django.db.models.DateField

If you name the fields created and updated they will even be the same as TimeStampedModel from django-model-utils!

from fcm-django.

The official docs even recommend tracking the last activity of that token:

When stale tokens reach 270 days of inactivity, FCM will consider them expired tokens. Once a token expires, FCM marks it as invalid and rejects sends to it. However, FCM issues a new token for the app instance in the rare case that the device connects again and the app is opened.

Using the token prevents that inactivity and thus seems to be a valid use case to update the timestamp imo.

And another passage:

Retrieve registration tokens from FCM and store them on your server. An important role for the server is to keep track of each client's token and keep an updated list of active tokens. We strongly recommend implementing a token timestamp in your code and your servers, and updating this timestamp at regular intervals.

The last words in the last sentence explicitly recommend an update timestamp.

from fcm-django.