将我的Windows Phone应用程序更新到Windows Phone 8

Earlier this year I wrote a small Windows Phone 7 application in a day called Lost Phone Screen. It creates lock screens for you with your name and contact number on them to aid in finding your phone the old fashioned way when you lose it. No need for a GPS, just tell folks you have a small reward and give them a number to call. You can download it free now as folks will not pay 99 cents for anything except Angry Birds. But I'm not bitter. ;) Anyway, it works great on Windows Phone 7 and Windows Phone 7.5 (Mango.)

今年早些时候，我一天写了一个小的Windows Phone 7应用程序，称为“丢失的电话屏幕” 。 它会为您创建锁屏，上面带有您的姓名和联系电话，以帮助您在丢失手机时以老式的方式找到手机。 无需GPS，只需告诉人们您可获得少量奖励，然后给他们打个电话即可。 您现在可以免费下载它，因为除了《愤怒的小鸟》以外，其他任何人都不会支付99美分。 但是我并不苦。 ;)无论如何，它在Windows Phone 7和Windows Phone 7.5(芒果)上都很好用。

Recently I got a Nokia Lumia 920 with Windows Phone 8 and since there's a number of new APIs and features I could exploit - not the least of which being the ability to programmatically set the phone's Lock Screen without the user needing to do anything - I figured it was time to update it.

最近，我得到了带有Windows Phone 8的Nokia Lumia 920，并且由于可以利用许多新的API和功能-尤其是能够以编程方式设置手机的锁定屏幕而无需用户执行任何操作的能力-我认为是时候更新它了。

I encourage you to review the post From Concept to Code in 6 hours: Shipping my first Windows Phone App as a reminder of what the app did and the issues I had writing the Windows Phone 7.x version.

我鼓励您在6个小时内阅读从概念到代码的文章：交付我的第一个Windows Phone应用程序，以提醒该应用程序做了什么以及我在编写Windows Phone 7.x版本时遇到的问题。

Here's what I had to think about updating the app for Windows Phone 8. Big thanks to my friend Justin Angel at Nokia for brainstorming on Skype with me and helping with the async code and resolution issues. His blog post on What's New in Windows Phone 8 was very useful, especially his little MultiRes helper class.

这就是我为Windows Phone 8更新应用程序的思考。非常感谢诺基亚的朋友贾斯汀·安吉尔( Justin Angel)与我一起在Skype上集思广益，并帮助解决了异步代码和解析问题。 他的博客文章“ Windows Phone 8的新增功能”非常有用，尤其是他的MultiRes小助手类。

更新应用 (Updating The App)

First, to be clear, the existing Windows Phone 7 app works great on Windows Phone 8 without ANY changes. It runs and behaves exactly on Windows Phone 8 as it did on Windows Phone 7. I wanted to update it in order to "light up" some the new features on the new OS.

首先，需要明确的是，现有的Windows Phone 7应用程序在Windows Phone 8上运行良好，无需进行任何更改。 它在Windows Phone 8上可以像在Windows Phone 7上一样运行并正常工作。我想对其进行更新，以“点亮”新操作系统上的某些新功能。

将项目升级到Windows Phone 8 (Upgrading the Project to Windows Phone 8)

Upgrading was easy, I opened the old project and was prompted to upgrade. I double-clicked on the WMAppManifest.xml and made sure to reassert some of the basic settings like icon sizes and tiles for my app, as well as confirming the capabilities that my app would need like photo access, etc.

升级很容易，我打开了旧项目，并提示升级。 我双击WMAppManifest.xml并确保重新声明一些基本设置，例如我的应用程序的图标大小和磁贴，以及确认我的应用程序需要的功能(例如照片访问权限等)。

I was sure to check the Supported Resolutions as I knew I'd need those later.

我确定要检查受支持的决议，因为我知道以后需要这些决议。

保留两个分支与一个超级项目 (Keeping two Branches vs. One Super Project)

