Main Site Documentation

If any windows phone 7 people are interested


#1

My first app went live over the weekend :slight_smile: It’s a freebie one and for people who have bad memories :slight_smile:

Jas


#2

cool, might come in handy…


#3

I’ll gladly pay for it if you can have it also add a tap to the side of my phone :slight_smile:


#4

It’s a pleasure to meet people developing for WP7 here! :wink:


#5

+1 for WP7. Being able to develop on the Fez, Phone, Desktop and Web within the same IDE kicks butt. Now to see some phone 7 controlled fezes!


#6

I’m now working on such a scenario. Full duplex communication WP7+Cobra. :slight_smile:


#7

Bluetooth or WiFi or Neither?


#8

@ kurtnelle

My Gadgeteer helicopter project includes a Windows Phone 7 client. Uses standard TCP sockets for comms, thanks to a library from Marco Minerva:


#9

Rum an Diet Coke - the health conscientious choice :slight_smile:

Actually it would be a rather handy little app for a number of things, you will have to let us know how it does in the market place.


#10

I use TCP over sockets. It’s over ethernet now but WiFi could be used either, no matter.

As for example from Marco Minerva, as I can see, - it doesn’t keep track of possible portions of received messages. In practice a message could come split in several portions of data (especially if the message is long and receive buffer is small), so you have to keep track of the beginning and the end of the message and merge received portions to get the whole message. I use BOM and EOM markers in a message. So the showed example is for demo purpose only. In real app you should do more work to avoid the message drops.


#11

@ Gothic Maestro

Thanks for the info on the Marco’s sample. For my purposes, the data is quite small, so I’m not worried about it being broken up across packets. But I appreciate the warning, as I’m not too deep on network programming at the socket level.


#12

@ devhammer
You are welcome! :slight_smile:
Anyway I would suggest that you test received messages because we couldn’t assume they’ll be always correct. This case is sometimes hardly discoverable and we could experience the drop of data. Message breaking depends on many reasons, not only lengths of buffer and message itself. So when you’ll be developing some serious and stable communication it’s necessary to check packets for consistence. There are a lot of approaches for this, you could find more info on the web. :wink:

One more thing, when you call the Send method of a socket please be sure to check its return value indicating the number of bytes sent, because it’s not a fact the socket has sent all of your data just in a single method call; correct practice is to send remaining portions of data in a loop until that return value will become zero.