In game development with SignalR and MVC, I have to manage the player id's.
With MVC all Controllers is re created for each AJAX request so you can't store anything unless you use a database or store it in a cookie.
Does SignalR have any tools I can use for persisting something like playerIds for a game to ease it the situation?
You can't get the connection id's from SignalR, but you can register a ID per user on the OnConnected method. just override that function in your hub.
There might be a simpler way to do it, but one option is to pass the session key to JS, and from JS you can pass that session key (or any other unique identifier) back to the server on every command.
For example, while the user is first connected: OnConnected() -> gets the user unique id from JS and saves it locally to map each user to a unique id(possibly save that id as a group id so you can call send back msgs to that user according to the id).
After you that on each request sent to the hub you can attach the unique ID to it and then you can use it however you like.
I'm pretty sure you can find easier way to define a unique identifier and maybe a more suitable way to save your data in the hub.
Now that I think about it, you should also check this.
Related
I'm using socket.io in my app, and attaching a socket id to each user after login. I get that info on front end and when I'm trying to emit an event, it creates a new connection so every user gets a new socket id, but the old ids are stored on front end and I'm sending the data to that old ids. What is the solution? (I'm using Angular)
I've tried creating groups, but it really slows down the app because I have to create as many socket groups as every user's friends.
My suggestion to you to solve this problem is to use a unique ID for each user. This unique ID can be created and delivered to the user through rest api. The user puts his ID in an object before every connection to the socket. Your task is this. At the same stage of user connection, create an object for each user. In this object, there are two parameters. The first one is the user ID that does not change, and the second one is the user ID that changes. In this way, you have a list of objects that are inside Each object has two mentioned parameters, it is enough to compare the user using the socket ID loop and implement your logic and operations. Note, at the end of connecting the user, remove the user from the list.
I'm creating a TODO-list using React.
When the user fills all the fields and presses the ADD button, I want immediately add the item to the list, and then send this item to the server. Then, the server responses with the ID of this item in the database.
The problem is that my app uses item IDs to remember which items are selected at the moment. Also, I want to use IDs in the browser's address bar. But the item ID is being generated on the server, so I cannot figure it out before server responded.
What options do I have?
You can easily add items to a react list without relying on the server-side ID.
If you really need the ID generated by the back-end, I don't think this is possible.
You could of course use some temporary front-end ID (e.g. based on an educated guess) and replace that with the actual ID once the back-end responded, but that would obviously require some obscure bookkeeping and mapping.
It also depends on the way your ID's work. If an item-ID is a combination of the user and the item, the above should be feasible.
Im not sure we are on the same page but u can use local storage to save data and do your local stuff before server response
For a to-do list app, when the user creates a task, the back-end would need to return an ID to identify the task uniquely so that when the user deletes the task later on, the correct task can be referenced in the back-end.
But what if the user deletes the task before the back-end returns with the identifier?
Possible inelegant solutions i thought of:
prevent the user from deleting task until back-end returns the identifier
generate the identifier on the client side (perhaps with the user id + timestamp)
couple the creation and deletion actions together, assigning a temporary id on client side and using Promises to ensure correct deletion. (ugly solution for a Redux framework?)
A "clean" solution which could work well with Redux could be using a generated identifier on the client side.
So an user, create a task id is generated on the client and after is sent using AJAX.
I would recommend disabling the delete button until you get a response back from the server. I know there are more examples out there, but one example of this that I can think of is in the TFS portal. When you create a new User Story, the row gets added to the grid (at the top) immediately. And the api POST is sent to the server. And if you right-click that row immediately, you get a popup menu with a spinner. Then, after a second or so, the front-end gets the response back from the POST, and the popup menu is populated with two items (Add Task and Add Bug).
When a client logs in, i want to store inside a dictionary the ids of the clients / sessions as keys inside a dictionary mapped to some data (In case there is no need for a dictionary and meteor has a way to map a single variable with client specific data it would be even better).
I am not familiar with developing Meteor packages and Javascript at all, so my question is: Where do i put this dictionary so i can access it from everywhere on the server and where can i get the clients ids?
Wished behaviour:
1. Client logs in -> Server registers new client id
2. Client calls function on server
3. Inside the function the server gets the right data according to the clients id for further processing
Inside a package (https://github.com/steffow/meteor-accounts-saml) i set up a global variable but when i tried to access it from javascript, inside the imports/api directory, the global variable was undefined.
You could use the Presences package to store information about each logged in user, https://github.com/dburles/meteor-presence. It automatically creates unique ids for these.
These database records are available both in the client and server. You can either fork and extend this package to store more information, or create another database table to store your information.
I'm developing a single page jQuery & Backbone.js web app. The backend is a JBoss 6 application server.
Until now we had the following structure:
There is only one servlet (front controller). Every request from the JavaScript client goes through here.
In the servlet - at the first request of a certain JS client - I make a look p to a stateful session bean. For the next requests of this client, I store the result of the look up in an HTTP session container. So every JS client has exactly one stateful session bean. This connection is kept by a session cookie.
Now I have an additional requirement:
When the user has two browser tabs (in one browser), they should have two isolated instances of the web app in every browser tab. Because of that I have a problem with session cookies because this session cookie is for all browser tabs.
I have to change the structure so that:
The servlet has to generate a new session ID for the first request of a certain JS client. This session ID is communicated to the client.
With every POST to the backend the JS client has to send this session ID.
My question is:
Until now I saved the result of the look up in an HTTP Session object and I hadn't to think about generating a session ID. But now I have to store this somewhere else, where?
Has anybody experience with this kind of setting and can help me?
Update:
Thank you BalusC for this very interesting approach.
When I understood you well, this means:
All individual JS clients of the tabs of one browser share one HTTP session object. And in this HTTP session object, every tab has its own entry point. That sounds really good. So I still can use the whole HTTP session infrastructure and don't have to reinvent the wheel.
Autogenerate an unique value on the initial GET request which you store and pass around on every subsequent postback as a hidden input value. Use this unique value as identifier of the session attribute representing the view-scoped data.
During the 1st request on a brand new session, do:
Map<String, ViewData> viewScope = new HashMap<String, ViewData>();
session.setAttribute("viewScope", viewScope);
(the ViewData represents the view-specific data you'd like to track across postbacks on the same view)
During every GET request, do:
String viewDataId = UUID.randomUUID().toString();
viewScope.put(viewDataId, new ViewData());
request.setAttribute("viewDataId", viewDataId);
During generating the HTML, do:
<input type="hidden" name="viewDataId" value="${viewDataId}" />
During every POST request, do:
ViewData viewData = viewScope.get(request.getParameter("viewDataId"));
// Get/set view-specific data in there.
Make sure that jQuery also passes this hidden input around (which shouldn't be a big problem if you already properly use $(form).serialize() or e.g. AjaxForm plugin to ajaxify the forms).
If you're familiar with Java EE's MVC framework JSF, then it may be useful to know that its #ViewScoped annotation works roughly the same as described above. See also a.o. How to choose the right bean scope?
You can use session tracking with URL rewriting. See here:
Session shared in between tabs