I went back and forth on this. It's an upgraded OS but 99% of the code will be shared. However, enough stuff has changed that I decided to make a branch in source control rather than make a single build. Honestly, there's likely no wrong answer here and you use what you're comfortable with. I could have to CSProj files if I liked, or just made a different Build Configuration (like Debug8 and Debug7, etc) but I understand my source control pretty well so I ended up with a phone70 and a phone80 branch and I switch between them. It's more likely that I'll be updating the phone80 branch then "back porting" new feature so for now this work fine, but know I can always make a single build if I want.

我在这方面来回走了。 这是一个升级的操作系统，但是99％的代码将被共享。 但是，已经发生了足够的变化，我决定在源代码管理中创建一个分支，而不是进行单个构建。 老实说，这里可能没有错误的答案，您可以使用自己喜欢的东西。 如果愿意，我可能必须使用CSProj文件，或者只是进行了不同的构建配置(如Debug8和Debug7等)，但我对源代码控制了解得很好，所以最终得到了phone70和phone80分支，并在它们之间进行了切换。 我更可能会先更新phone80分支，然后再“反向移植”新功能，因此目前可以正常工作，但知道我可以随时进行单个构建。

Ultimately though, I know that I need to make a build for Windows Phone 7.x and one for Windows Phone 8 but I can submit them each to the Store under the same name and the Store will do the right thing. If you've got Windows Phone 8 with a new resolution you'll get the right version as you can see in the screenshot below. I've submitted two XAP files.

最终，尽管我知道我需要为Windows Phone 7.x和Windows Phone 8构建一个版本，但是我可以使用相同的名称将它们分别提交给商店，并且商店将做正确的事情。 如果您拥有具有新分辨率的Windows Phone 8，则将获得正确的版本，如下面的屏幕快照所示。 我已经提交了两个XAP文件。

新屏幕分辨率 (New Screen Resolutions)

I updated my app a few weeks ago but my first good bug came in from a gent with a HTC Windows Phone device running at 1280x720, rather than 1280x768. He said my lockscreens were cropped! With Windows Phone 8 there's three resolutions, in fact as Justin points out:

几周前，我更新了我的应用程序，但我的第一个好错误来自一个运行1280x720而不是1280x768的HTC Windows Phone设备的绅士。 他说我的锁屏被裁剪了！ 贾斯汀指出，使用Windows Phone 8，有三种解决方案：

The resolutions are: WVGA (480x800 pixels), also used in Windows Phone 7; WXGA (768x1280 pixels), essentially an HD version of WVGA; and the wildcard 720P (720x1280 pixels) that uses a different aspect ratio to WVGA and WXGA. You should be aware of these different resolutions, make sure to use relative <Grid /> positioning in laying out screens, and potentially different media assets for different resolutions.

分辨率为：WVGA(480x800像素)，也用于Windows Phone 7中。 WXGA(768x1280像素)，基本上是WVGA的高清版本； 而通配符720P(720x1280像素)则对WVGA和WXGA使用不同的宽高比。 您应该注意这些不同的分辨率，请确保在布局屏幕时使用相对的<Grid />位置，并针对不同的分辨率使用可能不同的媒体资产。

It's less important that there's three resolutions but rather more interesting that 720p is a different aspect ratio! Turns out I was making a number of assumptions in my code, not the least of which being the screen resolution. I was assuming 15:9 as the aspect ratio like 800x480 and 1280x768, but 16:9 is 1280x720!

拥有三种分辨率并不是那么重要，但是更有趣的是720p是不同的宽高比！ 事实证明，我在代码中做出了许多假设，其中包括屏幕分辨率。 我假设15：9是长宽比，例如800x480和1280x768，但16：9是1280x720！

My initial reaction was, crap, now I have to actually think.

我最初的React是，废话，现在我必须真正思考。

Turns out that it's easier than that. On all of my app's pages but one I was able to remove XAML code and hard coded margins and row definitions. I was actually being too specific and not letting the system lay itself out optimally.

事实证明，这比这更容易。 在我应用程序的所有页面上，但只有一个页面，我能够删除XAML代码以及硬编码的边距和行定义。 我实际上过于具体，没有让系统以最佳方式进行布局。

