I'm running an IntentService which has a SensorListener running. It seems impossible to stop the service from another activity within the app.
Is there anyway at all to stop an IntentService from outside the service?
Also, since the Listener is the only thing that is running (keeping the app from stopping), is it possible to unregister the Listener from another activity?
Thanks!
It's ok now. Commonsware told me here
BroadcastReceiver within a Service not receiving broadcasts Android
that I was leaking the receiver, hence the appearance of the service not being stoppable.. IntentService cannot implement receivers
Related
I have a situation where i have to call an Azure function periodically.
When i call the function, i need to check the state of the azure function.
If the Azure function is running, then i need to postpone the call until it is completed.
I am trying to look in an Email Queue (as the emails are coming in), I need to send the email using Amazon SES
I am using a HTTPtrigger and the email part is working fine.
I don't want the function to be called, when it is already running.
If you consider the serverless architecture, each time whenever you invoke a service endpoint, a new instance will be created and scaling is managed by scaling controller.
There is no way to check if the function is running or not.
Without understanding more about your use-case, I think this is possible with Durable Functions. Look up Eternal Orchestrations that call themselves on an interval indefinitely. You can then query the status if required and have a workflow in the eternal orchestration that changes depending on certain criteria.
I'm writing a chromecast receiver application that will (hopefully) allow me to remotely put alert messages up on my TV to serve as reminders.
My plan was to have a dedicated wireless device on my home network that would constantly poll for new messages from a centralized server. When a new message was found, it would connect to a chromecast route, turning on the TV and displaying the new message.
But as far as I can tell, the only way to activate a chromecast route is by manually clicking the chromecast icon on my Chrome browser or wireless device.
Is there a way, programmatically, to activate the chromecast? Can it be done in the sender?
You can programmatically scan for cast devices and connect to them if needed. Steps are:
Get an instance of the MediaRouter singleton from the system: mMediaRouter
Build a selector:
mMediaRouteSelector = new MediaRouteSelector.Builder()
.addControlCategory(
CastMediaControlIntent
.categoryForCast(YOUR_APP_ID)).build();
Add a callback to initiate scan:
mMediaRouter.addCallback(mMediaRouteSelector, mMediaRouterCallback,
MediaRouter.CALLBACK_FLAG_PERFORM_ACTIVE_SCAN);
The onRouteAdded() and onRouteRemoved() of your callback (i.e. mMediaRouterCallback) will be called as routes are discovered or removed. You can maintain a list of routes in your app and keep them up to date by using these two callbacks.
You can select a route by calling mMediaRouter.selectRoute(aRouteInfo). Then the onRouteSelected() of your callback will be called and you can extract the cast device as usual and do as you please.
These said, remember that if you want to show a notification to users on TV your app should be running on the chromecast at the time you want to send the notification.
I would like to know what is the clean & correct way to notify my WP8 app that the ChannelUri has changed?
I read that i need to handle this in the ChannelUpdatedUri method. But i have a few queries here. Doesn't this require my app to be running all the time?
Second query is suppose i use ChannelUpdatedUri to listen for changes to the Uri. If there is a change will the app be notified as soon as it launches? Or will it be notified at a later time?
The trouble is if the app is not notified on launch then there is a possibility that it may re-register for a new channel uri before ChannelUpdatedUri is invoked. Isnt it?
Please help!
You'll only get notified of a change in the ChannelUri when you have the listener attached and the app running.
The best approach is to always check for the current Uri and pass it to the server when the app starts. You could leave the listener attached for the lifetime of your app and get a new one if it's lost while the app is running but in reality it's far more likely that the channel will be dropped/disconnected when the phone isn't in use.
There is, of course, the scenario where a channelUri may expire when the app isn't in use but the utility of the app is primarily around sending notifications. Obviously you need the user to restart the app to get a new connection but you can't tell them to restart the app.
This is a generic problem: how do you tell someone that you can't talk to them?
The reality of this situation is that if you really need to tell someone to launch the app again you'll need another way to do it.
Unfortunately, it's not possible to get an updated channelUri from a background agent, but you could query your backend to see if you need one and then raise a toast to the user to prompt them to reopen the app. Or you could just update the tile from the agent when this happens.
Alternatively you'll need to send them the prompt in another way (e.g. email or SMS?) but this is reliant on you capturing and securely storing these details.
There is no perfect solution to this scenario other than creating an app that the user opens regularly regardless of whether there are notifications or not and simply having the notifications as an extra feature.
I have a BackgroundTask which connects to a remote server and does some kind of action, download, upload, etc. This task runs every 15 minutes.
The UI associated to the BackgroundTask does the same and more.
However, the remote server allows only one session per login and I have only one login to that server. As such, I need a strategy to ensure that either one of these two are active and not both.
Currently, I store a value in LocalSettings which indicates if the UI is open or not. If the UI is closed, the BackgroundTask will do it's job as per normal. If the UI is open, the BackgroundTask will do nothing.
This works fine, except for when the BackgroundTask is in the middle of it's Run and the UI is launched. I need a way of cancelling this BackgroundTask immediately when the UI is launched, so that the UI can use the login to the remote server. Any tips or suggestions on how this may be achieved?
Thanks to Dave Smits for the solution.
In a nutshell:
Register for Cancellation event in Run method.
In the Cancellation event handler ensure connected sessions are disconnected.
When the OnLaunched event is raised in the App object, Unregister the
task which raises the task Cancellation event.
I'm building some very basic analytics for in-house WinJS apps. Take this to mean that a 3rd-party analytics solution would both overkill and/or unworkable and/or against the 3rd-party providers terms of use as they generally disallow capturing personally identifiable information about the user, and in this case that is a business requirement.
The thing I'm trying to do is determine how much time is spent in multiple apps, and in areas within certain areas of the app. For this I obviously need to know when they enter and leave.
All the documentation I've found says to use the WinJS.Application.oncheckpoint event or the Windows.UI.WebUI.WebUIApplication.onsuspending event, which really seem to be two access points into the same basic concept. The problem is this doesn't accurately reflect when the user leaves the app! Suspend seems to happen only after the user has switched to another app, plus about 10 seconds ...... if the system feels like it.
If the user simply hits the Windows key to go out to the Start Screen and just sits there, the app continues to run indefinitely (calls to setInterval are able to affect state) even though the app cannot be seen!
I understand this is a bit of an edge case, but is there any more reliable way to tell when the user can't see the app, for lack of a better definition?
Notes:
I did look at the Cordova 2.7 code for Windows 8 and they are using the checkpoint event to drive the Cordova pause event.
App Visibility section on Application lifecycle seem to address this. This means registering for `msvisibilitychange' event, to know when user moved away and moved back to your app.
default.js:
document.addEventListener('msvisibilitychange', function ()
{
console.log('visibility changed');
console.log(document.visibilityState); // 'hidden' or 'visible'
});
In addition, suspending, resuming and activated events also needs to be handled.
default.js:
Windows.UI.WebUI.WebUIApplication.onsuspending = function ()
{
console.log('suspending');
}
Windows.UI.WebUI.WebUIApplication.onresuming= function ()
{
console.log('resuming');
}
Needless to say, that nuance of ordering, and/or event being absent cases needs to be handled. For example - if the user moves away and comes back quickly, visibilitychange event will be received. whereas if user does not come back suspending event may come after some time. if the app is not terminated, it may be followed by resuming event. otherwise, activated event.
regards spending time on specific pages, page ready and unload method should work. unload() will not get called if the app is suspended or terminated.
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/visibilitychange
Use the visibility change event to recognize when the user can no longer see the app.