Say I am making a little chat application using phoenix.
Locally when I open multiple tabs in a browser, will that be a separate socket connection?
From what I see with other chat apps is that if I open a new tab or even browser window, it re-connects to the same chat session, which makes sense since you want to re-connect the user using a cookie or something.
If this is the case, how do you test things locally if you want to test multiple users in a chat session etc.?
Any tricks?
Yes, each tab will have a separate socket. If you are authenticating your sockets per the recommend approach (in the socket.js boilerplate generated with your project), you will automatically authenticated. However, if you want the second tab to open the same room, you will need to handle that yourself. The answers to these questions will give you some ideas:
phoenix-channels-multiple-channels-per-socket
phoenix-channels-broadcasting-from-controller-how-to-find-current-user
broadcast-to-different-channel-phoenix-1-1-6
But would you really want to do that? Perhaps the user has opened another browser tab/window because they want to chat in another room.
I'm a little unclear on your question, but I'm going to assume that you want to test different users on the same computer. You can open the chat app in a different browser like Chrome, Firefox, IE, etc. This is how I do manual testing. If your looking for automated unit testing of channels, Chapter 13 of Programming Phoenix has some good examples.
Related
I am trying to create a shared calendar as a web app. When someone adds an event on the calendar i want everyone who shared that calendar to see that event too. When someone create an event, I made an ajax that sends the data to a database. Is there a way to send the event from server to other clients that are online on the page and share the same calendar? I did it now by constantly 'refreshing' the info from database.
If anyone has a clue how this can be made, please tell me.
Wanting a web server to "push" information back to the browser is a time old issue. The traditional way to handle this is to have any active clients (i.e. the people still logged into your app with a page open) continuously "poll" the server at a regular interval to see if there's any new information for it. In your case, you can have some JS on the page make an AJAX call every 10 seconds to see if they have any new calendar events they should be aware of. This does increase the overall traffic to your web server so pick your polling time appropriately - otherwise you'll cripple your web server because it will spend all of its time handling these "is there anything new?" requests when most of the time there won't be.
If you want to be a little more cutting edge, you can look at HTML5 websockets. A google search for "html5 websockets tutorial" should give you plenty of resources. They're a bit trickier to use and require that you are running a web server that supports them (you probably are). For browsers that support it, you can maintain a more long term open connection where you can then push data from the web server back to the browser like you want to and your JS will capture "onmessage" events with the updated info. Pointing you at google isn't trying to flake out of a more complete answer, but there's already a number of excellent tutorials out there so look for HTML websockets and you should be able to pull off what you're looking to do.
I'm trying to write the most basic application for windows phone 7 and want to be able to send files (specifically XML in case that changes anything) to my app. Currently I have a WCF service setup so I can send push notifications through it. The problem is that there is a limit on the amount of raw data I can send via a push notification.
My solution to this is to send the initial push notification (either tile or raw) to alert my application that I want to send a file to it and then make the app somehow communicate with a server (everything is on my personal computer btw - I'm just trying to figure out how things work) - from which the app will recieve/download the files.
What is the easiest way to accomplish this? Note that I'm not concerned with security or anything like that.
Clarification - the question is essentialy: how do I transfer files from/to a server to/from the phone? Assume everything else was handled - the app is up and running and the user has given or will give permissions to every possible thing he may give his permission to.
Unfortunately, the total size of a push notification (including HTTP headers) is 1kb. This means that it can't be used to send large amounts of data.
Instead of sending the whole file, send a notification (raw or toast—as appropriate) which should be treated by the application as a trigger to go and retrieve the new file/data/whatever from the server. It may also be worth checking for new messages when your app starts. However, if when you start the app it will notify the server that it is ready to receive raw notifications and such messages will be sent indicating new content is available, it may be unnecessary to add this extra check.
To transfer files to/from the phone you will need to use either HttpWebRequest or WebClient as this is the only way to use HTTP on the device and HTTP is the only protocol currently available to transfer data.
While WebClient may appear to be easier to use than HttpWebRequest it is less flexible and will automatically perform it's callback on the UI thread and if you're downloading files in the background you almost certainly don't want this.
There is no way to transfer files to/from a conencted PC and have them exclusively available to your app.
First of all: you won't be able to do this approach automatically - the user will have to open your app to do that because WP7 SDK doesn't allow your app to run on background/start automatically once a push notification is received.
The only way to communicate with your server, at this point in time, is web services. If I were you, I would check for new information available once the app is started, if there is new info, I would call one or more web services which would return me all the information that I need.
If you want, you can use a timer to check for information periodically.
As I said, it will only work while your app is running (check the app lifecycle if you don't know it yet), WP7 doesn't allow apps to run in background, that is a serious limitation IMHO.
Good Luck,
Oscar
Maybe a little bit off topic but when I was thinking about file sharing in my WP7 app, I found two approaches:
Integrate an app with Dropbox
Use advanced explorer for WP7
You can use the WebClient class and the DownloadStringAsync method in order to download data from a web service .
A good example of this is Scott Guthrie's Twitter app from MIX10 .
George
I am developing a feature in my app where I need to store the state of a particular series of actions between 2 users, just like an ajax based chat service.
The scenario is as follows:
A user can is able to see which other users are online and then challenge one of them. The other user receives the challenge and accepts it. Now both the users are given 5 questions each and the match starts simultaneously for them (almost simultaneously) Then as a user navigates thru the question or solves it, the state is updated on the other user screen as well.
Essentially this is very similar to a chat system like say facebook chat. I am able to see who all are online. I send a chat msg to my friend who can then respond to that and that response is seen on my chat window.
I believe all this can be achieved by using ajax. I can easily make ajax calls to .asmx webservices and retrieve objects for a particular user as Session can be accessed there. However, I am wondering where to maintain state because session is for a particular user and I want my particular object to be accessible for two particular users.
Where do I store the state? Or taking the example of Ajax based chat, where should I store what message User1 entered and when Uer1 entered how is it shown to user2?
I was thinking application object but read it is not recmmended.
What do you recommend for such a thing?
If you're trying to do "near real-time" message passing you might want to take a look at HTTP polling (a.k.a. long polling). I won't use SQL for temporal message passing and short-term state transitions like I've seen in the past. If running on a single web server just keep the state in session or in the ASP.NET Cache. If running on multiple web servers take a look at distributed caches like memcached, Velocity (Win 2008), or NCache. Then serve the cached data to the AJAX requests which are sitting and waiting (because of long-polling). The key design issue is the design of the cache keys (no pun intended), which would need to include the user's ID for user-specific event data.
P.S. There are frameworks for large-scale, near real-time message distribution that solve scaling issues which are hit when hundreds of clients are participating in long-polling at the same time. The broad name for those frameworks are 'Comet', and they are most useful when broadcasting the same messages to many clients.
I want to be able to synchronize several text files on a user's PC in real time from my web application. Basically I want a few data files on the local PC to mirror the state of a user's data in my web application so if the web application or the user's internet connection is lost he can use those data files to get some critical info (possibly using html/javascript code stored in with those files that would run in offline mode on those data files.)
I know that google gears has a lot of interesting tools for working with offline state, but I'd prefer an even simpler application in html/javascript that wouldn't be as reliant on google gears. I'd rather use google gears to just create those files and slowly keep them in synch with the web application's version of data throughout the day.
Update on answers:
PersistJS is a good suggestion I will look into, but I was hoping people would direct me towards really good Google Gears tutorials resources.
You can save data on the browser using PersistJS, which uses the best client-side persistent storage mechanism it can find, supporting:
Flash
Google Gears
HTML 5 storage specs
browser-specific extensions
cookies
When your app reconnects, you can resync. Creating and reading text files is something the browser will generally block your web site from doing.
Risking of stating the obvious; if you want to store user state locally, isn't cookies the standard way?
maybe more then one cookie will be needed, but that sounds like the simplest of ways.
You're going to need to make an ActiveX control and a FireFox plugin to get these permissions. Short of that I agree with orip try using PersistJS
You can ask the user to download a subversion client that is predefined to interface with your subversion server only. Then write your web application to interface with the subversion service from your side only.
There is a good deal of security harm associated with granting access to a user's file system so you will want to lock down all possible points of exploitation. You will want to ensure that the user cannot access the subversion server except through the client that you ask them to install. You will want to ensure the connection between the application server and the subversion server is extremely secure so that the transmission path cannot be compromised and that malicious logic that may be loaded onto the application server cannot access the subversion server. I would say to encrypt the transmission path between those two servers and put the subversion server behind the firewall separating your network DMZ. I would also suggest use a challenge/response mechanism between the application server and the subversion server to prevent malicious code from appearing to be legitimate decisions made on the application server. Also, ensure that data only flows form the application server to the subversion server in a unidirectional fashion only, because if there is malicious logic planted on your application server then any data that comes from the subversion server is compromised without even accessing that server.
you could use the File System Object FSO through javascript, however it is dependant on Microsoft as it is an ActiveX control, it would also require permissions in the browser, or perhaps a HTA (HTML Application).
http://www.webreference.com/js/column71/
Its a real security issue so most avenues are closed down inhrentley.
Inherently the web model was designed not to authorize upstream from server to client. Now things are changing slowly maybe could you do this with Websocket ?
(Also asked over on ServerFault, where I was advised to post it here too)
We have a requirement to send desktop alerts to various users (compliance, production) across a network when other users have submitted content online for a report.
At present we are using NET SEND but this has no guarantee of delivery and has proved unreliable from both client and server perspective (and I gather will be unsupported in later versions of Windows; we are currently running XP).
We are considering a Jabber-based solution but has anyone used a Jabber client to pop up alert messages on the screen like NET SEND does, as opposed to just bringing a chat window to the front or displaying a temporary 'toast' message near the system tray.
We need the alert message to be persistent and only dismissed by the user, indicating they have seen it. Toast-style pop-ups would be fine as long as it was not only for a limited time and again had to be dismissed by the user.
Any solutions?
Openfire is a java based Jabber server that seems to be targeted to a corporate/business environment and provides the "toast" message feature with their Spark client. They also offer several other useful business-focused features.
Offline message delivery is not guaranteed by XMPP specification. It depends on concrete server implementation. Moreover, it has cost in supporting user accounts.
As an out-of-box solution it is fine, but since we are in development community, I would
consider building alert system using MessageQueue for guaranteed delivery.
The message-delivery semantics of XMPP are liable to be a good fit for your application, since you're not talking about financial transactions that require fiduciary-level delivery guarantees. It will certainly be better than NET SEND by a lot.
Write a simple client that listens for messages and does the pop-ups in whatever format you want, and have the program run in the background, perhaps with a tray icon. Writing something like that with Jabber-Net would be the work of a few hours, for example.