1. Classification of the document

1.1 Purpose

By making this document, the developer community who wanted to get started in

Windows Phone App Development, can easily understand few important aspects of

Windows Phone Mobile Platform like UI/UX, Design Guidelines, Naming Conventions,

Architecture, so on and so forth.

1.2 Target Audiences

This document is targeted to:

Those developers who know basics of Application development, especially

Mobile App Development and want to get started with Windows Phone App

Development.

Those developers who want to know more about Architecture, Design and

Flow of Windows Phone App

2. General

Framework

Windows Phone Application can be developed on the base of total 2

Framework for two different Operating Systems, Windows Phone OS 8.0 & OS

8.1

App Development for Windows Phone 8.0 can be done only on “Silverlight

Framework” Platform, whereas if we develop App for Windows Phone 8.1,

then there are 2 choices. Windows Phone OS 8.1 made on the base of two

different Frameworks, one of them is “Silverlight Framework” and the other

one is “Windows Runtime” framework (WinRT framework).

2.1 Deliverables for a project

In Windows Phone Application project the main deliverable is the Application

Installation Package wrapped in the file format and encryption of “.xap” or

else “.appx”

(Here XAP is the application package of Silverlight based App, and APPX is the

application package of Windows Runtime (WinRT) based App.)

2.1.1 One Pager

Windows Phone Application development made easy with the help of

Interactive Development Environment (IDE) Visual Studio.

While Application development, debugging of the app can be done in a

developer unlocked Windows Phone device as well as “Windows Phone

Emulator”.

One Application of Windows Phone can contain multiple projects developed

in same framework.

While Developing Windows Phone OS 8.1 Application based on “Windows

Runtime” platform, developer needs to have “Windows 8.1 Developer

License” installed with the visual studio IDE. To gain the Developer License,

one needs to just sign in with respective Microsoft account.

Key Features of Windows Phone Application which makes the app different

from other platforms are:

- Pin to Start functionality:- Pin specific application page on start screen as a

Tile

- Tile Notification:- developer can set notification on Tile pinned to start

screen

- Live Tile:- developer can update the Tile pinned to start screen periodically

- Setting Lock Screen Notification & Background

- Fast App Switching functionality

After developing application, developer needs to select a unique “App Name”

from the Windows phone store Developer portal and upload the released

version of Windows Phone Installation package in form of XAP. With that

developer also needs to provide Application specific information in order to

certify the app on store.

The duration of Application certification on Windows Phone Store Developer

Portal, varies with the scenarios and circumstances in which App submitted to

verify. After successful verification of Application, the application can be

published on the store manually as well as automatically.

2.1.2 Release Candidate

After developing the basic application, developer can submit the app to the

Beta store for testers to test the application flow and for Quality Assurance.

After completion of Beta app testing, developer can submit the application on

store as Release Candidate with integration of App Track functionality.

Developer can check the Error & Exception logs of the Application published

on the store from the Developer portal of Windows Phone Store.

2.1.3 Technical Aspects

After completing Development of Windows Phone Application, We need to

Build the Solution in terms of getting Output XAP package file.

While Building the Solution, the IDE Visual Studio will make a root Folder with

the name of Application Project. And in that root folder, Source Code of whole

Application goes.

As the Structure of Windows Phone Application Project, the Opening file will

be with the “.SLN” extension which stands for “Solution”.

So, Technically the deliverable of Windows Phone App Project, we’ll get a fully

working copy of Source code in form of Code files as “.cs”, “.xaml”, “.sln”,

“.csproject” etc.

2.1.4 Security Aspects

The Application package that a developer will get after successfully building a

Windows Phone application, will be kind of a compressed form of the code

files. Anyone with File extraction technology can open that application

installation package and extract the code files resides in the package.

But, once if developer will host that XAP package onto the store and if that

package published after successfully verified and certified by Windows Phone

Store, then the application package downloaded from the store, is a non

extractable file in the same form of XAP package.

Once publishing the application, Windows Phone Store Encrypt the whole XAP

package and the code files in the package with some unique technology and

key. So, the XAP files downloaded from the Store cannot be extracted by

anyone except “Windows Phone” at the time of installation.

3. Development

Overview – Windows Phone Development

Windows Phone 8.1 Application Development can be done with the help of

