My new article in DevProConnections Magazine is now live. If you want to see the top ten features of Windows Phone 7.5 (according to me), go see the article now!
If you have any comments, let me know!
My company, AgiliTrain, has created its spring schedule and we are happy to announce that we’re going to be expanding with new courses and new cities. Let’s take the courses first.
After much consideration, it seems to me that 2012 is going to be all about XAML *and* HTML5/JavaScript. With this in mind we’re focusing on our two new courses:
ASP.NET MVC 3, HTML5 and jQuery Course
This course is about teaching developers how to build their next generation of web sites. The course includes coverage of:
This new course focuses on taking the skills of existing XAML developers and migrating them to the web. This course includes:
In addition to new courses, we’re also expanding our lineup to include several new cities this year:
Our upcoming schedule of courses includes:
Hope to see you at one of our events!
A long labor of love of mine has finally been birthed. My Essential Windows Phone 7.5 book is now available for Kindle. You can also pre-order the physical book from Amazon or directly from Pearson. While I’ve been assured that the book is printed, sometimes it can take some time to make it into the retail chain for different outlets. To clear up some of this confusion I thought it would be helpful to tell you how you can get the book depending on which retailer you go with:
Because the book is done printing, some of the retailers that are selling the physical book may ship early so if you want the physical book, pre-ordering is still the best option. If you want to get a hold of it now, Kindle is the way to go.
I hope you enjoy the book.
So the Windows Phone Marketplace hit 40K apps. What does it mean to the platform? There are a number of articles out there that talk about the 40,000 apps and compares them to other platforms but I think they are missing a key differentiator.
Articles like the PC Magazine article point to the fact that Apple got to 50K in one year (faster than Microsoft) and that it took Android in 18 months (a tad slower than Microsoft). But to me the real remarkable news of this milestone isn’t the speed…it’s the size of the marketplace for that is astounding in my opinion.
Let’s look at the numbers. According to Garner, the 2011 Q3 numbers indicate that the worldwide market share for smartphones is (see Table of the report):
Note that is worldwide. Apple and Microsoft have better market share for the US market alone.
Why is this important? A platform that in it’s first year only got to 1.5% of the smartphone market was able to get the developer ecosystem excited enough to build and deploy 40,000 apps. How big will it be if the world’s largest handset (not smartphone) manufacturer succeeds in getting the world to buy WP7 devices? Wow…
Admittedly, I am invested in WP7 (book, classes, fandom, etc.) so I am apt to be excited by anything that improves our 1.5%. What excites me is that we got to 1.5% without Nokia. Nokia is an impressive brand…just not so much here. Where is it big? in 2/5ths of the world. When you look at China, India and Japan you find that those are monster markets. If Nokia even has mediocre success, that could change the balance. when you’re talking about 2.7 billion people. These three countries represent the 1st, 2nd and 10th biggest populations in the world. That’s 38% of the world population.
I know that population numbers aren’t strictly indicative of market size, but when you’re talking about numbers this big, even a smaller percentage of users of phones in these countries (ignoring Japan in this case), we’re still talking about much larger markets than the US or Europe.
I hope I am right…
If you're a XAML developer and have proudly stated that you hand-code all your markup, it’s time to learn how to be more productive. I’ve authored a new course for PluralSight. If you have a subscription, you can view it my new “Blend for Developers” course now:
Hope you enjoy the course!
If you are in the Washington, DC area (or are close enough to fly), I am coming to teach two courses just after Thanksgiving.
The first is my newly revamped Silverlight Tour course that has been updated for Silverlight 5. This three-day course includes information on how to build line-of-business applications using Silverlight. Topics include:
If you’re trying to get up to speed with the latest version of Silverlight, or are new to XAML-based development – this is the course for you. Free with every attendance to the Silverlight Tour are several key tools:
If you signup before November 2nd, you get the early-bird pricing of $1,695 for the course! You can register for the event being held on Nov 30-Dec 2nd here:
https://agilitrain.com/Workshop/EventInfo/267
If you would like an outline of the course, get it here!
Web Development for XAML Developers
In addition, I am debuting a brand new course called “Web Development for XAML Developers”. In this two-day course I help XAML developers take their design, data binding and MVVM knowledge and apply it to client-side web development. This course will cover
Since this is our first holding of this course, we’re introducing a special pricing for this and only this event of $1,295 ($200 off). If you register before Halloween, you can get an additional $300 off (for a final price of $995)! You can register for November 28-29th event for this special price here:
https://agilitrain.com/Workshop/EventInfo/275
You can get an outline of the course here.
After 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:
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.
I am happy to announce my new online course on using Silverlight Server Communication is now available on Pluralsight. This course covers the basics of using services from with Silverlight projects. The course covers:
You can view the course online at Pluralsight’s website:
If you don’t already have a subscription to Pluralsight’s content, you can get sign up for only $29 per month for all their content, including my courses.
I am headed to Build Windows next week and I have a lot of hopes for the conference. I haven’t been to a conference as an attendee alone in quite a long time. I am anxious to see what the v.Next is out of Redmond.
I didn’t get to go to the 2000 PDC that changed everything…so I really wanted to be here for this conference. Is this going to change everything again? I have no earthly idea but I hope for a mix of new and old.
Here is what will happen at Build if this were a perfect world:
Here’s crossing my fingers.
(NOTE: I’ve been asked a lot lately about what is happening at Build Windows. To be clear, I have no idea what is going to happen…but you should keep your eyes out to see what’s happening.)
One major feature that was much requested for the new version of Windows Phone was the ability to run agents behind the scenes. The desire was to be able to execute code periodically so that a developer’s application could keep itself up to date (or tell the user about a change) when the application was not running. Microsoft has allowed this in Mango (e.g. Windows Phone OS 7.1) and allows several different flavors of agents:
For this post, I will focus on the Periodic Agents. Periodic agents run every 30 minutes but with some limitations:
Creating a Periodic Agent
Periodic agents run as an included assembly in your .xap file (but a separate assembly from the startup assembly). By picking File->New->Project you can pick the “Windows Phone Scheduled Task Agent” project type. This will create a new project in your solution and create a skeleton class for you:
using Microsoft.Phone.Scheduler;
namespace BackgroundAgent
{
public class ScheduledAgent : ScheduledTaskAgent
{
protected override void OnInvoke(ScheduledTask task)
{
//TODO: Add code to perform your task in background
NotifyComplete();
}
}
}
The OnInvoke call is where your code happens. Once your task has completed, you need to call the NotifyComplete method to tell the operating system you are completed with the background task. These are short tasks and will only run for a short period (typically less than 15 seconds) so making your code very concise is important.
Once you have the agent assembly, you need to associate it with your main project (so it’s included in the .xap file) by simply making a reference to it. In addition, the project template will delve into the WMAppManifest.xml file and add an “ExtendedTask” element that points a the type name of the background agent:
<Tasks>
<DefaultTask Name="_default"
NavigationPage="MainPage.xaml" />
<ExtendedTask Name="MyBackgroundTask">
<BackgroundServiceAgent Specifier="ScheduledTaskAgent"
Name="FooManMark"
Source="BackgroundAgent"
Type="BackgroundAgent.ScheduledAgent" />
</ExtendedTask>
</Tasks>
Your application can have more than one ExtendedTask but each Extended Task has to support a different kind of background agent. Specifically the BackgroundServiceAgent’s Specifier property must be unique. So that means you can only have one scheduled agent and one of each of the audio agent types. The names of the ExtendedTask and BackgroundServiceAgent elements are not important so you do not have to keep these in sync with what you use in code as you will see next.
Adding Code to Your Agent
Now that your agent is ready to be deployed to a device, you can add your code to the OnInvoke method like so:
protected override void OnInvoke(ScheduledTask task)
{
// If the Main App is Running, Toast will not show
ShellToast popupMessage = new ShellToast()
{
Title = "My First Agent",
Content = "Background Task Launched",
NavigationUri = new Uri("/Views/DeepLink.xaml", UriKind.Relative)
};
popupMessage.Show();
NotifyComplete();
}
Notice that you can run any code you need. In this case I am using a Toast message to alert the user. (As an aside, toast messages will only show if the main application is not running). As long as the code you have in here does not violate the memory, APIs or time limitations, you’re good to go.
Registering Your Agent
Finally, in your main application you will need to register the background service. You can accomplish this with the
// A unique name for your task. It is used to
// locate it in from the service.
var taskName = "MyTask";
// If the task exists
var oldTask = ScheduledActionService.Find(taskName) as PeriodicTask;
if (oldTask != null)
{
ScheduledActionService.Remove(taskName);
}
// Create the Task
PeriodicTask task = new PeriodicTask(taskName);
// Description is required
task.Description = "This saves some data to Isolated Storage";
// Add it to the service to execute
ScheduledActionService.Add(task);
You will want to use a unique task name so you can find your background task when you need to register it. This name is unique to your application so you can make it whatever you want. You can see in this example that the first thing I do is find the old task so I can remove it and replace it with a new task. Next I create a new PeriodicTask object that contains the information about the agent. The only required field is the Description property. The description is shown to users when they are reviewing background tasks in the OS’s management UI. This means the description should be in plain English that makes sense to end-users.
Finally you can schedule the background agent by adding it to the ScheduledActionService (same service that is used to schedule Alarms and Reminders). The information about what assembly to load and the name of the class is all read in from the WMAppManifest.xml file so you do not need to specify it here.
Once you do this, your service will start running approximately every 30 minutes (unless the user has disabled background tasks or battery saver is on).
Testing Your Agent
You could just wait 30 minutes to debug your background task but that is not very helpful. Instead the ScheduledActionService has a static method called LaunchForText. This method should be used to execute your task for debugging purposes:
var taskName = "MyTask"; ScheduledActionService.LaunchForTest(taskName, TimeSpan.FromMilliseconds(1500));
The same name you used to register the agent should be used as the first parameter to the LaunchForText method. The second parameters let’s you specify how soon to execute the service. This is often used to give you time to kick off the launch and exit the application. The debugger will remain connected to let you actually debug your code.
Only caveat about debugging agents is they can only be debugged once per session. If you need to re-run your agent, you’ll need to re-start the debugger.
Conclusion
Using these simple agents can help you accomplish specialized operations where you need code to be executed behind the scenes without hampering the performance or battery of the phone itself. You still don’t have a blank check to run background code, but this will fill out some significant use-cases.
Check out my Pluralsight Courses:
Ready to start building Mango Applications? This is the book for you. I teach you how to build apps using Windows Phone OS 7.1. Order today!
