I noticed this paragraph in the BackgroundTransferService documentation:
This property allows applications to request that background transfers proceed when only a cellular connection is available and when the device is on battery power. This is only a preference setting. It does not guarantee that transfers will take place under these conditions. The default value is None, which indicates that transfers should occur only when a Wi-Fi connection is available and when the device is connected to external power.
http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh286419(v=vs.105).aspx
I'm not a native english speaker, but does that means that the API will roll some dices to choose whether or not an upload will work, whatever are the preferences I chose, and that transfer can pause or fail?
I want to verify with you, as at first sight, it doesn't make sense to rely on randomness.
I agree that the wording can be confusing. Changing this setting allows the background transfer to occur if the phone is not connected to WiFi and not plugged in (which is the default). It's best to look at the available values.
None Allow transfers only when the device is using external power and has a Wi-Fi connection. This is the default setting.
AllowCellular Allow transfers when the device is connected to external power and has a Wi-Fi or cellular connection.
AllowBattery Allow transfers when there is a Wi-Fi connection and the device is using battery or external power.
AllowCellularAndBattery Allow transfers when the device is using battery or external power and has a Wi-Fi or cellular connection.
The default value states that transfers can ONLY happen when the phone has WiFi AND plugged in. By changing this value you allow the phone to not have WiFi and/or not plugged in. The transfer will still happen if connected to WiFi or pluggin in.
Hope this helps
Related
I am working on BLE application on a embedded platform where there are frequent connect/disconnect events. The issue I am seeing is re-connection takes too long. The high frequency of connect/disconnect is a part of usage scenario so I can't change that. What I can do is make the re connection more efficient. I noticed, the bulk of re-connection is spent of service/characteristic discovery of other devices.
I still want to make sure the service/characteristic of the connecting device hasn't been changed. In stead of discovering all the service , can we instead use a characteristic that has the hash of all the service/characteristic on the device? So each device can compare the received hash with the stored one. Only in case of mismatch perform full service discovery. Is there a precedent of doing it in BLE?
Bluetooth Low Energy (BLE) allows devices to leave their transmitters off most of the time to achieve its “Low Energy”.
I would expect a central device to subscribe to notifications from the peripheral. That way the peripheral only turns on and transmits when there are updates.
The other approach would be to put the data (or hash) in the advertising data (manufacturer data or service data) like many sensor beacons do. That way you might not need to connect at all or only connect if needed.
I'm using code from Google's sample game "ButtonClicker2000" found here: https://github.com/playgameservices/android-basic-samples
I have 3 androids running this game in genymotion plus one on my own phone, debugging them all from android studio. I've gotten to a point where I'm trying to gracefully handle disconnect in the event of network issues. The way I'm simulating network issues is toggling the wifi on my phone. (on or off, same behavior) After that, real time messages from my phone are no longer being received by the virtual devices, and my phone is no longer receiving real time messages from the other devices. However, my phone never enters onDisconnect() and the other devices never enter onPeersDisconnected. If I exit the app on my phone after communication ceases, onPeerLeft fires on the other devices.
How can I either ensure communication between devices in a game isn't lost in the likely event that a user at some point comes in or out of range of their wifi? If that's not possible, how can I at least ensure the onDisconnect event is firing from the offending device and onPeersDisconnected event is firing on the others?
If we're going with what the documentation states, onDisconnect usually happens when there's a problem with the remote services (crash or resource problem). having the WiFi turned off doesn't look like it fits with those criteria. [onPeersDisconnected](https://developers.google.com/android/reference/com/google/android/gms/games/multiplayer/realtime/RoomStatusUpdateListener#onPeersDisconnected(com.google.android.gms.games.multiplayer.realtime.Room, java.util.List)) is called when the participants are disconnected from the room.
Determine if the onP2PConnected is called when its connected and onP2PDisconnected when disconnected (hopefully this can catch WiFi toggling cases) since I think its more appropriate when you're using real-time multiplayer.
You can also read more about it in the Real-time Multiplayer section of the documentaiton.
Hope this helps!
I have an old hub that sucks, so I converted it to a USB-tripler by soldering all of the input 4 wires to the corresponding wires on the output connectors. I had to do this because modern devices require 2.0 or 2.8 volts on d+, and refuse to charge if d+ is shortened or not connected. It works well charging three devices from a 1a wall adapter.
But if someone accidentally connects this to a PC port, what will happen? Well if there is only one device, it would be detected no problem. But if two devices are wired to the same port, how dangerous is that?
I would prefer the first connected device to be identified in the system, while the second connected devices just get the power.
One of the first steps in USB enumeration is to send a reset signal by driving D+ and D- low. All the devices plugged in will see the reset and think it was intended for them. After the reset they will each think they have address 0 and respond to requests to that address. The result will be multiple devices trying to drive the bus at the same time, for a brief period before the host gives up.
I think it wouldn't damage anything, but you will be causing a short circuit for a few microseconds which is bad.
If I have two iOS devices, both on same WiFi network and both with Bluetooth turned on, and I use GameKit (specifically GKSession) to manually setup a communications channel between them (without using GKPeerPickerController), I cant tell if it is using WiFi or Bluetooth.
Does iOS prioritise one over the other? I'm hoping that it uses Wifi before Bluetooth, but id like to be sure.
If WiFi is available and bluetooth isn't, it uses Wifi, if Bluetooth is available and Wifi isn't, it uses Bluetooth. Im wondering how they're talking if both bluetooth and WiFi are available, which does GameKit choose over the other?
The only way I can see to find this out is by running a packet sniffer on my WiFi and running several tests across different devices. Kinda hoping someone can save me that effort!
Thanks :-)
According to Apple's documentation if you use a GKPeerPickerController to create your GKSession you will be able to select bluetooth or wifi connectivity (see GKPeerPickerConnectionType).
I'm hoping that it uses Wifi before Bluetooth, but id like to be sure.
It seems an internet connections requires a bit of user code (but not bluetooth) so I would guess it defaults to bluetooth to avoid making this requirement mandatory.
We have developed an application on Windows.net mobile framework and it is used on a Windows 6.5 Smartphone. for our location based application. Our application is real time and tracks our employees. We are finding that the device loses its GPS signal.
Has anyone managed to restart the GPS receiver so that it starts giving the GPS signal again. I would be ever so gratefull if someone can help. We are using GeoFramework2.0 to deliver the geographic information that you need.
Regards
Sandy
The GPS is "shut down" when no application is using it. Just close your handles and re-open them.
If the GPS on your device is part of the WWAN radio (i.e. cellular phone) it may get put in to a low power state rather than being actually shut off. In that case, you can try restarting the radio.
If that doesn't work, some GPS's will allow you to send proprietary commands to them to force a reset or clear the memory. These commands are not standard and will differ significantly by manufacturer. If you have a SiRF GPS, take a look at the SiRF Binary Protocol Reference.