two different frameworks as “Silverlight Framework” and “Windows Runtime

framework”. Whereas Windows Phone 8.0 applications development can be

done with only “Silverlight Framework”.

Here, while developing Windows Phone 8.1 application developer can choose

from two different development environments to develop application with.

- XAML + C# (XAML as Frontend + C# as Backend)

- HTML5 + CSS3 + JavaScript (HTML5 & CSS3 as Frontend + JavaScript as

backend)

Provision of Windows Phone Application Development with HTML5 + CSS3 +

JavaScript is especially for Web Developers, who wanted to develop windows

phone applications as well.

Web Developers can directly migrate their Mobile Website code to Windows

Phone application with small amount of changes and few changes in including

libraries specific for windows phone application.

There is one more option available for .NET developers to develop windows

Phone 8.0 as well as Windows Phone 8.1 application with the help of XAML +

VB.net. Here XAML used as Frontend and VB.net is for Backend.

Universal Application:

- Developers can also build Windows Phone Application by creating

Universal Application in Visual Studio.

- Universal Application based on the concept of “Write Once, Run

Everywhere” concept. Here Universal App contains two kind of application

from which one is Windows Phone Application (targeted to Windows

Phone OS 8.1) and the second one is Windows Store (Metro App)

application targeted to (Windows 8.1 & higher).

- Universal Application is based on “Windows Runtime” framework.

Application developed for Windows Phone OS 8.0 can run on Windows phone

OS 8.1 or greater, but app developed in WinRT framework and for OS 8.1

cannot be migrated to Windows Phone OS 8.0

Windows Phone Application is following Forward Migration but not reverse

with respect to Windows Phone OS versioning system.

3.1 Solution Structure

Windows Phone Application is made easy with the help of Visual Studio (VS)

Interactive Development Environment (IDE).

Visual Studio has several versions from which VS 2012 or greater is required in

order to develop Windows Phone OS 8.0 or higher application. Although to

develop windows phone 7.5/7.8 application, visual studio 2010 or greater

versions required.

3.1.1 Visual Studio

Visual Studio provides an integrated environment and full solution to develop

windows phone application.

Solution Explorer in visual studio is the tool which manages all the code

portions. In Solution explorer, the root directory is the Solution which

contains more than one project (if any) and those projects are placed

hierarchically in the Folders created by Visual Studio.

Solution Explorer reflects the Copy of files and folders created by visual studio

and those required to build the project.

In the Project root folder there are couples of folders and files which contain

the resources that application is using and the code that executes the

application.

Project root folder is mainly divided into 5 portions as mentioned below:

- Properties

- References

- Assets

- Resources

- Other manually added code files

Properties:

- This section contains 3 files by default when creating project.

“AssemblyInfo.cs”, “AppManifest.xml” and “WMAppManifest.xml”

- Here WMAppManifest.xml file is the file which contains the code of

Application properties and the configuration of the Windows Phone

App.

- From this WMAppManifest.xml file, developer can change the App

configuration of Application UI, Capabilities that application holds from

the device it installs in, Requirements of device in order to install the

app and the packaging information of the application installation

package which generates at the time of building the project.

References:

- This section holds the references to the Libraries used in the

application whether the library is a third party external or internal

project Code.

- Reference section is the one in which Visual Studio installs the NuGet

Packages in the project solution.

- Moreover The Reference section also holds the reference to the core

libraries that used in the application in order to execute the basic

project.

Assets:

- In most of the case this folder used to hold all of the images that used

in the application anywhere, including the tile images and Logos with

different resolutions of the application.

- There can be nested folders in the assets root folder to maintain the

modularity.

Resources:

- This section contains all those code files which define the styles and

Templates of specific controls used in the whole application project.

- By default there will be a resource file named “AppResources.resx”.

Other than these four Sections, the Developer can add custom folders and

files as requirement and as appropriate.

3.2 Naming in Windows Phone & C#

3.2.1 Naming Convention in C#

In fact there isn’t any strict rule to follow the Naming convention in C#

language but it’s always a good practice to follow a specific form of

Naming Convention to make it easier to maintain future conflictions in

Applications Variable declarations.

Here are few important Guidelines which is used by Microsoft, to

develop Samples and Documents in order to maintain the common

