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.
Related
The company I work for is considering to build an application for Windows Phone. Well, actually we plan to build an universal app ( for phone, tablet and PC ).
There are some requirements ( especially for Phone version ), so I would like to clarify few things before allocating resources & hiring people.
I would be very grateful, if some Windows expert goes through these requirements and confirm that this is possible.
So:
1) We need to launch a call within the application.
I've found this solution:
Make a phone call in Windows Phone 8.1
The question: is it possible to launch a call without a prompt? As far as I understand this solution prompts a question to user, if he wants to call or not. Our flow and design is made in a way, that this prompt will be redundant ( of course, we launch a call on user's behalf ).
2) We need to maintain internet persistent connection and be able to react if some message comes using this persistent connection. I've checked PubNub and it seems that everything is OK and PubNub provides SDK for Windows Phone.
Important: this is not VoIP application, so it might get complicated if Microsoft has some policies that persistent connection might be used only by VoIP application ( Apple has these policies ).
Important thing: Persistent connection should stay connected, if application goes background, so there should be no "cut off".
3) We should be able to present some notification ( with sound alarm ) to user and launch the app if he "accepts" the notification. Basically, we should be able to send some message to the device using PubNub or even Microsoft WNS service for pushes and present the notification on the device. Like "Local Notification" in iOS.
Any help would be highly appreciated.
Thank you in advance.
Best Regards,
Maksim
1)Unfortunately on Windows Phone you can't start a call without the system prompt.. It's for security..
2)I can't help you here..
3)Of course you can send notification to a device. This notifications are called toast notification.
A notification's custom sound can't be setted within the app, you have to load the sound on a server or let the user decide (he can change the sound in the system settings). If you don't need a custom sound.. no problem, it'll be used the default ones and you don't have to worry about anything.
I use Parse.com to send push notifications or you can even run a sheduled task every 30 mins on the user's phone(maybe is not appropriate for your application).
In the notification you can also set the property navigationUri to open the app on a defined page.
Unfortunately you can't still customize the notification aspect(you'll be able to do it in Windows 10) and you can see the default aspect here: http://www.codeproject.com/KB/windows-phone-7/ToastNotification/PushNotification.png
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).
I wonder if the background time that an app receives when entering an ibeacon region can be used for opening a session with an external accessory object. Can the app then also keep on running in the background while the session remains open?
This of course assuming that the external-accessory background mode is enabled.
While I have not tried this myself, I do not see any reason why it wouldn't work. You would need to have a legitimate reason in Apple's eyes to use the external-accessory background mode in order to get your app approved.
Assuming you have this, as soon as the app sees an iBeacon in the background, the app gets about 5 seconds of run time, which should generally be sufficient to establish a connection to an external accessory. If the connection is made, and the app is exchanging data with it regularly, the external-accessory background mode should keep it going in the background indefinitely, so long as the connection to the external accessory stays open. So long as this is true, the app will probably be able to get ranging updates in the background indefinitely, too.
It doesn't take a huge leap of logic to see that you could build a device that behaves as an external accessory and an iBeacon simultaneously, and use this to get around the usual iBeacon background rules. That said, you'd need to be careful that Apple doesn't think this is illegitimate, or the app could get rejected quickly. To avoid this rejection, you probably would need to be providing some benefit to the end-user via that external accessory channel.
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'm using BackgroundAudioPlayer agent in my Windows Phone 7 application. When the track end, the agent side receives TrackEnded event, but UI side doesnot receive any events.
Also, when I intentionally set audio track 's position to its end, then call Play(), the agent side receives TrackEnded event (because the track has come to an end), but the UI side does receive Stopped in its PlayStateChanged handler. So weird !
How to let UI know that an track has come to an end ? Communicating through isolated storage is not my favorite !
From research and a little testing, using Isolated Storage as a middle-man between Background and Foreground instances of the BackgroundAudioPlayer is still the only route for Windows Phone 7. The options are mentioned here (which I know you're aware of)...
http://blogs.msdn.com/b/wpukcoe/archive/2012/02/10/background-audio-in-windows-phone-7-5-part-2.aspx
http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202944(v=vs.105).aspx
https://stackoverflow.com/a/11419680/247257
This was also confirmed by Peter Torr who said:
For example, the agent may need to tell the foreground “I just started pre-downloading the next track,” or “I updated a database table and you should refresh your state”. Such notifications are impossible to create with Windows Phone OS 7.1; at best you can model them by using polling techniques, but this approach is inefficient and prone to errors.
The only good news is that in the same post, he gives a solution (using named events for IPC) for Windows Phone 8 which is a lot more reliable...
http://blogs.windows.com/windows_phone/b/wpdev/archive/2013/03/27/using-named-events-to-coordinate-foreground-apps-and-background-agents.aspx