Ranting and raving about anything I feel like complaining about.

Confusion Around WP7.1 Periodic Agents

IMG_0088After my recent post on Periodic Agents, I had a number of people react to specific parts of the API. Let’s discuss each of these separately.

Periodic Agents’ 14-day Lifespan

It seems that developers are confused about the role periodic agents have with their apps. The short version of the story is that periodic agents are supposed to support your app, not replace it. To this end a periodic agent must be re-registered at least every fourteen days. Typically this is accomplished by re-registering your app on every startup.

So I am curious as to whether people are building apps they think only have background agent functionality. My typical thought about periodic agents is that they are to get the user to come back to my app. If I am doing work in the background for two weeks and can’t coax the user into launching the app, then the app isn’t worthwhile for the user. Am I wrong?

Running a Periodic Agent from the App

As you may have seen from my recent post on Periodic Agents, you can debug an agent by using ScheduledActionService.LaunchForTest. I’ve gotten a bunch of people who asked me if they could run this from published applications. The Marketplace certification doesn’t mind if you use this API but I am confused why you would do this. Agents are under much more stringent runtime limitations than your application so why run code under those limitations? I think what these developers really want is to run the code in their agent…not run their agent. And this is remarkably simple.

The trick is to put the code you need to launch from both places in a shared library. For example, you can see here a Windows Phone 7 application in Visual Studio’s Solution Explorer:

10-15-2011 7-31-44 PM

TheApp is the main WP7 application that the user launches; TheAgent is the Periodic Agent; and SharedCode is a shared library that both use. If you put operation that you typically do in a Periodic Agent into a shared library, then you can call it from your app as well without having to execute TheAgent at runtime.

In this scenario, TheApp references both TheAgent and SharedCode. TheAgent references SharedCode. This way the same code in OnInvoke in the Periodic Agent can be used in your application as shown below:

// In the Periodic Agent
protected override void OnInvoke(ScheduledTask task)
{
  // Code in a shared library
  var obj = new SomeCode();
  obj.SomeOperation();

  NotifyComplete();
}
// In the Main Application
void MainPage_Tap(object sender, GestureEventArgs e)
{
  // Shared Code 
  var obj = new SomeCode();
  obj.SomeOperation();
}

This should remove the necessity to ever execute the Periodic Agent from your application.

 
 

Comments

Gravatar "If I am doing work in the background for two weeks and can’t coax the user into launching the app, then the app isn’t worthwhile for the user. Am I wrong?"

Well I think you are. I have at least two examples: the Samsung's "Now" app, and "StockMap". I use both apps only for the live tile (to have the weather and the stock market on my home screen). They provide all the information I need through the tile, I have no reason whichever to start them.
Gravatar I accidentally left in ScheduledActionService.LaunchForTest, and while you're right in that it does pass certification, for some reason it causes your app to throw an exception in the signed/downloaded version. I would definitely advise making sure it's removed before submitting to the marketplace.
Gravatar If the periodic agent updates a tile and the information on the tile is most of what you need most of the time then why would you go back to the app? I have something in development that one would hope would fit that model (because you only need to go to the app when something has gone wrong somewhere).
Gravatar KooKiz,

True enough, and if that's what you need. Push notifications is your friend.
Gravatar Murph, See what I said to KooKiz.
Gravatar Shawn,

Erm... no, push notifications are not necessarily my friend because they require an element that runs off the phone - the level of complexity and the requirements for deployment are therefore significantly increased.

I use an app that tells me which colour bin to put out on which day - seemingly trivial (except when you forget!) but useful and entirely self contained (and hopefully getting a Mango update with a live tile...) there's simply no need for an external service.

My app? Yes, maybe - and of course because I'm running .NET almost trivial to run the same logic (for changes to the tile) in multiple locations (-: But whilst it may be desirable its still not *necessary* for the app to do what I want it to do.
Gravatar Murph,

I understand your frustration, but the limitation is to prevent misuse by applications that the user doesn't know is running background agents. I see how your app could use them and be useful without launching the application, but it's just not possible.
Gravatar One can live with the limitation - I understand why its there, my comments were more to make the point that there are valid use cases for apps that run solely on the phone and need minimal interaction with the user. Yes, in the general case, one wants a user "using" one's application - that means in the app, doing stuff but there are things that don't need that. Interestingly I've downloaded one (already) that lets you set up a 14 day reminder to make you go visit the app and reset its background stuff. That could get, erm, irritating if you have several... hmm, doing it via the tile would be better (-:
Gravatar Thanks Shawn. This is exactly what I was looking for.
Gravatar Is there a penalty to the app for having it terminated by the OS several times (as in will the user have to relaunch it to reactivate the periodic task)? I'm interested in using location services in the background with a high accuracy but I'm concerned it will exceed the 25 second time list for periodic tasks. Thanks in advance for any feedback.
Gravatar Carlos,

The penalty is prevention of the background task being executed (black listed) but you won't run into this. The reason is that you can't do high-accuracy location services in a background task. For battery savings, location services always returns cached location services information. The AGPS is never fired up during a background task...ever.
Gravatar and so another tons of cool ideas die, because the platform-designers just wanted to throw a brick labelled "we rule here. period." in your face. guys. i know that fault-prevention is a generally good idea, but PREVENTION does not necessarily must mean MAKING-IT-IMPOSSIBLE. did you ever considered that some application environments are created by multiple teams? SEPARATE teams? and that a problem that wp7-app team stumbled upon cannot be 'simply solved' by some crapphrase like 'push is your friend' simply because it would end in impacts on symbian-team, android-team, j2me-team, ios-team, blargh-team, etc? you CANNOT try to prevent the devs from shooting their feet at every single point/feature. if the app is broken/bad/dangerous/battereater/deviceburner/etc, thats why there's certification and market reviews, not the APIs!
Gravatar Don't make a shared library as this says. It won't pass certification if you have something like a MessageBox in your shared library even if you dont use it from the periodic task. it scans the shared assembly looking for anything that a periodic task can't use and won't let you submit. Microsoft is stupid like that.

Add a Comment

*
*
*