Welcome to the second part of the tutorials on how to build a Windows Phone 8 app. Follow this link to get to the first article of this series.

Last time we built up the vision and identified the requirements of the app called Hello Friends. This time I would like to go a step further and to think about the project in general.

You can find the final version of the app I am writing about in the Windows Phone marketplace:

For today we have some open questions:

• Can we use existing libraries?
• How to structure the project?
• Which design patterns should be used?

Existing Libraries

Well, there are a lot of helpful libraries out there. And I really like using nice libraries that reduce one’s own programming effort. The following ones are the libraries we will use in this tutorial:

• MvvmLight: A library that helps you following the principle “Separation of Concerns”. The View is for displaying the user interface and forwarding user interactions, nothing more. The ViewModel is a representation of the view’s data and offers public properties that can be bound to the view. http://mvvmlight.codeplex.com/
• Microsoft.Practices.ServiceLocation: A simple and nice dependency injection container that helps you building loosely coupled applications (http://unity.codeplex.com/).
• WriteableBitmapEx: This is a great library from René Schulte with a lot of useful extension methods for the WriteableBitmap class. http://writeablebitmapex.codeplex.com/ We need this one because we will have to do some graphic stuff for generating lock screen images.

These are the basic libraries we will use in this tutorial. MvvmLight and Unity are basic libraries that can be used in almost every project. Additional ones like the Windows Phone Toolkit or some libraries for adding Google Analytics support are also worth checking them out. We will include them later, when necessary.

The Project Structure

Now we’re heading to the big question: How about the project structure?

The answer depends on several aspects: Do you want it quick and dirty? Do you want to reuse resulting libraries in different projects? If yes, are the other projects similar apps for the same platform? Do we need reusable libraries for Windows 8 or Xbox? Or even a shared library for Windows Phone 7?

Let me define the principles for this tutorial:

• We don’t want it quick and dirty. If the app sells well, you may want to maintain and extend features (non-functional requirements). We also want to be able to bring this app to Windows Phone 7.5, if users are asking for it. If you start quick and dirty, it gets even more dirty.
• I would always suggest building libraries that can be reused in other projects. This saves a lot of time, brings unity to your projects and helps you regarding the project structure: For example, if you put everything from the UI to the data layer together in one assembly, you can’t reuse anything.

The first step of structuring the source code is building separate projects in Visual Studio:

• The initial Windows Phone 8 project that contains the user interface
• One Windows Phone library that contains all the algorithms, data providers and so on.
• We also need another project for the Background Agent, because one of the requirements was to change the lock screen automatically from time to time
• We need a contracts assembly containing interfaces for instances that are registered to  the dependency injection container.

How to name these projects?

The project name you enter when creating the WP8 project in Visual Studio will also be used for the namespace. Of course, you can change that later, but it’s a good deal to have everything geared from the beginning to obtain a great structure.

I usually end up in naming projects according to namespaces:

I chose a generic name “LockScreenApp” because the final name of the product may change and generic names are better for the case if you want to reuse libraries in other projects. As you can see in the screenshot, we also have a library called “BrilliantVision.Common” which is just a collection of often used functionalities that I collected during developing several Windows Phone projects.

The marked project is the entry point containing user interfaces, the other ones I guess are self explaining.

Design Patterns

Design patterns are a great way to solve architectural issues and to keep the project structure clean. Remember: We don’t want a messy Windows Phone project. Before we start writing code we should think about patterns that can be very useful in our project. As I mentioned before, the MVVM pattern is great for decoupling the GUI from the business logic. We will also use the dependency injection principle, as well as the command and observer patterns. These are quite common for almost every kind of project. If you are not familiar with these principles I would suggest either this classic book or this one for those who need more examples. The latter comes with great explanations based on real-world scenarios.

Conclusion

At this point we’ve already collected requirements for the app and know what we want to build. We also know the technical environments: Which libraries do we use, what functionality do they offer. In one of the next parts I will focus more on designing the visual appearence of the app. I took this chapter before the UI design part because it is important to know the environmental parts with all their capabilities and restrictions. In the design phase we will be able to see more quickly where we have to put specific elements inside our project when having a basic structure.

Read part 3