Return to Answer

Few things to take into account

Missleading names

Then I'd make a function called User.update() that just pulls userdata from the server and populates the User class properties. This is the only function that would be allowed to write over the User properties.

Whoever is familiar with Active Record design pattern would be fooled by the name of the method.

The name could make us belive that we are pushing changes to the server, but in reality -according to the question- we would be doing the opposite!!!

If we are pulling the latest User representation, then we should consider changing the name of the method for something like retrieve , refresh or reload. If we are really synchronizing, sync would be more acurate than update.

Too many requests

I would run the User.update() function during times such as:

• App launch
• App re-opened from sleep
• Profile update
• After in-app-purchase
• etc.

If we need to retrive the User so often, it probably means that we shouldn't hold all its state. Or at least not completely.¹

Ideally, we request the latest data when there's an evidence of changes and we need to be aware of them. For example, after specific business operations.

Otherwise, we come to realise that any event|action|moment is as good as any other. Such randomness, eventually, lead us to retrieve half DB without consistent reasons.

If App re-opened from sleep is a good moment for refreshing the User, why shouldn't it be good for any other entity?

Remember that connections consume resources and they also have an impact on the data plan. So, I would consider constraining the requests to the essential.

Consider holding the URIs instead of the complete representantion. For example, we could retrieve and hold data that is unlikely to change.

GET /user/1
HTTP 200 OK
{
  "fullname":"Han Solo"
}

Store the fullname and hold the URIs of those resources sensibles to changes. For example, /user/1/profile or /user/1/score.

Later, we can retrieve these resources only when the business need them, and not randomly after certain events of the application.

Finally, consider who else is going to be changing the User beside the user himself. If there's no concurrency over the user' data, probably the client application always has the most up-to-date representation.

