added createdAt property for issue #43

[netbull]

quick fix for issue #43 until the backend returns real lifetime of the token

[stefanpolzer]

@netbull I'm not sure if this is the right way e.g. in my case some response go into a queue first.

So the createdAt have nothing to do with the validity. The right naming should be parsedAt but I'm not sure if anyone needs that...

We can't fix this on the SDK site along the only good way is to get it from the Server.

[netbull]

@stefanpolzer it's not the right way.

this is temporary solution in order to know when the token was created and the validity check can be if it's less than X minutes, recreate the token.

The right way should be if the response returns info until when is valid /when it expires/ and the validation will be much easier and correct

I don't get it why you may need to put the response in a queue... O_O if you have many request to process in the queue and theoretically until the time to process a response the token is expired what will happen?

[stefanpolzer]

Ask a for a new one... but this more a theory...

If it's only a temporary solutions than think twice... one day there is the info send by the server will you remove it and bracket some backwards compatibility or will you keep it there forever.

BTW way do you have included a setter? How should be allowed to change the createdAt property?

[stefanpolzer]

And because this is not really a value send by the server I would put it in the abstract class as a general value available for all responses.... make more sense to me

[netbull]

@stefanpolzer yes, that's better... I guess

the setter was auto generated...dumb thing..

[stefanpolzer]

Yes this is a workaround that can stay there 😉 even if we get the real valid till value

[stefanpolzer]

@netbull @tobiaslins one more topic to think about. Every value in all the Response Classes are primitive data types link sting, int, bool now we have a Object...

[stefanpolzer]

Usually I prefer Object, but because others may want to us it as well I would just go with the Unix Timestamp int time()
Than ever body can use the object that want's... e.g. I prefer Carbon over DateTime

[stefanpolzer]

@tobiaslins what do you think?