understanding of coding standards in C#.

This Portion of the Document is taken from “Microsoft Developer

Network” Community Library, to make sure the preciseness of

Content.

Selecting Variable Names

- Choose the names of variable those can be easily readable.

i.e. a variable should named “SelectedObject” instead “SeleObj”.

- Try to avoid using Underscores, Hyphens &nonalphanumeric

keyword.

i.e. a variable should named “TextboxName” instead “textbox_name”.

- Try to avoid use of wildly used keywords or matching the keywords.

- Avoid using Hungarian Notation.

Proper Abbreviations and Acronyms

While choosing identifier names, do not use abbreviation or

contractions as part of it. Try to avoid use of acronyms those are not

wildly accepted.

Letter Capitalization

In capitalization style, there are 3 cases.

- Pascal Case

The first letter in the identifier and the first letter of each subsequent

concatenated word are capitalized. You can use Pascal case for

identifiers of three or more characters. For example:

i.e. TextBox

- Camel Case

The first letter of an identifier is lowercase and the first letter of each

subsequent concatenated word is capitalized. For example:

i.e. textBox

- Upper Case

All letters in the identifier are capitalized. Use this convention only

for identifiers that consist of two or fewer letters. For example:

i.e. System.IO

i.e. System.Web.UI

Case Sensitivity

Do not use names that require case sensitivity. Components

must be fully usable from both case-sensitive and case-

insensitive languages. Case-insensitive languages cannot

distinguish between two names within the same context that

differ only by case. Therefore, you must avoid this situation in

the components or classes that you create.

Do not create two namespaces with names that differ only by

case. For example, a case insensitive language cannot

distinguish between the following two namespace declarations.

i.e. namespaceee.cummings;

namespaceEe.Cummings;

Do not create a function with parameter names that differ only

by case. The following example is incorrect.

i.e. void MyFunction(string a, string A)

Do not create a namespace with type names that differ only by

case. In the following example, Point p and POINT p are

inappropriate type names because they differ only by case.

i.e. System.Windows.Forms.Point p

System.Windows.Forms.POINT p

Do not create a type with property names that differ only by

case. In the following example, int Color and int COLOR are

inappropriate property names because they differ only by case.

i.e. int Color {get, set}

int COLOR {get, set}

Do not create a type with method names that differ only by

case. In the following example, calculate and Calculate are

inappropriate method names because they differ only by case.

i.e. void calculate()

void Calculate()

Type Name Confusion

Use names that describe a type's meaning rather than names

that describe the type. In the rare case that a parameter has no

semantic meaning beyond its type, use a generic name. For

example, a class that supports writing a variety of data types

into a stream might have the following methods.

i.e.

void Write(double value); void Write(float value);

void Write(long value); void Write(int value); void Write(short value);

Do not create language-specific method names, as in the

following example.

i.e.

void Write(double doubleValue);

void Write(float floatValue);

void Write(long longValue);

void Write(intintValue);

void Write(short shortValue);

Namespace Naming Guidelines

The general rule for naming namespaces is to use the company

name followed by the technology name and optionally the

feature and design as follows.

Format:

CompanyName.TechnologyName[.Feature][.Design]

i.e.

Microsoft.Media

icrosoft.Media.Design

Prefixing namespace names with a company name or other

well-established brand avoids the possibility of two published

namespaces having the same name. For example,

Microsoft.Office is an appropriate prefix for the Office

Automation Classes provided by Microsoft.

Use Pascal case for namespaces, and separate logical

components with periods, as in Microsoft.Office.PowerPoint. If

your brand employs nontraditional casing, follow the casing

defined by your brand, even if it deviates from the prescribed

Pascal case. For example, the namespaces NeXT.WebObjects

and ee.cummings illustrate appropriate deviations from the

Pascal case rule.

Class Naming Guidelines

Use a noun or noun phrase to name a class.

Use Pascal case.

Use abbreviations sparingly.

Do not use a type prefix, such as C for class, on a class name.

For example, use the class name FileStream rather than

CFileStream.

Do not use the underscore character (_).

Occasionally, it is necessary to provide a class name that begins

with the letter I, even though the class is not an interface. This

is appropriate as long as I is the first letter of an entire word

that is a part of the class name. For example, the class name