^{1: What we do with the local storage is caching. If we have to expire the cache often, it means either we don't need cache at all or we are caching the wrong data.}

Few things to take into account

Missleading names

Then I'd make a function called User.update() that just pulls userdata from the server and populates the User class properties. This is the only function that would be allowed to write over the User properties.

Whoever is familiar with Active Record design pattern would be fooled by the name of the method.

The name could make us belive that we are pushing changes to the server, but in reality -according to the question- we would be doing the opposite!!!

If we are pulling the latest User representation, then we should consider changing the name of the method for something like retrieve , refresh or reload. If we are really synchronizing, sync would be more acurate than update.

Too many requests

I would run the User.update() function during times such as:

• App launch
• App re-opened from sleep
• Profile update
• After in-app-purchase
• etc.

If we need to retrive the User so often, it probably means that we shouldn't hold all its state. Or at least not completely.¹

Ideally, we request the latest data when there's an evidence of changes and we need to be aware of them. For example, after specific business operations.

Otherwise, we come to realise that any event|action|moment is as good as any other. Such randomness, eventually, lead us to retrieve half DB without consistent reasons.

If App re-opened from sleep is a good moment for refreshing the User, why shouldn't it be good for any other entity?

Remember that connections consume resources and they also have an impact on the data plan. So, I would consider constraining the requests to the essential.

Caching only the essential

Consider holding the URIs instead of the complete representantion. For example, we could request and hold data that is unlikely to change.

GET /user/1    HTTP/1.1
HTTP 200 OK
{
  "fullname":"Han Solo"
}

Caching the fullname and hold the URIs of those resources sensibles to changes. For example, /user/1/profile and /user/1/score.

Later, we can retrieve these resources only when the business need them instead of randomly after certain events of the application.

Finally, think who else is going to be changing the User beside the user himself. If there's no concurrency over the data, probably the client application always has the most up-to-date representation.

^{1: What we do with the local storage is caching. If we have to expire the cache often, it means either we don't need cache at all or we are caching the wrong data.}

A few things to take in account

Missleading names

Then I'd make a function called User.update() that just pulls userdata from the server and populates the User class properties. This is the only function that would be allowed to write over the User properties.

Whoever is familiar with the Active Record design pattern would be fooled by the method's name.

While we may expect to be pushing changes to the server, in reality -according with the question- we would be doing right the opposite!!!

If we are pulling the latest User representation, then we should consider changing the method name to something like retrieve , refresh or reload. If we are really synchronizing, sync would be more precise than update.

Too many requests

I would run the User.update() function during times such as:

• App launch
• App re-opened from sleep
• Profile update
• After in-app-purchase
• etc.

If we need to retrive the User state so often, it probably means that we shouldn't hold its state. Or -at least- not completely.¹

Ideally, we should request for the latest data when there's any evidence of changes and we want/need to be aware of the them. For instance, after specific business operations.

Otherwise, we will come to realise that any event/action/moment is as good as any other. Such randomness, eventually, lead us to retrieve half DB with no consistent reasons.

If App re-opened from sleep is a good moment for a User refresh, why should not be good for any other entity?

Keep also in mind that connections consume resources and they also have an impact on the user's data plan. So, I would constrain the calls to the server to the essential.

Consider holding the URIs instead and retrieve them as soon as you need'em, but don't hold the representantations if you find yourself synchronizing them often.

  For example, we could retrieve and hold data that is unlikely to change

GET /user/1
HTTP 200 OK
{
  "fullname":"Cheewacka"
}

And just hold the URIs of those resources sensible to be retrieved often. For instance, /user/1/profile or /user/1/score.

Retrieve these resources only when the business need them, and not randomly after random application events. Be consistent.

Finally, consider who else is going to be changing the User beside the user itself. If there's no concurrency, probably the client application always has the most up-to-date representation. Or part of it.

^{1: Keep in mind that, what we do with the local storage is caching. If we have to expire the cache often, it probably means either we don't need cache at all or we are caching the wrong data.}

Few things to take into account

Missleading names

Then I'd make a function called User.update() that just pulls userdata from the server and populates the User class properties. This is the only function that would be allowed to write over the User properties.

Whoever is familiar with Active Record design pattern would be fooled by the name of the method.

The name could make us belive that we are pushing changes to the server, but in reality -according to the question- we would be doing the opposite!!!

If we are pulling the latest User representation, then we should consider changing the name of the method for something like retrieve , refresh or reload. If we are really synchronizing, sync would be more acurate than update.

Too many requests

I would run the User.update() function during times such as:

• App launch
• App re-opened from sleep
• Profile update
• After in-app-purchase
• etc.

If we need to retrive the User so often, it probably means that we shouldn't hold all its state. Or at least not completely.¹

Ideally, we request the latest data when there's an evidence of changes and we need to be aware of them. For example, after specific business operations.

Otherwise, we come to realise that any event|action|moment is as good as any other. Such randomness, eventually, lead us to retrieve half DB without consistent reasons.

If App re-opened from sleep is a good moment for refreshing the User, why shouldn't it be good for any other entity?

Remember that connections consume resources and they also have an impact on the data plan. So, I would consider constraining the requests to the essential.

Consider holding the URIs instead of the complete representantion. For example, we could retrieve and hold data that is unlikely to change.

GET /user/1
HTTP 200 OK
{
  "fullname":"Han Solo"
}

Store the fullname and hold the URIs of those resources sensibles to changes. For example, /user/1/profile or /user/1/score.

Later, we can retrieve these resources only when the business need them, and not randomly after certain events of the application.

Finally, consider who else is going to be changing the User beside the user himself. If there's no concurrency over the user' data, probably the client application always has the most up-to-date representation.

^{1: What we do with the local storage is caching. If we have to expire the cache often, it means either we don't need cache at all or we are caching the wrong data.}

Several things to take in account

Missleading names

Then I'd make a function called User.update() that just pulls userdata from the server and populates the User class properties. This is the only function that would be allowed to write over the User properties.

Whoever is familiar with the Active Record design pattern would be fooled by the method's name.

While we might expect to be pushing the changes to the server  , the reality -according with the question- would be right the opposite!!!

If we are pulling the latest User representation, then we should consider changing the method name to something like retrieve , refresh or reload. If we are really synchronizing, sync would be more self-descriptive than update.

Too many pulls

I would run the User.update() function during times such as:

• App launch
• App re-opened from sleep
• Profile update
• After in-app-purchase
• etc.

If we need to retrive the User state so often, it probably means that we should not hold its state in the locale storage. Or -at least- not completely.¹

Ideally, we do pull only when has been proven that the User state has been modifed and we need its current state. Otherwise any event on the client-side is as good as any other. Such randomness eventually lead us to retrieve half DB with no consistent reasons.

If App re-opened from sleep is a good moment for a User refresh, why should not be good for any other entity?

Keep also in mind that connections consume a lot of resources and it also as an impact on the user's data plan. So I would constrain HTTP calls to the essential.

Consider holding the proper URIs and retrieve them as soon as you need'em, but don't hold the representantations if you find yourself synchronizing them often.

For instance, we can retrieve and hold data that is unlikely to change

GET /user/1
HTTP 200 OK
{
  "fullname":"Cheewacka"
}

And hold the identifiers of those resources sensible to be retrieved often. For instance, /user/1/profile or /user/1/score.

Do retrieve these resources only when the business need them and not randomly after random events of the application. Be consistent.

Finally, consider who else is going to be changing the User beside the user itself. If there's no concurrency, probably the client application always has the most up-to-date representation. Or part of it.

^{1: Keep in mind that, what we do with the local storage is caching. If we have to expire the cache often, it probably means either we don't need cache at all or we are caching the wrong data.}

A few things to take in account

Missleading names

Then I'd make a function called User.update() that just pulls userdata from the server and populates the User class properties. This is the only function that would be allowed to write over the User properties.

Whoever is familiar with the Active Record design pattern would be fooled by the method's name.

While we may expect to be pushing changes to the server, in reality -according with the question- we would be doing right the opposite!!!

If we are pulling the latest User representation, then we should consider changing the method name to something like retrieve , refresh or reload. If we are really synchronizing, sync would be more precise than update.

Too many requests

I would run the User.update() function during times such as:

• App launch
• App re-opened from sleep
• Profile update
• After in-app-purchase
• etc.

If we need to retrive the User state so often, it probably means that we shouldn't hold its state. Or -at least- not completely.¹

Ideally, we should request for the latest data when there's any evidence of changes and we want/need to be aware of the them. For instance, after specific business operations. 

Otherwise, we will come to realise that any event/action/moment is as good as any other. Such randomness, eventually, lead us to retrieve half DB with no consistent reasons.

If App re-opened from sleep is a good moment for a User refresh, why should not be good for any other entity?

Keep also in mind that connections consume resources and they also have an impact on the user's data plan. So, I would constrain the calls to the server to the essential.

Consider holding the URIs instead and retrieve them as soon as you need'em, but don't hold the representantations if you find yourself synchronizing them often.

For example, we could retrieve and hold data that is unlikely to change

GET /user/1
HTTP 200 OK
{
  "fullname":"Cheewacka"
}

And just hold the URIs of those resources sensible to be retrieved often. For instance, /user/1/profile or /user/1/score.

Retrieve these resources only when the business need them, and not randomly after random application events. Be consistent.

Finally, consider who else is going to be changing the User beside the user itself. If there's no concurrency, probably the client application always has the most up-to-date representation. Or part of it.

^{1: Keep in mind that, what we do with the local storage is caching. If we have to expire the cache often, it probably means either we don't need cache at all or we are caching the wrong data.}