Edit the app's package metadata to ensure the app is ready for publishing.
- [Voiceover] At this point, we've built our app. The next logical step is to publish it. Before we do that, however, there are several steps we should take first. The first thing we should do is to make sure that our package metadata is specified properly. After that, we should ensure that our app is performant, and will not cause any issues on our users' devices. Finally, we should test it to make sure our application is accessible. In this video, I will show you some of the tools in visual studio, that make it easy to get your application ready to publish.
First, let's start with the package metadata. Open the package.appxmanifest file, and you should see this screen. There are several tabs that specify different information about your package. The first one is the application tab. Change the display name, to the name that you want your application to be displayed as. I'll set mine to To do Together. Change the description if you'd like, as well. I'll say, a collaborative project management application. I'll spell it right.
This will also pick your default language, which in our case will be English with the United States locale. The next tab we're going to change is the visual assets tab. This will be all of the different icons for your application including the task bar, the start menu, and the splash screen, for example. Before we update this, let's delete out existing assets that come with the project template. Next, add an asset that you would like to be your package logo. You can use the asset provided in the exercise files, or create your own.
I recommend using a 400 by 400 pixel. First I'm going to add it to my assets folder in the solution explorer. Then I'll reference the source in my application directly. Source is under the assets folder, and it's my new image. The assets I will create will be all of the defaults including the package logo, so I will add the package logo at the bottom of the assets dropdown. I'll do all scales and I will apply the recommended padding. When I click generate, I should see all of these new assets created for my application.
Great, we're not going to do anything with the capabilities or declarations tab. These are used to specify additional functionality that your application may need. You'll generally run into these when using more advanced APIs in your app. The API documentation should say what you need to add to your package metadata. The content URIs is also not going to be used, because none of our content is hosted on the web. All of our views are specifically in zammo. We'll look at the packaging tab, but we're not actually going to update anything here, either.
This automatically gets updated by Visual Studio when you associate your application with a product to your store account. The information here is just an artifact of downloading this template from the azure portal. Our publisher name is not anwigley. The package display name won't be TryMobileApp. It will all work out when we package for the store. Next, let's take a look at the performance and reliability of our application. I'm going to save the package, that appxmanifest file first, and then I'm going to launch my application locally.
You may have noticed it before, but when your application is running, there is a diagnostics tools window available to you. I'm going to pin this and hide the live property explorer. I'm also going to hide the windows at the bottom, so that I can see the full thing. This shows me the application memory that's being used, the CPU that's being used, and any events that occur. If I wanted to go deeper into the details of the diagnostics tools, I could go to debug, performance profiler, and see more information.
For now, I'm going to stop the app and try out some of those advanced performance profilers. I'll select application timeline and CPU usage. When my project starts, I can immediately see the CPU usage of my application, which is very low, that's good. I'm not too worried about performance. I'll do some navigation in my application, I'll add a task, check a task, and see those little spikes where the app is processing, but they are very little, I'll then stop collection, and take a look at the report that's generated.
There you have it, I can see my UI thread utilization, the overall CPU usage, which is very low, as well as my visual throughput. In the application timeline, I can see what type of application functionality is taking each amount of time, and I can even scope to specific times. If I wanted to see exactly what's happening during the UI thread utilization at the startup, I can see what's happening, windows resized, pages loading, which is my login view, takes about half a second to load. I can load my nav view as well, and my project view.
So what's happening is it's loading login view, skipping immediately to nav view, which loads my project view, and that whole thing takes about half a second, and uses very little CPU. I'm okay with that. I can also see the UI thread summary, in this case, page loading, it is taking most of the UI thread, which is expected. The other tool that you can use to help you determine accessibility issues in your application, is called UI analysis. I'm going to close this diagnostic sessions, and start my application again. I'm not too worried about performance for now. In the diagnostics tools window, in this little gear box, there's an option to select UI analysis.
This is only available in Visual Studio 2017. When you select it on, you get a dialogue saying that the changes will be applied in the next debugging session. Go ahead and restart the application so that you can see the changes. UI analysis is a really powerful tool to help you find performance and accessibility issues in your UI code, and your zammo code. If I want, I can go to the diagnostics tools window and I see that there's nine out of nine UI analysis events. I can click on the events tab to take a look at these.
Let me expand the diagnostics tools window pretty significantly so I can read them. Each of these has more information on the web, if you want to learn more about it. Let's just take a look at one example. List view, options, list view is not being virtualized, due to being placed inside a grid. What that means, I can click on the more information link to learn more about this issue. The impact is that if a user reaches an element with no name, they often will have no way of knowing what the element relates to. This is especially impactful to users that may be using accessibility tools, such as the narrator, to read information about the application.
The solution is to set the automation properties dot name property, in the control zammo, to an appropriate, localized string. If I double click on this event, I can navigate directly to the control that it impacts. Let me make the diagnostic tools window a little bit shorter. If I refer to the solution in the web, I can go ahead and set automation properties dot name equal to add project. Now, when a user navigates to this button, the screen reader should say add project, and they know exactly what to do.
We're not going to fix all of the UI analysis issues now, but I just want to show you that that one is indeed resolved. One piece of advice I have is to enable UI analysis as soon as you start building your application and fix them as they come. If I return to the diagnostics tools window, I should only see eight events now. So if I go to summary, I see eight events. One of them has been fixed. These tools in Visual Studio make it easy to determine whether or not your app is ready to publish. If you're building an app that you want to publish to the store and be a success, I encourage you to use these tools to make your app performant and accessible.
These will help you find the bugs before your customers find them, so that your app has a better chance of success. Now that we know the tools to make our app ready to submit to the store, let's go ahead and learn how to create a package to submit to the store.
- Working with .NET for UWP app development
- Establishing application architecture
- Configuring Azure services
- Configuring the mobile app service backend
- Testing and publishing the service backend
- Using Facebook authentication
- Using XAML
- Client server abstraction API
- Using the UWP community toolkit
- Styling app views
- Creating adaptive views
- Testing an app for multiple user accounts
- Publishing to the Windows Store
- Sideloading app packages