IdentityStore is appropriate.

i.e.

public class FileStream

public class Button

public class String

Interface Naming Guidelines

Name interfaces with nouns or noun phrases, or adjectives that

describe behavior. For example, the interface name

IComponent uses a descriptive noun. The interface name

ICustomAttributeProvider uses a noun phrase. The name

IPersistable uses an adjective.

Use Pascal case.

Use abbreviations sparingly.

Prefix interface names with the letter I, to indicate that the type

is an interface.

Use similar names when you define a class/interface pair where

the class is a standard implementation of the interface. The

names should differ only by the letter I prefix on the interface

name.

Do not use the underscore character (_).

i.e.

public interface IServiceProvider

public interface IFormatable

Attribute Naming Guidelines

always add the suffix Attribute to custom attribute classes. The

following is an example of a correctly named attribute class.

i.e.

public class ObsoleteAttribute{}

Enumeration Type Naming Guidelines

Use Pascal case for Enum types and value names.

Use abbreviations sparingly.

Do not use an Enum suffix on Enum type names.

Use a singular name for most Enum types, but use a plural name

for Enum types that are bit fields.

Always add the FlagsAttribute to a bit field Enum type.

Static Field Naming Guidelines

Use nouns, noun phrases, or abbreviations of nouns to name

static fields.

Use Pascal case.

Do not use a Hungarian notation prefix on static field names.

It is recommended that you use static properties instead of

public static fields whenever possible.

Parameter Naming Guidelines

It is important to carefully follow these parameter naming

guidelines because visual design tools that provide context

sensitive help and class browsing functionality display method

parameter names to users in the designer.

Use camel case for parameter names.

Use names that describe a parameter's meaning rather than

names that describe a parameter's type. Development tools

should provide meaningful information about a parameter's

type. Therefore, a parameter's name can be put to better use

by describing meaning. Use type-based parameter names

sparingly and only where it is appropriate.

Do not use reserved parameters. Reserved parameters are

private parameters that might be exposed in a future version if

they are needed. Instead, if more data is needed in a future

version of your class library, add a new overload for a method.

Do not prefix parameter names with Hungarian type notation.

i.e.

Type GetType(string typeName)

string Format(string format, object[] args)

Method Naming Guidelines

Use verbs or verb phrases to name methods.

Use Pascal case.

i.e.

RemoveAll()

GetCharArray()

Invoke()

Property Naming Guidelines

Use a noun or noun phrase to name properties.

Use Pascal case.

Do not use Hungarian notation.

Consider creating a property with the same name as its

underlying type. For example, if you declare a property named

Color, the type of the property should likewise be Color. See the

example later in this topic.

Below are the examples:

public enum Color

{ // Insert code for Enum here.

} public class Control

