If I use any of the CRUD methods of SocialDataService (eg: AddComment), I find that even once the POST has returned successfully SharePoint has not actually processed the change. By that I mean that a quick call to GetCommentsOnUrl will return the old data, even though I am clearly making my request only after receiving a reply.
Is there a specific delay time I can wait to be sure SP has had time to process the change? If I'm using AJAX to perform changes to a page (which could in the meantime have also been changed by other users) I'd like to present the most up-to-date version, so how long do I wait before re-polling the web service?
edit: longer than 1 second, less than 1.5 is this a server setting or something?
Another pointless SP question, answer then is 1.5s. Feel free to post an answer if you know anything about this issue and I'll swap the check-mark.
The social data service uses this user profile synchronization service in the background:
User Profile Service Application – Social Rating Synchronization Job
The service is set to run every hour OOTB.
Related
I made a request to Google to use their Business Profile API, but the response from them can take up to two weeks. Is it possible to have access to a development version of the API so I can start coding and make tests without having to wait for their answer ?
Unfortunately this is not possible, as per this documentation it is a requirement to get approval first.
Developing a SPA in the frontend (with Vue.js) which consumes endpoints from a (Laravel) API in the backend introduces some challenges that need to be tackled:
1. How to sync deployment when introducing new backend/frontend code
If the code is separated in two VCS repositories (frontend/backend) it can be challenging to sync deployment of both frontend and backend making sure that both finish at the exact same time. Otherwise this can lead to unexpected behaviour (e.g. calling endpoints that are not yet deployed or have changed). Anyone came up with a great solution for this? What is your best practice to tackle this problem? What if versioning every little change is not an option?
2. How to make sure that the frontend code of the SPA is being refreshed after deployment?
So you managed to keep your deployments in sync (see problem 1.), but how do you make sure that the SPA code of every currently active end user is being refreshed? With webpack code splitting enabled, the application might break immediately for users that are currently using your app in between a deployment.
How do you make sure that your users are being served the latest JS without having them reload the entire application on every request? What are best practices (besides forcing the user to refresh the entire page via websockets)? Are there solutions that allow currently active users to keep using the application without being forced to refresh while they might just finished something that's ready to be saved?
I am very interested in your findings, learnings and solutions!
1. How to sync deployment when introducing new backend/frontend code
The best practice here is to keep the backend and frontend in the same repo. You can, of course, extract some reusable code out of them to use in other projects but the code base should ideally be in the same repo or you will keep facing these frustrating code sync issues. Even if you look at popular Laravel libraries - they all have the frontend and backend in the same repo.
If that's not option, I would suggest that you use a versioning system that can link the versions of both repos. Yep, that means versioning every little change!
2. How to make sure that the frontend code of the SPA is being refreshed after deployment?
Usually, I'd avoid doing stuff to force a refresh on the client codebase but if you have long user sessions, it may actually make sense.
To do that, you can use any web socket implementation (such as Pusher) and have your CI notify the frontend through web sockets of any deployment. The frontend can then queue a page refresh. Check out this article on how to implement.
The two questions are tightly coupled and can't be answered separately in my opinion. I have some possibile strategies to deal with such a scenario:
1. Never introduce breaking changes in the API
API deployments should be incremental without breaking anything for users using the previous version. In this way you can simply push the changes on your backend and when the backend deployment is completed you deploy the frontend. Easily achieved if you have separate projects.
This can be performed for major releases by prefixing the API with the version:
https://website.url/api/v${version}/${endpoint}
while minor deployments should only be minor adjustments/bugfixes that do not break frontend functionality.
This approach is the best because it ensures absolutely no downtime in the user activity, but requires additional work and may not be feasible in many projects. If the backend does not introduce breaking changes, you can implement a simple polling system (with a long timespan, such as minutes) from the frontend that detects if a reload in necessary to load the new frontend deployment.
2. Standard response for outdated requests
Each request from the frontend includes an information about the version in use by the frontend. It could be a standard header, a param, whatever. You should wrap your requests in a function that add the information before sending the request itself.
If the server detects a request from an outdated frontend, it returns a standard response, such as:
{
"error": "update required"
}
The frontend detects the error and reload the page
I honestly don't like this approach, because the request may be a POST request with some form data and a page reload may lose the user all their input, which is annoying.
1. How to sync deployment when introducing new backend/frontend code
With a staging environment where you run both test suites before pulling on production.
2. How to make sure that the frontend code of the SPA is being refreshed after deployment?
Don't just break your API. Implement a grace period. For example, you could check for updates on every request, then notify the user that a new version is available so that they have to click a button at their earliest convenience. Record the used client version in your DB. Once all your users are updated, you can delete the old endpoints.
We have Intermec CK71 mobile devices (WiFi). There will always be a scenario in which the device sends a request (GET, PUT, or POST), then loses connection. What methods can we use to prevent duplicate PUTs or POSTs? How does the client device know whether or not the server processed its request before losing the connection?
I have seen similar posts like this but the marked answer doesn't go into much detail. I'm not even sure where to begin. Should I be looking into caching (ETag, last modified), or some type of handshaking?
The client device has the .Net Compact Framework 3.5 on it and is hitting the server via its Web API 2 endpoints.
If someone can point me to the right direction or offer any suggestions it would be much appreciated. Thanks.
I am not using REST but as far as I read the information there is no easy way to get an acknowledge and avoid duplicate POST.
As with other high level API frameworks you are tied to what the API offers and it looks like the designers did not think about connection aborts.
The easiest way to workaround this seems to use an unique ID with every post and check the server for knowing these UID before re-posting. If the server does not response with OK for an POST, you have to assume the connection has broken or other things went wrong. Then query the server for the UID you posted to know if the pervious POST was succesful before you try another POST with the same data and UID.
Possibly there is some transaction encapsulation available with REST as available for sql server. A 'transaction' protocol would ensure that a POST has been processed succesfully or will be 'rolled' back, if something failed.
Sorry, but I do not know much about REST.
We are developing a social networking iOS application. The application loads lots of data from back end server. I have following doubts which is still unclear .Please help
What is the best approach for handling these much data from back end server?.
How does social networking mobile applications like facebook loads and update friends data?
Does these kind of application uses a local database to store these data?? If so when is the values in the local database updated?
Is making an synchronous call on a separate thread same as making an asynchronous server call?
Please provide your suggestions.Thanks in advance
Ideally, load data "on demand". Request from the server the data the user is seeing at the moment, or that you think she will see soon. Also, request data in batches (for example, last 50 posts, or post between certain dates).
Considering the answer above, Facebook does something similar. The key is to be smart on the server side. Let the client ask for a feed, for example. The server returns the last 50 posts and a "next page" attribute. The client can store that attribute and when the user scrolls down to the last post, send a request to the server asking for more news and passing the "next page" attribute that the server previously returned. The server of course will return a new "next page" with the new request. In this way, what is returned to the client is decided by the server.
Yes, you should use a local database which acts like a client cache. This is used to present the data that was shown to the user the last time she opened the app, so that you can show something while the request is loading from the server. You should update your database when the server sends a response to your request. This is also valid for friend lists, messages, etc. Don't forget, though, that the server has he most up-to-date information and the client database is mostly a cache to display temporary information.
Not exactly the same but for your use case it will be very similar. Ideally some operating systems provide low level asynchronous network operations, which is much better than handling it on your code with a background thread.
I am new to webOS development. I have one app in the app store and in the next update to the app I would like to be able to identify the age of users, their location, how long they use the app, which features they use the most/least and then store that data in a database. How do I do this? Many thanks in advance for your help.
Well, that's a pretty big question. Here's an outline of what to do, with some notes.
First, you're probably not going to be able to get age unless you ask the user directly and they tell you. Also, you're only going to get location if the application is location-aware and the user permits you to collect that data (when you install a location-aware application, it asks the user if they're okay with the fact that the application will be able to get their location).
As for how long they use the app and which features they use, that's easier. Depending on the granularity you need/want to capture, you can just record time stamps when a user starts and stops using a particular feature, such as when scene activate and deactivate methods fire. As long as you store feature name and timestamp, that should give you what you're looking for.
Then comes to question of collection. However you store it in the app, you have a couple of choices for how to get it out of the app. Unless you can get your users to just email the data to you, probably the easiest thing to do would be to create a web app (possibly with no user facing output, since you're just using it to collect data) using something like Google App Engine that gives you a URL you can send a POST request to using an HTTP request. Depending on how you set it up, it could do the request every time you collect a timestamp (bad for battery use, though), just occasionally, or only when the app is doing cleanup (possibly a problem if you don't get the request off in time).
I'd recommend taking a look online at how people do this type of thing in iPhone apps to get a good sense of how to do this type of thing. If you hit problems getting particular things to work, you can of course come here to StackOverflow with specific coding questions.