I removed all my hard-coded margins and changed my Grids to use a RowDefinition of "*" which means "the rest of the space" like this:

我删除了所有硬编码的边距，并更改了网格以使用“ *”的RowDefinition，这意味着“其余空间”是这样的：

<Grid x:Name="LayoutRoot" Background="Transparent">
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto"/>
        <RowDefinition Height="*"/>
    </Grid.RowDefinitions>
...
</Grid>

The first RowDefinition fills to the size of its content and the second just takes up the rest. This made all my pages look great on every resolution screen, and it was easy to test because I could just change the Emulator dropdown to select the various  resolutions:

第一个RowDefinition填充了其内容的大小，第二个RowDefinition占据了其余内容。 这使我的所有页面在每个分辨率屏幕上看起来都很好，并且易于测试，因为我可以更改“模拟器”下拉列表以选择各种分辨率：

However, with these new resolutions, I did change my originally single SplashScreenImage.jpg to include one each for the three resolutions named SplashScreenImage.Screen-720p.jpg, SplashScreenImage.Screen-WVGA.jpg and SplashScreenImage.Screen-WXGA.jpg. You'll find that at least half your time doing mobile apps (regardless of Apple, Windows or Android) is getting the PNGs and artwork files correct).

但是，使用这些新分辨率，我确实更改了我原来的单个SplashScreenImage.jpg，使其分别包含三个名为SplashScreenImage.Screen-720p.jpg，SplashScreenImage.Screen-WVGA.jpg和SplashScreenImage.Screen-WXGA.jpg的分辨率。 您会发现至少有一半的时间在使用移动应用程序(无论Apple，Windows或Android)上都能正确使用PNG和美工图文件。

I had (chose) to hard code some screen sizes in one place in the app. (I could have queried  Application.Current.Host.Content.ScaleFactor. Application.Current.Host.Content.ActualHeight and Application.Current.Host.Content.ActualWidth to be correct.) I have a VERY specific custom Image Cropping control that needed special handling for the 720p case, likely due to my lack of skill with XAML. I am told that only the most edgy of edge cases need to do this and often this is in the creation of pixel-perfect lock screens so you probably won't sweat it at all.

我不得不(选择)在应用程序中的某个位置硬编码一些屏幕尺寸。 (本来可以查询Application.Current.Host.Content.ScaleFactor。Application.Current.Host.Content.ActualHeight和Application.Current.Host.Content.ActualWidth正确。)我有一个非常特定的自定义图像裁剪控件，它需要720p情况的特殊处理，可能是由于我缺乏XAML技能。 有人告诉我，只有边缘情况最恶劣的情况才需要这样做，而且通常这是在创建像素完美的锁屏时进行的，因此您可能根本不会发汗。

新的锁屏API (New Lock Screen API)

Finally my app can update the Lock Screen without manual user intervention. This was my #1 request and everyone assumed it was my fault that the feature didn't exist. It's been added in Windows Phone 8.

最后，我的应用程序可以更新锁定屏幕，而无需人工干预。 这是我的第一要求，每个人都认为该功能不存在是我的错。 Windows Phone 8中已添加它。

If you app wants to change the Lock Screen it has to ask once and get permission. It has to be the "current lock screen provider." If it is, it requests access and then sets the lock screen.

如果您的应用要更改锁定屏幕，则必须询问一次并获得许可。 它必须是“当前锁定屏幕提供程序”。 如果是，它将请求访问权限，然后设置锁定屏幕。

if (!LockScreenManager.IsProvidedByCurrentApplication)
{
    LockScreenRequestResult result = await LockScreenManager.RequestAccessAsync();
    if (result == LockScreenRequestResult.Granted)
    {
        SetAsWallpaper(filename);
    }
}
else
{
    SetAsWallpaper(filename);
}

SetAsWallpaper is just a helper around LockScreen.SetImageUri().

SetAsWallpaper只是LockScreen.SetImageUri()的助手。

private void SetAsWallpaper(string filename)
{
    string realPath = "ms-appdata:///local/" + filename;
    Debug.WriteLine(realPath);
    //Debug.WriteLine(ApplicationData.Current.LocalFolder.Path);

    LockScreen.SetImageUri(new Uri(realPath, UriKind.Absolute));
}

