Is there any way to access the sphero while it is charging in its cradle? I'm looking to pass information to it but still have it cradled and charging (ie, change colors throughout the day without draining the battery). Thanks!
Yes. If it goes to sleep in the charger, you can't communicate with it at all, but you can set it to stay awake in the charger, which will allow you to still communicate with it. If you're developing toward Android, use the SetOptionFlagsCommand with a value of 1 to prevent it from sleeping. Use a value of 0 to allow it again.
Related
I am building an Android App to control power outlets with a smartphone. The app features an Android Wear app so people can control their lights right from their wrist.
When the user wants to control a light I send a String action via the MessageApi from the smartwatch to the smartphone, which receives this action in a WearableListenerService and sends the appropriate network signal to the power outlet/gateway in an AsyncTask.
This works fine as long as the phone has not been in idle for too long. However if the phone is still on the table for too long and doze kicks in Wear actions do execute very slow or sometimes not at all. I guess this is in part intended behavior however it is not practical in my case as the user cant wait that long for his lights to turn on if he wants to enter a dark room.
I am aware that doze completely cuts the networking for everything except FCM/GCM if you are not on the doze whitelist. But even when my app is on this whitelist and the networking part works actions can take a long time to execute on the phone.
So my specific question is:
Whats the recommended way to handle this scenario, where an action from a wearable device needs to be done via network on the connected smartphone which is in doze mode?
Is there a way to exit doze for a quick amount of time to execute calculations triggered by the wearable companion app faster?
I know the AlarmManager has a new method that works even in doze mode, but will this fix the processing delay too? Firing an alarm after receiving a MessageEvent from MessagApi seems like a workaround to me.
Or maybe is an AsyncTask just the wrong way to handle background networking and thats where the delay comes from?
Actually, there are a few options that you can do to handle Doze's effects as given in Adapting your app to Doze. You may want to consider the following options:
If your app requires a persistent connection to the network to receive messages, you should use Google Cloud Messaging (GCM) if possible.
GCM is optimized to work with Doze and App Standby idle modes by means of high-priority GCM messages. GCM high-priority messages let you reliably wake your app to access the network, even if the user’s device is in Doze or the app is in App Standby mode.
To help with scheduling alarms, Android 6.0 (API level 23) introduces two new AlarmManager methods: setAndAllowWhileIdle() and setExactAndAllowWhileIdle(). With these methods, you can set alarms that will fire even if the device is in Doze.
However, please note that with these methods, neither setAndAllowWhileIdle() nor setExactAndAllowWhileIdle() can fire alarms more than once per 9 minutes, per app.
Please try going through Optimizing for Doze and App Standby for a more detailed information or discussion.
In addition to these given documentations, the same options in handling Doze were also given and discussed in Diving into Doze Mode for Developers which might also help.
I am trying to collect GPS location every 5 seconds from a smart phone by using socket.io.
I notice that when users pick up a phone call, socket.io will stop emitting messages. When users switching tabs in the browser, socket.io will stop emitting messages too.
Does anyone know how to solve this problem?
Thanks very much!
Your best bet would be to package the website in a native app. Use a service such as http://build.phonegap.com or Intel XDK. There are configuration options to keep your app alive in the background. As for it disconnecting during phone calls, this is a carrier limitation. If the user was connected to WIFI, most phones will that for data while simultaneously on a call.
Some networks (such as Verizon) do not have the capability to do voice and data at the same time. Thus, when a call is made, data is suspended until the call is finished. AT&T does not have this limitation.
The operation of background tabs will vary by mobile browser and is likely done for battery conservation reasons. It is unlikely there is a work-around to keep the background tab running (because that would defeat the whole battery management purpose).
In my windows phone 8 application, I would like to refresh/load some data periodically (less than 10 minutes) from server, while application running in background (ie, in dormant and tombstoned). I tried scheduled task agent and resource intensive task agent, but they are called at rate of 30 minutes gap. Please let me know is there any other solution for implementing the above said requirement.
Thanks and Regards
#nish
If you need to get data more frequently than the default available in Windows Phone, you should think about using push notifications. This won't be suitable for a full data push, but if you use it correctly, you can get a user experience that you can live with.
One common approach to this is to set up your server to send a notification to the device when there is something new to report instead of pushing a "nothing has changed" message every 10 minutes or so. If you push out a tile update notification to say, for example, "You have x unread items", the user may then click on the tile for your app and you can poll the server for new items on launch/resume. If you want a more intrusive option, you can send a toast notification as well, but in most cases the tile update will be sufficient.
This method has a few advantages.
You won't be burning through battery power polling every 10 minutes while the user is asleep
Your server will have significantly less load since it is not having to process full data requests every 10 minutes per client.
This fits in with the design philosophy of Phone apps - you are surfacing the required data to the user, while at the same time preserving battery life.
Do I understand correctly that your primary goal is to keep some host session alive by having the phone make a query periodically? If so...
I would not recommend this approach: 1) you cannot count on the phone having network connectivity when it tries to send its query. If the user puts the phone away in a pocket or purse, the odds worsen. 2) it's probably bad from a security perspective, and wasteful from a host resources perspective.
You might instead add logic to your app to resume a timed-out host session as seamlessly as possible. This would add real utility value to the mobile app value proposition over raw HTTP access to the same host.
I am planning to write WP7 app, which needs to send to server phones GPS position every 5 minutes. Data must be sent to server even if app is not running. One way to do that is to use Background agents (I am using 7.5 Mango), but in that case app will send data only every 30 minutes, which is not acceptable in my case.
Is there any other solution?
Thanks in advice.
No, this is not a supported usecase for WP7 apps on Mango. Also, it's important to mention that the location you'll get for GeoCoordinateWatcher on a background agent is a cached geolocation from approximately the last 15 minutes and not the real-time geolocation.
What exactly are you trying to build if you don't mind me asking? This sounds oddly close to spyware. Even if it's innocuous and meant for a good purpose, I'd be careful walking in any direction that constantly shares GeoLoc with a remote server.
Your only choices are sending the data every 5 minutes while application is running (even when the phone is locked) and/or send the data once every 30 minutes by registering a PeriodicTask.
Having said that, I agree with Justin in that what you are describing sounds nefarious.
The sole user interaction for my app is through the accelerometer, so there is never a reason for the user to touch the screen. What I need is the ability to elevate a non-touch event so that the system recognizes it as user interaction, delaying the screen timeout. Either that or I need to be able to manually extend the timer.
I have already read (and commented on) the thread about disabling the timeout. That is not what I need. The interaction my users are performing is very explicit (turning it over 180 degrees) so it won't happen if it is set down or stuck in their pocket (unless they are riding a rollercoaster.
Currently, the device is constantly shutting down when the user is in the middle of actively using my app.
Have you tried flipping UserIdleDetectionMode from enabled to disabled again to see if it resets the timer? If that works you could do it in response to your application events.
Otherwise there is no means of simulating user events, so I would say you are out of luck on this one for the moment.