locked
Easy way to communicate between app running on multiple devices?

    Question

  • Hi,

    I want to build a XAML Windows Store app to run on two different devices that display synchronized images.

    So when I change the image displayed on device 1, I want device 2 to automatically switch to show a related image. I can pre-load all the images on both devices, so I don't need to actually transmit the image, but I need a way to communicate that an image change has happened and what image is now displayed. Both devices will be on the same local network.Any suggestions for the easiest way to implement this?

    Monday, October 13, 2014 11:22 PM

Answers

  • I actually worked up a sample here for you that does exactly that, attempting to work out a proof of concept for another pair of apps that I need to do the same thing in. 

    I wanted to give you something that would be resilient and that would "just work" on WP and Windows, as it should.  However, I ran into a bug with Windows RT - which won't receive broadcast UDP datagrams.  It appears to be a problem within the network stack, according to the threads I can find on the issue.

    That's the thing about networking.  If you build an app like this, you'll really need to make it robust.  Users don't always have great networks, and in this case, not all devices will "just work."  You'll be supporting them, so make sure you test and test!

    Anyway, take a look at the sample I started.  You can use it on phones without issue at least.

    I stopped working on it when I found the problem with Windows/the Marvell adapter, as I spent far too much time trying to figure out a workaround.  Some things that still need to be addressed and that I didn't get to do are:

    1. making a real packet/protocol.  If some other app was to send a junk packet to our port, it would simply crash.  I would add markers and "magic numbers" to the packet to make sure de-serializing a c# string wouldn't cause an exception when fed invalid data.
    2. I'd limit the packet size.  You can't send infinite data in the payload, too large and it will not work as expected.
    3. handle resuming.  Right now I have it just recreating everything.  There may be a better way.

    I also noticed that there are some differences about where you can start/initialize the communicator: On Windows Phone, the communicator needs a window to be active, while Windows 8 doesn't care.  That's why it is currently initialized in the MainPage and not in app.xaml.cs, where I'd prefer it to be.

    It's a start, anyway.


    Darin R.

    Monday, October 20, 2014 11:59 PM

All replies

  • Hi Jan,

    PeerFinder can find other devices using WiFi if both devices support Wifi. After the initial handshake, both devices communicate using sockets.

    The Proximity Sample shows basic use of PeerFinder: http://code.msdn.microsoft.com/windowsapps/Proximity-Sample-88129731.

    PixPresenter is a sample app that uses PeerFinder and exchanges images between devices: http://code.msdn.microsoft.com/windowsapps/PixPresenter-Code-sharing-39ed631f.

    PeerFinder.SupportedDiscoveryTypes tells you what methods are currently available for discovering other devices: http://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.proximity.peerfinder.supporteddiscoverytypes.

    If I misunderstand, please feel free to let me know.

    Regards,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, October 14, 2014 7:20 AM
    Moderator
  • Another way, if you want more than 1 peer, and when on WIFI is using Sockets/UDP Datagrams.

    On every system, wait for a Receive for specific UDP port, or multicast group.  When a message comes in, parse it and show that image.

    Then, every time a device selects an image, broadcast a message using a socket to the above port.  All connected/listening devices will react.

    Remember, only works on WiFi (not Cellular)

    Or, another way would be to have a server and use SignalR.  It makes it really easy, and abstracts you from the lower level protocol related stuff if you're not all that familiar with that sort of thing.


    Darin R.

    Tuesday, October 14, 2014 5:58 PM
  • Thanks for the quick replies!

    I guess I should have clarified - I'm hoping to have more than 1 peer listening for the image change event. But as far as I can tell all the options mentioned could support that, right?

    To summarize, these are the proposals:

    - Use PeerFinder to detect other devices, then communicate using sockets

    - Just use sockets (which means I have to manually enter the info on each device to set them up, right?)

    - Use SignalR to set up a server - would I set up a server on device 1 and then just have all the other devices connect to that one?

    Tuesday, October 14, 2014 10:04 PM
  • Using sockets doesn't mean you have to manually enter any data.  You can broadcast that the app is running using a UDP/multicast message.  Then, the apps listening for that UDP "ping" know other people in the WiFi area have the app.  (Important!  This only works over WiFi, not cellular!)

    I'd have the apps all launch and receiving the "pings" (UDP broadcasts from a host app).  They'd get a ping and would then notify the user that "host x" is hosting a channel/room/etc.  The ping would also contain the IP/connection info, possibly.

    The host user would start the app as the normal users would have.  They'd do something with the UI to enter host mode and possibly enter the name of the channel/room/etc and then their app would start the pinging, advertising the host is there, and sending the IP to connect to.

    You could do it all with UDP 'ping' packets too.  If you sent [App/Host/image#] in every ping, there'd be no further connection needed by the client apps.  If the other users (other than the host) were running the App, and wanted to connect to the Host in the UDP, they'd show the Image # taken from the UDP packet.


    Darin R.

    Wednesday, October 15, 2014 5:21 PM
  • Thanks for the response Darin!

    Would it be crazy to just use broadcast for all the communication? Basically just broadcast a packet with ID of what image to switch to. Each device could then know how to parse that broadcast message. Then there would be really no need for device pairing process, right?

    Monday, October 20, 2014 9:36 PM
  • I actually worked up a sample here for you that does exactly that, attempting to work out a proof of concept for another pair of apps that I need to do the same thing in. 

    I wanted to give you something that would be resilient and that would "just work" on WP and Windows, as it should.  However, I ran into a bug with Windows RT - which won't receive broadcast UDP datagrams.  It appears to be a problem within the network stack, according to the threads I can find on the issue.

    That's the thing about networking.  If you build an app like this, you'll really need to make it robust.  Users don't always have great networks, and in this case, not all devices will "just work."  You'll be supporting them, so make sure you test and test!

    Anyway, take a look at the sample I started.  You can use it on phones without issue at least.

    I stopped working on it when I found the problem with Windows/the Marvell adapter, as I spent far too much time trying to figure out a workaround.  Some things that still need to be addressed and that I didn't get to do are:

    1. making a real packet/protocol.  If some other app was to send a junk packet to our port, it would simply crash.  I would add markers and "magic numbers" to the packet to make sure de-serializing a c# string wouldn't cause an exception when fed invalid data.
    2. I'd limit the packet size.  You can't send infinite data in the payload, too large and it will not work as expected.
    3. handle resuming.  Right now I have it just recreating everything.  There may be a better way.

    I also noticed that there are some differences about where you can start/initialize the communicator: On Windows Phone, the communicator needs a window to be active, while Windows 8 doesn't care.  That's why it is currently initialized in the MainPage and not in app.xaml.cs, where I'd prefer it to be.

    It's a start, anyway.


    Darin R.

    Monday, October 20, 2014 11:59 PM
  • Wow, thanks so much for the sample!

    Unfortunately I'm planning to have this running on 3 Surface RTs, so looks like the broadcast approach is a bust :(
    Thanks anyway :)

    Tuesday, October 21, 2014 5:51 AM