And that's it. Lovely and simple. BUT.

就是这样。 可爱又简单。 但。

使用异步API时的重要提示 (A Very Important Reminder when using Asynchronous APIs)

In Windows 8 and Windows Phone 8 (since the Windows 8 magic dust is under Windows Phone 8) everything is all about asynchrony and non-blocking APIs. Before I'd just save the wallpaper and you'd wait and you had no choice. Now all the underlying APIs are asynchronous  (non-blocking) and we as developers have await/async keywords to make things simple, right?

在Windows 8和Windows Phone 8中(由于Windows 8的尘埃落在Windows Phone 8中)，所有内容都与异步和非阻塞API有关。 在我只保存墙纸之前，您要等待，您别无选择。 现在，所有基础API都是异步的(非阻塞)，并且作为开发人员，我们有await / async关键字来简化操作，对吗？

Sure, but my second lovely bug that showed up was when folks mashed on the Save button many times. Because everything is non-blocking this would fire off many save requests and eventually they'd collide at the file system with an "Access Denied" or something equally useful.

可以，但是我出现的第二个可爱的错误是当人们多次按下“保存”按钮时。 因为所有内容都处于非阻塞状态，这将触发许多保存请求，最终它们将通过“访问被拒绝”或同样有用的方法在文件系统上发生冲突。

I have this shared resource that I need to protect access to but I don't want to block the UI. Michael L Perry has a great solution for this that should probably be built into the Windows Phone SDK (unless it is and we've all missed it?) in his Awaitable Critical Section helper. This helper lets us use the familiar using{} block structure in situations where we are using async and await inside what would have been a lock(){} block.

我有此共享资源，需要保护对它的访问，但我不想阻止UI。 Michael L Perry为此提供了一个很好的解决方案，应该将其内置到Windows Phone SDK中(除非确实如此，我们都错过了它？)在他的“等待关键部分”帮助器中。 在使用异步并在可能是lock(){}块的内部等待的情况下，此帮助程序使我们可以使用熟悉的using {}块结构。

As Michael points out, you CAN'T do this because you can't await in a lock.

正如Michael指出的那样，您无法执行此操作，因为您无法等待锁。

lock (this)
{
    FileHandle file = await FileHandle.OpenAsync();
    await file.WriteAsync(value);
    file.Close();
}

But with his helper you can do this:

但是借助他的助手，您可以执行以下操作：

using (var section = await _criticalSection.EnterAsync())
{
    FileHandle file = await FileHandle.OpenAsync();
    await file.WriteAsync(value);
    file.Close();
}

And I did just that.

我就是这样做的。

分析 (Analyze)

When you're done, make sure you run the Windows Phone Application Analysis tools see how your application does. Does it use too much memory? Use up the battery? Does it startup in less than a second?

完成后，请确保运行Windows Phone应用程序分析工具，以了解应用程序的工作方式。 它会占用太多内存吗？ 电池用完了吗？ 它是否会在不到一秒钟的时间内启动？

This is fascinating stuff. Don't work so hard on your app and forget to profile it.

这是令人着迷的东西。 不要在您的应用程序上如此努力地工作，而忘了对其进行概要分析。

提交应用程序和提交两个版本时要记住的新事物 (New Things to Remember when Submitting Your App and Submitting Two Versions)

I fixed some bugs in the Windows Phone 7 version, changed that XAP's version number and submitted it as a small upgrade. Folks who have Windows Phone 7.x will get prompted to update their app. This version, as you'll recall, doesn't auto-update the lock screen because it can't.

我修复了Windows Phone 7版本中的一些错误，更改了XAP的版本号并将其作为小升级提交。 拥有Windows Phone 7.x的人们将被提示更新他们的应用程序。 您会记得，此版本不会自动更新锁定屏幕，因为它不能。

I go into the Phone Marketplace and click Update App from the Dashboard. There's the Marketplace before my update, showing the 7.1 app:

我进入手机市场，然后从仪表板上单击更新应用程序。 我的更新之前有一个市场，显示7.1应用程序：

I click Update selected and upload the new Windows Phone 7.1 targeted XAP that I just built. After that's uploaded I change the dropdown and upload the Windows Phone 8 XAP. I make sure in both cases to upload a Release XAP and the "AnyCPU" version.

我单击“更新所选内容”，然后上传刚刚构建的新的Windows Phone 7.1目标XAP。 上传之后，我更改下拉列表并上传Windows Phone 8 XAP。 在这两种情况下，我都确保上载Release XAP和“ AnyCPU”版本。

I am keeping the Windows Phone 8 one a few versions ahead for my own sanity. It makes sense to me and it helps me remember what's "newest" even though it only matters that the new versions be higher than the previous versions.

为了我自己的理智，我将Windows Phone 8保持几个版本的领先地位。 这对我来说很有意义，并且可以帮助我记住什么是“最新”，即使新版本高于先前版本也很重要。

Be sure to check all your text, your descriptions and icons to make sure they are correct.

确保检查所有文本，描述和图标，以确保它们正确无误。

时间支出编码与时间支出编辑PNG (Time Spend Coding vs. Time Spend Editing PNGs)

Goodness, I swear I have spent more time messing with screenshots and PNGs than coding.

天哪，我发誓我花了更多的时间在屏幕截图和PNG上，而不是编码。

Here's the thing: Mobile app development is all about the Screenshots and Icons.

事情是这样的：移动应用程序开发完全是关于屏幕截图和图标的。

There's so many resolutions and assets and different scenarios where your application can be showcased that it's worth spending some time getting really good at PhotoShop or Paint.NET. I'm doing all my work in Paint.NET, in fact.

可以展示您的应用程序的分辨率和资产种类繁多，并且场景各异，因此值得花一些时间在PhotoShop或Paint.NET上变得非常出色。 实际上，我正在用Paint.NET进行所有工作。

Because there's three resolutions you'll want to make note that you need three sets of screenshots! Fortunately there's a screenshot cool built into the Emulator and Windows Phone also supports in-device screenshots (finally) by pressing Power+Windows Key.

由于存在三种分辨率，因此您需要记录三组屏幕截图！ 幸运的是，模拟器中内置了一个很酷的屏幕截图，Windows Phone也可以通过按Power + Windows键来支持设备内屏幕截图(最终)。

It may not be obvious from this picture of the marketplace submission but you need to click WXGA and 720p and upload separate screenshots for each one! Otherwise your potential users won't see your app looking exactly as it will on their device. Tedious, but crucial.

从这张提交的市场图片中可能看不出来，但是您需要单击WXGA和720p并分别为每个屏幕截图上传！ 否则，您的潜在用户将看不到您的应用在设备上的外观。 乏味，但至关重要。

Truly, this became an asset management chore. I ended up with a folder fill of JPGs and PNGs and only kept my sanity with some reasonable file name conventions.

确实，这成为了资产管理的琐事。 我最终得到了一个包含JPG和PNG的文件夹，并且只保留了一些合理的文件名约定来保持理智。

You will end up with at least 24 screenshots (3x8) plus three splash screens, several icon sizes and you'll also want to test on both the Dark and Light themes.

您最终将获得至少24个屏幕截图(3x8)，外加三个启动屏幕，几个图标大小，并且还需要在“黑暗”和“明亮”主题上进行测试。

结论 (Conclusion)

In the end, it will be seamless for your end users. Folks who have Windows Phone 8 will get their updates from your WP8-XAP and Windows Phone 7.x folks will get theirs from your WP7-built XAP. This whole thing took about 3 hours and most of that time was spent doing screenshots.

最后，它将对您的最终用户而言是无缝的。 拥有Windows Phone 8的人们将从您的WP8-XAP获得更新，而Windows Phone 7.x居民将从您的WP7内置的XAP获得更新。 整个过程大约花费了3个小时，其中大部分时间都花在了截图上。

翻译自: https://www.hanselman.com/blog/updating-my-windows-phone-app-to-windows-phone-8