{ public Color Color

{ get {// Insert code here.} set {// Insert code here.} } }

publicenum Color {// Insert code for Enum here.} public class Control

{

publicint Color { get {// Insert code here.} set {// Insert code here.} } }

Event Naming Guidelines

Use Pascal case. Do not use Hungarian notation. Use an EventHandler suffix on event handler names.

Specify two parameters named sender and e. The sender parameter represents the object that raised the event. The

sender parameter is always of type object, even if it is possible to use a more specific type. The state associated with the event

is encapsulated in an instance of an event class named e. Use an appropriate and specific event class for the e parameter type.

Name an event argument class with the EventArgs suffix. Consider naming events with a verb. For example, correctly

named event names include Clicked, Painting, and

DroppedDown. Use a gerund (the "ing" form of a verb) to create an event name

that expresses the concept of pre-event, and a past-tense verb to represent post-event. For example, a Close event that can be

canceled should have a Closing event and a Closed event. Do not use the BeforeXxx/AfterXxx naming pattern.

Do not use a prefix or suffix on the event declaration on the type.

For example, use Close instead of OnClose. In general, you should provide a protected method called OnXxx

on types with events that can be overridden in a derived class. This method should only have the event parameter e, because

the sender is always the instance of the type. i.e.

public delegate void MouseEventHandler(object sender,

MouseEventArgse); public class MouseEventArgs : EventArgs

{ int x; int y;

publicMouseEventArgs(int x, int y)

{ this.x = x; this.y = y; } publicint X { get { return x; } } publicint Y { get { return y; } } }

Layout Conventions

Write only one statement per line. Write only one declaration per line. If continuation lines are not indented automatically, indent

them one tab stop (four spaces). Add at least one blank line between method definitions and

property definitions. Use parentheses to make clauses in an expression apparent,

as shown in the following code.

Commenting Convention

Place the comment on a separate line, not at the end of a line of code.

Begin comment text with an uppercase letter.

End comment text with a period. Insert one space between the comment delimiter (//) and the

comment text, as shown in the following example.

Implicitly Typed Local Variable

Use implicit typing for local variables when the type of the variable is obvious from the right side of the assignment, or when the precise type is not important.

Do not use var when the type is not apparent from the right side of the assignment.

Do not rely on the variable name to specify the type of the variable. It might not be correct.

Avoid the use of var in place of dynamic. Use implicit typing to determine the type of the loop variable in

for and foreach loops.

3.2.2 Naming Convention in Windows Phone

If the developer uses C# as a backend in Windows Phone Application

Development, then in most of the cases Naming convention is same as Naming convention used in C#.

UIElement Naming

Naming of UIElement generally goes in below manner: ElementName_UniqueKeyword

Source Folder Naming

Folders contain the source code of specific modules of the application generally named by the purpose or functionality of

that specific module.

Naming of Application Page

As the naming of source code folders, Application pages should also name after the functionality or the portion of the

application functionality that it holds.

Every Application Page must be named with prefix of “Page” which can overcome the confliction with the classes’ names

those named after the same functionality or same Modules in the Application.

3.3 Checking the Code

Checking the Code for quality is very important aspect for Major projects and those projects which are future planned.

Here is several guidelines for checking the Quality Code.

Use of Checklist:

Track the kinds of mistakes that you typically make and use them as a checklist for future code. You can start your checklist with common errors that your group or division made, and then personalize that list for your use.

Conduct code reviews: Code reviews give you an opportunity to explain and better

understand your own code, and give others an opportunity to view your code anew.

Unit Tests:

The best way to ensure quality is to write tests that validate data and algorithms and verify that prior mistakes do not recur.

Code Analysis Tool:

The simplest way to catch bugs early is by increasing the warning level in your compiler and using code analysis tools. The critical points are to never ignore a warning and fix the code.

User friendly names of Variables:

Consist coding style: To maintain good quality for the code written by several team members in the same team for different modules, whole team must follow the same and consistent coding style.

Code reusability:

Code reusability is also one of the most important aspect of Major projects. Code reusability will decrease the complexity

and Lines of Code for any specific project.

3.3.1 Dispose Check

Dispose checking is as important as the importance of Quality of code. There are few tools available in the market for Checking the memory leaks and the Object disposal.

Specifically for silverlight framework based windows phone application project, the dispose checker tool will integrate with the application through visual studio and it will check whether there are any memory leaks or any object that should not further in scope or not.

3.3.2 Code Analysis using Visual Studio

There is a functionality in visual studio itself is for analyzing the code for Errors, Quality and general Exceptions.

There is one limitation, Code Analysis tool will be activated and integrated by default with two high level versions of visual studios which are, Visual Studio Premium and Visual Studio Ultimate. In other two versions Visual Studio Professional and Visual Studio Express do not contain the Code Analysis tool integrated by default with the Installation of Visual Studio.

Configure Code Analysis for a Project:

Rules for managed code are organized into rule sets that target specific areas, such as security and design. You can use one of

the Microsoft standard rule sets or create your own.

Run Code Analysis: You can specify code analysis to be run automatically every time

that a project configuration is built, and you can run code analysis manually on a project.

Analyze code analysis results:

Code analysis warnings and errors are listed in the Visual Studio Error List window. You can click a warning or an error to display the source code that contains the issue, and the warnings are linked to detailed information and possible corrections.

Integrate code analysis with your development life-cycle: Check-in policies in Team Foundation version control enable development teams to make sure that all code check-ins meet a common set of code analysis standards.

3.3.3 Clean Code

There are few major guidelines which makes the code cleaner and more readable for developers who will refer that code in future.

Write short methods

Enable reusability of code in multiple classes and even projects if required.

More Classes are better than big classes. Simply write small classes.

Avoid mixing abstraction layers. Write Comments wherever needed to understand any portion of

the code.

Give appropriate code titles before writing the code to make

understand other developer who reads it. Code regions are also one of the important aspects of Code

Structure which helps developer understand the purpose of the code and it also helps developer distinguish specific code regions

from other.

3.3.4 Commented Code

Generally comments should only be used wherever developer needs to make it clear what the code is written for in the future.

Instead of using comments for making better understanding, sometimes the versioning of application leads to change the code, and at that time, developer will comment the old code and rewrite it from the scratch.

Here Commented old code is like a dead giveaway for those who

will read and try to understand the code in future. Instead of making old code commented, it’s a good practice to

maintain the versioning by any kind of Source control system. This will help reduce unnecessary commented old code.

3.3.5 Exception Handling and Logging

Exceptions are the key full-stopper in the whole application project. Every developer must handle all kind of exceptions as well as consider every situation where exception can be generated.

In Windows Phone application, exceptions can be handled by using Try and Catch block in the code.

If there is any possibility of exception generation, then write that code in try block. So here if the code generates any kind of exception, then compiler will directly go into the Catch block written exactly after the try block.

Windows Phone Application used with C# as backend, also provides nested Try Catch functionality to handle multiple exceptions at same time if there is any requirement.

For major projects it’s always better to use Logger as the exception

provider. Exceptions can be logged any time during processing; they do not

have to be logged at the beginning of the event handling sequence. For example, you can log an exception after it is

wrapped or replaced. The Exception Handling Application Block provides a logging

exception handler that depends on the Logging Application Block. You can also incorporate custom logging functionality into your

own exception handler to use instead of the Logging Application Block.

3.4 Programming Consideration for Windows Phone App Development

3.4.1 Multi Language Support

Developer can add Multi-Language support in Windows Phone Application by adding Multilingual App Toolkit in the application.

Windows Phone App Store is currently available in 191 countries with several different languages. This requires an App to be localized in many of other

languages then English. The Multilingual App Toolkit helps developer localize specific application in

more than one language. This Multilingual app toolkit also helps localize your app either by Microsoft Translator or also by the developer itself manually.

You can also import the translation file made by some expert into your project and integrate it to localize your own app.

Important note here is, Windows Phone 8 is well integrated with the Multilingual App Toolkit and when you create a Windows Phone 8 project most of the work to enable localization is done for you.

The tools also work on Windows Phone 7 provided that you first follow

these steps before getting started. In order to use the Multilingual App Toolkit your application must be built or

modified in order to support localization. This means that all your localized resources are separated from the code.

3.4.2 Layout Design

Windows Phone provides a flexible layout system that enables you to specify how controls are positioned on the screen.

Windows Phone provides various Panel controls, such as Canvas,

StackPanel, and Grid, that serve as containers and enable you to position and arrange the controls.

The Windows Phone layout system supports both an absolute layout and a

dynamic layout. In an absolute layout, controls are positioned using explicit x/y coordinates (for example, by using a Canvas). In a dynamic layout, the

user interface automatically sizes to various screen resolutions (for example, by using a StackPanel or a Grid).

Absolute Layout: Windows Phone provides a Canvas control to support absolute positioning. By default, when you create a new Windows Phone app project, the root layout panel is a Grid to create a layout based on absolute positioning, you must replace the Grid with a Canvas.

Dynamic Layout: In a dynamic layout, the user interface appears correctly on various screen resolutions. You arrange child elements by specifying how they should be

arranged and how they should wrap relative to their parent.

Auto and Star Sizing: Auto sizing is used to allow controls to fit their content, even if the content

changes size. Star sizing is used to distribute available space among the rows and columns of a grid by weighted proportions.

3.4.3 Resource Files

While creating new windows phone application project, Visual Studio will give you one resource file by default. This resource file contains the default styling and control templates which is used by the app.

Moreover that, developer can write specific resource code in any other file like xaml or cs, and make that file code available in whole application.

Generally the main function of resource file comes into picture when any app needs to be localized. At that time, developer need to add region specific resources into the resource files and then use it in the app whenever required.

3.4.4 Package Configuration file

In visual studio solution explorer, you can see one more file named

“Packages.config”. This is the configuration files which contains information of libraries and packages used in the specific windows phone application

project.

This config file, is general XML file, formatted to store the information like package identity, package name, package function and specific package’s

location into the project root directory.

3.4.5 Manifest File

The Manifest file resides under the Properties section of project’s root directory. This Manifest file contains information regarding the whole

project.

There are mainly 4 sections in this Manifest File. In Windows phone application project based on WinRT framework, the project manifest may contains more then 4 sections.

Application UI: This section contains the information regarding App Name, Application

description, Application icon, supported resolutions of the windows phone application, Tile Images, Till Title, Tile templates.

Capabilities: This section specifies the capabilities that application uses. Those capabilities may be like, Camera access, Phone Book access, Microphone, Media Library access so on and so forth.

Requirements: This section specifies the hardware requirement of the application by the

windows phone. It can be like Front Camera, Gyroscope, and Magnetometer etc.

Packaging: This section contains information regarding the package generated after building the application project which will be deployed to specific windows phone device. This information is like Author, publisher, Product ID, Publisher ID and Versions etc.

3.4.6 REST Clients

Using RESTful services and REST client for WebService or calls are the best and the secure way of communication between client and server in

windows phone application.

Though using REST Client is not the easy way to do it, as there are hundreds of third party libraries available in the market as of now.

Through the use REST client developer can call the server URL directly through communication API with any of the method like GET, POST or Do.

Windows Phone Application project supports most of all kind of data encoding to send it to the server through post or any other method. Those can be in form of “jSon” or may be in form of “Multipart-FormData”.

3.5 Publishing Consideration for Windows Phone Application

App certification is required, in order to publish any app on windows phone store.

To certify your app on store, the windows phone application must comply with the terms and condition supplied by windows phone store. With that,

application also requires to fulfill the criteria decided by windows phone store, for any application to be published on store.

3.5.1 App Publishing

To publish any app on Windows Phone Store, one need to have Windows Phone Developer account. There are two different types of developer account available. Individual Developer Account & Enterprise Developer

Account. Both Functionality and Pricing differs for both types of developer account.

To publish any app on windows phone store, developer need to generate application package by building the app from visual studio in “Release” mode of configuration manager.

After generating “Release” package of Windows Phone application project,

go to the “Windows Phone Developer portal”, URL: http://www.dev.windowsphone.com/dashboard

On the portal, submit the Information regarding your application as per asked by the portal and provide the screenshots (Maximum of 8, Minimum of 1) of your application, and icons with Store icon in appropriate resolution.

After providing the general information regarding the app, upload the “Release” mode package of application that you got from building the application in visual studio.

Publishing Stages: The application submitted to the store will go through various stages of certification and process the submission. Here are the main four stages among many.

- Submission Processing - Signing Stage - Pending certification - Published

3.5.2 App Feature Update

After publishing the app on store, developer can make updates to the app and publish the updated application package on store with it’s appropriate description and properties changed in update.

Here, to update any already published windows phone application on store, simply create an update submission from the windows phone store developer portal and specify the asked properties and information related to update, then submit then newer generated application package on store.

After submitting update to any app, the update submission will further go through all of those steps while it went through while submitting first impression of application.

If the application features certify the windows phone criteria, then it will be published as the next version of the app on store.

4. Tools

Windows Phone SDK 8.0 installs everything you need to build and test Windows Phone apps.

Other than windows phone SDK 8.0, if one needs some extra features provided by Ultimate, professional or premium Visual studio, then windows phone SDK can also be integrated with Visual Studio of any versions by default when installing specific Visual studio version.

Code & Design

Visual Studio Express 2012 for Windows Phone 8 is a complete development

environment for creating Windows Phone apps. It includes development features such as project templates, a code editor, a visual designer, and a

Toolbox of controls.

It also includes integrated testing features such as simulation, monitoring and profiling, and the Windows Phone Store Test Kit.

Blend for visual studio is used to design the Windows Phone application with

extra ordinary designs. Blend can make great User Interface for the app.

There are many Design Libraries available as well in the market to design some

of the great User Interface of windows phone application.

Run & Debug

Windows phone emulators can be used for debugging the application.

Emulators can also scale to available Windows phone resolutions to test and check whether it’s compatible with all resolutions or not.