Tag: Windows Phone
A lot has been made since a report from Microsoft late last week (http://shawnw.me/HPEh0R) that seemed to say that Silverlight on the phone was going away in Windows Phone 8 (Apollo). I liked a lot of what this article had to say (from e-week):
http://shawnw.me/IwMgR2
So it got me thinking that much of the Silverlight community would be jumping out of windows (lower case and not TM) this week due to the news. But of course, if that's the case for you, I'd urge you not to panic. Why? Let me tell you.
CAVEAT: I am guessing and have no inside knowledge on what Windows Phone 8 is going to do. Really!
Silverlight and Me
I came into Silverlight because of my prior work with WPF. But it's more complicated than that. I came to WPF at a time when I was primarily known as a database guy (my old moniker was "The ADO Guy"). So why would I care about WPF? Data binding.
I am not a UI/UX guy. I can barely match my own socks. But I came to XAML because I saw the potential of building apps using a smart markup language that has the possibility of a real data binding framework (unlike MFC, VB5/6, WinForms, ASP.NET WebForms before it).
I got into Silverlight because I lucked into being there at the ground floor (I taught a WPF/E course at Microsoft to MS employees and partners before it was publically named). But even in the early days of XAML + JS, I saw the potential of building apps (not sites) with XAML. The fact that Silverlight was originally to build them in the browser was tangential. In fact, I liked Silverlight (v2 and beyond especially) because it learned from the lessons of WPF (which in my opinion is over engineered somewhat) and simplified the XAML so that it was consumable in a short period. The lack of features like Triggers and a simplified text stack meant that people could get up to speed fairly quickly.
Windows Phone 8 and XAML
What the Microsoft folks said was that Windows Phone 8 development would be much more like Windows 8 XAML development. That meant that Windows Phone 8 would probably have the underpinnings of WinRT. Should anyone panic? Nope. Here is why.
The WinRT XAML stack is based on Silverlight 4. What losing Silverlight does is say that the XAML (and data binding stacks) are going to be unmanaged. That's a good thing. In Silverlight (especially on the phone) the managed part of the XAML stack (data binding et al.) got in the way of a great touch experience. In Mango, the Windows Phone team built several ways of keeping the experience smooth by doing a lot of tricks, but it is still pretty easy to screw it up as a developer. WinRT works differently. The entire XAML stack is in unmanaged code and the entire WinRT framework is built with async in mind. It makes it easier to build fluid, touch-enabled applications (or it should).
The other benefit is that it brings together the Metro-style application development on tablets and the phone. This is a big win for developers. This is likely not going to result in a single app working on both devices, but it should allow many of the assets to be more sharable. We have no details or promises yet, but if some of the features of WinRT come to the phone, we're all in luck. I am especially looking forward to Contracts.
WinRT XAML Development
I've been digging into the Windows 8 XAML stack and as of the Consumer Preview I am really enjoying the experience. The Consumer Preview build is pretty close to Silverlight's implementation IMO. There are likely some missing pieces, but all the big pieces are there. Adding to that, the great Visual Studio 11 XAML editing experience (powered by Blend) and I think you'll find the development experience is really good right now.
If you're a Windows Phone developer already, the experience of developing for Windows 8 (and Windows Phone 8 probably) will be pretty similar. App.xaml holds the application level events. Navigation to individual XAML files and support for a back-stack. Adding to the benefits here are things like Live storing of settings in the cloud (instead of inventing this yourself) as well as smoother touch APIs mean that the transition to WinRT should be smooth for Windows Phone developers.
If you're a WPF or Silverlight developer, there are pieces to learn (like Navigation and touch) but the XAML design experience should very familiar. If you're not digging into WinRT yet, it's time to dip your toes into the water!
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!
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):
- Android: 52.5%
- Symbian: 16.9%
- iOS: 15%
- RIM: 11%
- Bada: 2.2%
- Microsoft: 1.5%
- Others: 0.9%
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…
As many of my readers know, I’ve been neck deep in the Windows Phone. More recently, I’ve been digging into Windows 8 development as well. On my most recent trip, I spent quite a bit of time with the BUILD tablet. Good news is that it’s a pretty good piece of hardware. Even though it’s not ARM, I am still getting a good four hours of battery life. This version of Windows 8 is early but I do think there are some things that Windows 8 should learn from what they’ve done with the Windows Phone. Here is a short list of what I think the team should look at on the phone:
In-App Back Button
On the phone, the back button represents a major way to navigate in an application. In Windows 8, you can swipe back but that doesn’t take you back to the last page in an application, it takes you to the last Metro-style app. I know you can swipe up to show the ‘ApplicationBar’ and it can have a back button, but I think this is a mistake. The phone learned that users want a single back button that works everywhere…it’s more intuitive.
Hold Back Button
In Mango (7.5), you can hold the back button to get a list of the recently run apps. We need something similar on Windows 8. When looking for an app I am (was) running, just using the back swipe is not good enough. It’s too hard to tell what I was doing. I find myself going through the swipe-back list twice to find what I wanted (I find the app, but I just passed it so I slow down the 2nd time).
Simple Live Tile Management
The way that Live Tiles can be dragged and ordered on the phone works really well. People can pick it up fast. On Windows 8, I find myself confused about where the tile is going to end up. Is it in a list where it’s last? Can I drag it between two? I don’t get it. I love the grouping and the different sized tiles, but the management of it isn’t intuitive to me.
Input Scopes
Anyone who knows me knows that a Windows Phone app that doesn’t use good InputScopes makes me crazy. The same is true for Win8. My problem is that there don’t seem to be any contextual keyboards (so far) on Windows 8. The layout of the default keyboard hides too many keys I want. And if they would embrace InputScope so that keys would appear that are contextually important – I’d be a lot happier with text input.
AutoCorrect
Related to the Input Scope issue is that fact that auto-correct seems to be missing completely. If it’s going to be a touch interface, you have to have integrated autocorrect (with a single dictionary). It needs to be integrated across the OS, not tacked on to WinRT (e.g. should work everywhere, not just in Metro Apps). Period. End of story!
Copy/Paste
While not everyone loves the copy/paste gestures on the phone, they work. We need another solution than the Ctrl-C/Ctrl-V solution I am using currently. Again, it needs to be integrated across the OS, not tacked on to WinRT (e.g. should work everywhere, not just in Metro Apps).
What Should WinPhone 8 Learn from Win8?
I am not letting Windows Phone off the hook either. One of the things that I think Win8 gets right are “Contracts”. Contracts are the ability for system-wide verbs to be implemented by producers and consumers. A good example of this is Search. You can implement the “You can search my app’s data” contract so that the search bar in Win8 includes your application in the list of apps to search. You can also implement the “You can search from my app” contract (the other side of that contract). There are a handful of these: Search, Share, Picker are three well known ones. There are apt to be more.
On Windows Phone we get some of this through Tasks and Choosers, but that really means that our applications can consume OS-level verbs (e.g. take a picture, get me an address). But contracts are what we really should have. I should be able to say “Share this from my app” as well as “Share through my app”. When an app wants to share a link, we should present them with a set of apps that can share information so I don’t have to have Twitter integration at the OS level. I could say, “Share This Link” and the user could pick to share it via Rowi instead of the Twitter integration.
What do you think the two could learn from each other?
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.
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:
- Periodic Agents: Code that run about every 30 minutes.
- Resource Intensive Agents: Code that runs when the phone is plugged-in and has a WiFi connection (or when plugged into USB).
- Audio Agents: Code that is run in the background to provide audio to the user (e.g. for Pandora-like applications).
For this post, I will focus on the Periodic Agents. Periodic agents run every 30 minutes but with some limitations:
- Forbidden APIs (most anything to do with the UI like accessing the camera).
- 5MB of Memory Maximum (OS will kill process if breaks this limit).
- App must re-register agent every two weeks (e.g. if user doesn’t run your app every two weeks, it will cease to execute).
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.
In my previous post, I encouraged users to upgrade their applications to the newest version of the Windows Phone so that users that get Windows Phone 7.5 (or developers who already have it) can benefit from a newer version of your application. While I readily admit, some of that post is pure selfishness as I want apps to be ready for Mango (and on my phone ;) But there are some things to consider.
If you haven’t noticed, the Windows Phone Marketplace now has 30,000 applications. Yeah, 30K. That’s a lot of applications. While some of my favorite apps do update themselves fairly often, many of the 30K applications do not. Why does this matter?
The reality is that today you can now upload applications and update for Windows Phone 7.5. That’s great news. Those of us with applications can prepare our application for the coming phones. Wahoo! Or not? The problem is that if you choose to update your application for Windows Phone 7.5, you can no longer update your application for Windows Phone 7.
That means that if you release a Mango version of your application, you’re stuck with the Mango version. At some point that will make sense for authors of often updated apps but for now, most of them (I suspect) will keep with their 7.0 versions. If you have applications like mine which don’t get updated much (as they may be simple or topical), then upgrading to Mango may make sense. For example, I upgraded GooNews specially because I was ditching the in-app browser and just opening up IE instead. The reason I did this was that the Mango browser has additional functionality that I didn’t need to build (e.g. Share Link). Since Mango had Fast App Switching, going out to IE and hitting back button to get back to GooNews without any wait made sense for me.
I am not sure I totally condone this approach, but there are some who are using the Environment.OSVersion.Version property to determine if the phone itself is a Mango phone and then using reflection to use mango features. You can see this in practice here:
I’ve heard that applications with this technique *will* pass through certification so it’s safe to use, though I feel a little uneasy at the fragility of it. But until Mango has a solid user-base.
URL: MangoAlarms.zip
Ok, maybe I like my distracting titles…my apologies.
As many Windows Phone developers have noticed, Mango (e.g Windows Phone SDK 7.1) supports background processing through something called Agents. While Agents are certainly a welcome addition, I am exceptionally impressed in the fact that Mango also supports a bunch of features to avoid having to have background processing agents. In this post, I’ll show you one of these: Alarms.
The general idea of Alarms is being able to create application specific alarms (not just using the Alarm clock app). Alarms do come with a couple of small caveats:
- Alarms are fired once per minute. Sub-minute alarms will round to the minute.
- Alarms shown over lock screen cannot launch your application.
- Cannot control how long an alarm is snoozed.
- Alarm’s Title is always “Alarm”.
- Can only launch the application, not a deep link to a specific page.
To compliment alarms, the phone also supports Reminders which can overcome some of these limitations, but I’ll show them in a future post.
With that in mind, you can create your own alarms and even specify the type of alarm sound that is played. To do this, create an instance of the Alarm class (in the System.Phone.Scheduler namespace):
// Alarm Name (unique per app)
var alarmName = Guid.NewGuid().ToString();
// Create the Alarm
var alarm = new Alarm(alarmName)
{
// When the Alarm should sound
BeginTime = DateTime.Now.AddMinutes(1),
// The Message in the Alarm
Content = "Mango Alarm",
// Exists on Alarms, but it not used
//Title = "Not used!",
// What sound to play for the alarm
Sound = new Uri("alarm.wav", UriKind.Relative)
};
Each alarm must be named (unique, per application) so you can look it up later (if you want to disable it or remove it). BeginTime when the alarm should fire. Content is the message shown in the UI. Finally, Sound allows you to specify a sound file (mp3, wma or wav) to be played. This file must be delivered with your .xap file (can’t be in isolated storage or via an Internet connection). While the Title property exists on the Alarm class (because of the base class), it will throw an exception if set to ensure that you don’t think the Title will be used.
Once you create the alarm, you can register it like so:
// Add the Alarm to the Phone
ScheduledActionService.Add(alarm);
The ScheduledActionService is a class that is used to register reminders, alarms and agents. The Add method simply adds the alarm to the phone. The other methods of the service are also supported by the Alarms as well (e.g. Find, Remove, Replace and GetActions). There you go, you can now add your own alarms!
In Windows Phone OS 7.0, you could update your Live Tiles (but not create them) – but you had to do it via a push notification. In Windows Phone OS 7.1, this changes to allow you to not only update the Live Tile for your application, but your application can create multiple Live Tiles.
The ShellTile class gives you access to all the Live Tiles for your application. Before you ever create a single tile, you always have one tile. This tile is the default tile that your application will show if the user manually pins an application to the home screen. You can add additional Live Tiles manually. Each of these additional tiles are specifically to link deeply into your application. For example, if I had an airline application, I could have additional tiles that linked directly to individual flights. Let’s get started.
Updating the Default Live Tile
You can use the ShellTile class to retrieve the default tile like so:
// Get the default tile
ShellTile firstTile = ShellTile.ActiveTiles.First();
You can update the data in the shell tile, but creating an instance of the StandardTileData class as shown here:
// Create the new data
var newData = new StandardTileData()
{
Title = "AgiliTrain",
BackgroundImage = new Uri("background.png", UriKind.Relative),
Count = 3,
};
// Update the default tile
firstTile.Update(newData);
You can create the StandardTileData instance to contain the new, updated information then call the ShellTile’s Update method to update the tile. This updates the tile immediately.
Creating New Live Tiles
In addition, you can create new tiles with the same classes:
var newTile = new StandardTileData()
{
Title = "A Deep Link",
BackgroundImage = new Uri("background.png", UriKind.Relative),
Count = 42,
};
var uri = "/DeepLink.xaml?state=From a Live Tile";
ShellTile.Create(new Uri(uri, UriKind.Relative), newTile);
The StandandTileData includes information about the new Live Tile. You also need a Uri that points to a deeper part of the application. In this case the Uri points at a deeplink.xaml file that is in my project and I am including query string information. This Uri is important as each tile must point at a different Uri to your application. Finally you can use the ShellTile.Create method to then create the new tile.
When the Create method is called, your application will be suspended and the user will be taken to the Live Tile on the home screen. This behavior is to prevent unwanted new Live Tiles. This makes it clear that the current app is the one adding the Live Tile and allows the user an opportunity to remove it. Hitting the back button returns them to your application (with Fast App Switching).
Updating Secondary Live Tiles
If you need to update tiles that are on the home screen, you can use the same method used earlier to find the default tile to find these secondary tiles. Usually you would use an Uri to do the search like so:
var uri = new Uri("/DeepLink.xaml?state=From a Live Tile",
UriKind.Relative);
var myTile = ShellTile.ActiveTiles.Where(t => t.NavigationUri == uri);
// Update the tile
if (myTile != null)
{
// ...
}
Live Tile Backs
Finally, any of these Live Tiles now can also have information on the back of the tile. This back of the tile is occasionally shown by the home screen and should be used to show additional, but not critical information. The StandardTileData class contains properties for the background. The background contains a different format. You can see the back of a tile in the image above (the third Live Tile). The back of the Live Tile is handled with these additional properties:
- BackTitle: The small text on the bottom of the tile.
- BackContent: A short piece of text that takes most of the tile
- BackBackgroundImage: An image that takes the whole space of the back of the tile (must be 173x173 and be .png file).
You can see these properties used below:
var newTile = new StandardTileData()
{
Title = "A Deep Link",
BackgroundImage = new Uri("background.png", UriKind.Relative),
Count = 42,
BackContent = "This is the back",
BackTitle = "The Back",
BackBackgroundImage = new Uri("http://foo.com/moonimage.jpg")
};
var uri = new Uri("/DeepLink.xaml?state=From a Live Tile",
UriKind.Relative);
var myTile = ShellTile.ActiveTiles.Where(t => t.NavigationUri == uri);
Make sense?
A lot has been made since a report from Microsoft late last week (http://shawnw.me/HPEh0R) that seemed to say that Silverlight on the phone was going away in Windows Phone 8 (Apollo). I liked a lot of what this article had to say (from e-week):
