Update my Windows Phone application to Windows Phone 8

[Original article address]Updating my Windows Phone app to Windows Phone 8

[Chinese original address] update my Windows Phone application to Windows Phone 8

[Original article posting time]

Earlier this year, I spent a day writing a small Windows Phone 7 Application called lost phone screen. It can create a screen lock for you and display your name and contact number on it, so that you can use the old method to find your mobile phone when you lose it. You don't need GPS. You just have to tell your companions a small reward and ask them to call. Now you can download it for free. You don't have to pay for any software, except for 99 cents for angry birds. But I am not suffering .;) In any case, it is ideal for Windows Phone 7 and Windows Phone 7.5 (mango ).

Recently I got a Windows Phone 8 Nokia Lumia 920, because there are a lot of new APIs and functions available for me to use-one of the most important is that we can also set the screen lock of the mobile phone in programming mode, the user will not need to do anything-I think it is time to update it.

I encourage you to view the concept and code within six hours: launch my first Windows Phone application blog as a reminder, what can an application do and what problems I encountered when writing Windows Phone 7.x.

Here is why I have to consider updating the application to Windows Phone 8. I am very grateful to our Nokia friend Justin angel for brainstorming with me on Skype and helping write asynchronous code and solve problems. His blog post on the latest features of Windows Phone 8 is very useful, especially his small multires helper class.

Update an application

First, it is obvious that the existing Windows Phone 7 application can run normally on Windows Phone 8 without any changes. It runs on Windows Phone 8 just like on Windows Phone 7. I want to update it to use new features on the new operating system.

Upgrade the project to Windows Phone 8

Upgrading is simple. I open the old project and then it prompts me to upgrade. I double-click wmappmanifest. xml and make sure to reiterate some basic settings, such as the icon size and tile of my application, and confirm that my application will need features like photo access.

Make sure that supported resolutions is selected, because I know that I will use it later.

Save two branchesA super project

I did this repeatedly. This is an upgraded operating system, but 99% of the code will be shared. However, a lot of things have changed, so I decided to create a branch in source code management, instead of making a single build. To be honest, there may be no wrong answer here. You can use anything you are used. If I like it, I can use the csproj file, or just make a different build configuration (for example, debug8 and debug7 ), but I understand that my source code management runs very well, so I have a phone70 and phone80 branches each, and I switch between them. It is more likely that I will update the phone80 branch and "port later" the new function. Now it works normally, but I know that if I want to, I can always make a single build.

However, I knew that I needed a Windows Phone 7.x and Windows Phone 8,I can submit them to the store with the same name, and the store will handle it. If your Windows Phone 8 uses a new screen resolution, you will get the correct version, as you can see in the screen snapshots below. I have submitted two xap files.

New Screen Resolution

I updated my application a few weeks ago, but my first good bug occurred when the HTC Windows Phone device was running at a resolution of 1280x720, instead of 1280x768. It says: My lockscreens has been cropped! Windows Phone 8 actually has three screen resolutions, as Justin points out:

TheseScreen Resolution: WVGA (480x800Pixels), Also used in Windows Phone 7Medium; wxga (768x1280Pixels), basically WVGAAnd 720 p(720x1280Pixels), it is used with WVGAAnd wxgaDifferent Aspect Ratio. Pay attention to these different resolutions. Ensure that the relative <GRID/>Locate and use different media assets for different resolutions.

The three screen resolutions are the second, and what's more interesting is that 720 p isDifferent Aspect Ratio!I made many assumptions in my code, not the screen resolution. I will assume as the aspect ratio of 800x480 and 1280x768, but is 1280x720!

My initial response was, bad, and now I have to really think about it.

It turns out to be simpler. On the pages of all my applications, there is a page that I canDeleteXAML code, as well as hardcoded margins and row definitions. In fact, I am working on concrete implementation to prevent the system from being laid out in the best way.

I deleted all my hardcoded margins and used "*" rowdefinition to change my mesh. "This means that" other spaces "are like this:

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

The first rowdefinition fills in the content size, and the second occupies the rest. This makes my page look good on every resolution screen and is easy to test, because I can just change the simulator drop-down list to select different resolutions:

However, in these new resolutions, I changed my original single splashscreenimage.jpg to include each of the three resolutions used to name the SplashScreenImage.Screen-720p.jpg splashscreenimage. Screen wvga.jpg and SplashScreenImage.Screen-WXGA.jpg. You will find that at least half of your time is being done (whether it's apple, windows or Android). The mobile app gets PNG and the image file to correct it ).

I have to (select) Hard code a place on the app (I can question the application. current. host. content. scalefactor. application. current. host. content. actualheight and application. current. host. content. actualwidth is correct ). I have a very special custom cropping image control that requires special processing of the 720 p case, probably due to my lack of skills on XAML. It tells me that only the most avant-garde edge conditions need to be done like this. Usually this is the creation of a pixel perfectly locked screen, so your sweat may not flow at all.

New lock screen API

Finally, my application can update the screen lock without manual intervention. This is my first requirement. Everyone thinks it is my fault and this function does not exist. In fact, it has been added to Windows Phone 8.

If your application wants to change the lock screen, it must ask once and get the permission. It must provide "Current lock screen supplier ". If the above conditions are met, it will request the access permission and then set 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 about 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));
}

This is it. Cute and simple. However.

Use asynchronous APIA very important reminder

In Windows 8 and Windows Phone 8 (since Windows 8 magic dust isLocated inWindows Phone 8), everything is about asynchronous and non-blocking APIs. Previously, I only saved the wallpaper and had no choice but to wait for you. Now all the underlying APIs are asynchronous (non-blocking). As developers, we have the await/async keyword to make things simple, right?

Of course, my second cute bug appeared when you clicked the Save button multiple times. Because everything is non-blocking, it will close many save requests, and eventually they will collide with the file system, and then "access is denied ".

I want to protect access to such shared resources, but I don't want to lock the UI. Michael L Perry has a good solution for this, which may be built into the Windows Phone SDK of his awaitable critical section helper (at least it exists, unless we miss it ?). This helper allows us to use Asynchronous and wait, and lock () {} block when using the familiar using {} block.

As Michael pointed out, you cannot do this because you cannot wait in a lock.

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

But with this helper, you can perform this operation:

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

That's what I do.

Analysis

When you finish, make sure that you run the Windows Phone application analysis tool to view your application. Does it use too much memory? Have you used the battery? Does it start in one second?

This is amazing. So that you do not have to work hard for your app, or even do not need to configure your appWhat you need to remember when submitting your application and two versions

I fixed some bugs in Windows Phone 7, changed the xap version, and submitted it as a small upgrade. People with Windows Phone 7.x will be prompted to update their applications. In this version, as you remember, the screen lock will not be automatically updated because it cannot.

Go to phone marketplace and clickUpdate app. Before my updates, marketplace displays the 7.1 application:

Click Update selected to upload the newly created Windows Phone 7.1 for xap. After uploading, change the drop-down list and upload Windows Phone 8 xap. I am sure you want to upload and release a release xap or "anycpu" version.

I have been saving several versions of Windows Phone 8 for my own sake. This makes sense to me. It helps me remember what is "latest", even if it only cares that the new version is higher than the previous version.

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

Spend time codingSpend time editing PNG

I swear I spent more time playing with PNG than coding.

The problem is as follows:Mobile app development is completely related to screens and icons.

There are so many resolutions, assets, and different solutions for your application to display, so it is worth spending some time on Photoshop or painting. net. In fact, all my work is done in paint. net.

Because there are three resolutions, you needNote that you need three screens.! Fortunately, there are tools built into emulator, and Windows Phone also supports (eventually) screenshots on the device by pressing the power + Windows key.

Submitting from marketplace may be less obvious, but youYou need to clickWxgaAnd 720 pAnd then separate each upload! Otherwise, your potential users will not see your applications on their devices. It's boring, but it's important.

To be honest, this has become an asset management activity. It ended up filling in JPG and PNG folders and only kept some reasonable File naming conventions.

You will eventually have at least 24 (3x8) plus three initial screens, several icon sizes, and you will want to test on dark and bright theme.

Conclusion

Finally, it will seamlessly connect your users. People with Windows Phone 8 will get updates from WP8 xap, while those with Windows Phone 7. X will get updates from the WP7-built's xap. It took about three hours to process the screen most of the time.