Xamarin 4 By Example

The global search is one of the most powerful features of the editor.

It allows us to easily jump to the point of the code we need to retrieve.

Go to is the main feature of the global search, and this allows us to find a type, a file, or a declaration.

All we need to write is type:NameOfTheTypeWeAreLookingFor and we will be directed to the type.

When we are in a file, we can jump to a known line by typing in the global search :NumberOfLine:NumberOfColumn.

For example, :10:10 jumps to the 10^th line and 10^th column of the document.

The key bindings is a feature that allows us to use short key combinations for actions.

In the following table, we can have a look at some of them:

In the menu Tools | Options (Windows) or Xamarin Studio | Preferences (Mac), in the section Environment | Key Bindings we can look at all the default short keys and we can also define ours.

Xamarin Studio allows us to customize how the code will be automatically formatted.

We will find this feature very useful when we want to be consistent with the coding standard of our company or the coding standards of our customer.

To customize it, we go to Tools | Options (Windows) or Xamarin Studio | Preferences (Mac) and select in the left menu Source Code | Code Formatting | C#. A drop-down list appears, where we can select the coding style we prefer, or we can also define our own coding standard by going in to the tab C# Format. We will now see an example of code with the current coding standard. Clicking on the Edit button, we can choose from different layout options for Indentation, Braces, Blank Lines, Wrapping, White Spaces, and New Lines.

The Code Formatting settings are not saved in the solution but in the local settings of Xamarin Studio. If we share our code with another person with different policies, when they open the solution with their customized Xamarin Studio, they will have the option to apply their own policies for the solution or use the project specific user settings.

A code template is a block of reusable code that we can insert where we need it in our code. Code templates can be simple or very complex. For example, blocks such as try…finally and if…else are commonly used, but we could also use code templates to insert entire classes or methods.

To try one of them, we can go to the Program.cs, writing in the global search file:Program.cs and pressing Enter.

After the Console.Writeline("Hello World"); we can write for and press double Tab.

There the following code would automatically appear:

for (int i = 0; i < max; i++) 
{ 
 
} 

Using the Tab button, we can navigate between two fields, i and max. We can change them with the values we need. By replacing the field i with myIndex, all the i in the template will be updated with the new value. When we arrive at the last editable value, we can press enter and at this point the template will be transformed in to regular code.

The code templates are written with a simple meta-language.

Here is a small list of the code templates we can find useful:

As an exercise, we can try all of them in our code. To use them in our code, we need to write the keyword and press double Tab.

There are about 40 templates currently available for C# in Xamarin.

Going to Tools | Options (Windows) or Xamarin Studio | Preferences (Mac), under the Text Editor section we can find Code Templates, with all of them, and details of how they are implemented.

We can also write our own code template.

If we try to add a property by writing in the code prop + double Tab, it generates a short property as follows:

public object MyProperty { 
            get; 
            set; 
        } 

This has object and MyProperty as editable.

The implementation of this template in the meta-language is relatively easy.

public $type$ $name$ { 
    get; 
    set; 
} 

The words between the symbol $ are the ones that are editable. We can put them  in the code more than once, and when they have different names they can be navigated with the tab button. When they have the same name, the engine repeats for us, in realtime, what we write in the first field with that name.

It would be great and always useful to have a template that writes an extended property like this:

private object _myProperty;
public object MyProperty{
  get
  {
    return _myProperty;
  }
  set
  {
    _myProperty = value;
  }
}

Unfortunately, there is not a code template like this. The bright side is that we can create it.

Go to Tools | Options (Windows) or Xamarin Studio | Preferences (Mac), select Code Templates from the Text Editor section, and press Add.

As a shortcut, we can write propex. We need to select C# from the drop-down list called group and text/x-csharp from the drop-down list called mime. As a description, we can write Template for extended properties.

private $type$ $name$; 
public $type$ $Name${ 
    get 
    { 
        return $name$; 
    } 
    set 
    { 
        $name$ = value; 
    } 
} 

Now in the drop-down list, on the right, we can select three new fields that are all the fields we inserted between the $ symbols.

We can define the default values for type, name, and Name.

After defining the default values for each field, we just need to press OK to save the snippet.

This is a very useful feature of Xamarin, disabled by default. When we enable it we have a powerful tool to raise the level of quality of our code.

The source analysis checks code on the fly and warns of potential errors and style violation, suggesting automatic fixes. To enable it, we need to go to Tools | Options (Windows) or Xamarin Studio | Preferences (Mac) and turn it on from the Text Analysis in the Text Editor section.

When enabled, we can see markers in the scroll bar. By moving the mouse over them we can see the problems colored by severity. The scroll bar gives us a high level view of the quality of our code. Some of the suggestions are just recommendations, and this doesn't mean that they have to be addressed.

If we click on the marker and press Alt + Enter, a list of suggested actions will be shown and we can decide whether or not to automatically fix the issue with the suggested action.

Regions let us specify a block of code that we can retrieve in the navigation bar at the top left side of our document. In longer code files, it is convenient to separate the code into regions so that we can focus on the part of the file that we are currently working on. The following example shows how to define a region:

#region MyClass definition public class 
MyClass 
{ 
 static void Main() 
 { 
 } 
} 
#endregion 

A #region block must be terminated with a #endregion directive.

In general, we can comment a line in C# by using // before the part to comment or /* before the first char to comment and */ after the last one. In Xamarin Studio, we can also use a particular comment in our code by using // TODO: our comment. This will add the line commented on a task list that we will retrieve any time by clicking on the button Tasks positioned at the bottom right of Xamarin Studio.

To comment our classes and fields we use the documentation tags.

The documentation tags are comments in XML that can be useful if we want to automate the technical documentation of our app. The documentation tags are defined using /// and XML markup.

Xamarin generates the documentation tags for us. The quality of the auto-generated documentation tags is related to the quality of the coding standards we use.

Let's add, for example, a method to Program.cs called TransformTextInLowercase that transforms a string in its lowercase:

string TransformTextInLowercase(string textToTransform) 
{ 
     return textToTransform.ToLower(); 
} 

Adding the /// in the row before the first one and pressing enter allows Xamarin Studio to generate the following comment for us:

/// <summary> 
/// Transforms the text in lowercase. 
/// </summary> 
/// <returns>The text in lowercase.</returns> 
/// <param name="textToTransform">Text to transform.</param> 
string TransformTextInLowercase ( string textToTransform) 
{ 
      return textToTransform.ToLower(); 
} 

Xamarin and the Microsoft C# compiler provide us with a way to extract the documentation from the comments.

It looks for XML documentation comments within the source code (comments that start with three slashes, ///), and puts them all into a single XML file.

To auto generate this XML file, we have to:

Next time we compile, a new XML file that contains all the documentation tags will be automatically generated in the deployment folder.

The xml file can be used as the starting point to generate automatic documentation. We can write an xsl to present the data in html, or use tools such as NDoc, Monodoc, or Sandcastle to build a help file.

The UX design is the process of maximizing the usability and the interaction between the user and the application.

This is usually done using mockups and wireframes that may be created even with low tech tools: pencil and paper. But don't worry, that is not the only way! There are tools such as Balsamiq and InVisio that help UX designers to define mockups, providing a first feeling of the app.

This helps to define the interactions and the placeholders before starting the UI design.

User experience is not cross-platform.

When designing the user experience, it is important to consider the interface guidelines for each of the platforms we are designing for.

By following the platform-specific guidelines, we can ensure that our apps are well integrated on the operating system where they are running:

For example, each platform has its own way to switch between sections, to manage images, and so on. Even the available hardware influences the user expectations for our app. For example, Android devices have a back button, while iOS users expect to have a button in the UI that drives them back to the previous section and the only button is expected to go to the main screen.

UI design transforms the mockups into graphics elements. Spending time on a good UI design is always a good investment. Consider that the most popular apps generally also have great designs and usability.

A well-designed app usually looks different on each platform. As for the UX, it's important to understand that each platform has its own design language.

One example of these differences is the dimension of icons and images that we need in order to see them sharply and crisply on each supported platform.

Apple iOS apps are distributed to the Apple "App Store" via "Apple Connect".

When we submit an App to Apple Connect, we have to wait for a validation. Usually Apple is very strict with the validation process and it can take some weeks.

If our app is not compliant with all the Apple guidelines, it will be rejected with a list of issues to address in order to be compliant.

The Apple Store is the most popular distribution method for iOS applications, and it allows us to market and distribute our apps online with very little effort.

The second type of deployment is the enterprise deployment.

This is used for internal distribution of corporate applications that aren't available via the App Store.

A deployment also exists that is intended primarily for development and testing: "ad-hoc deployment".

The official app store for Android is Google Play, but as we will see, there are a few other different stores that we can consider.

Android is also open to app distribution. Devices are not locked to a single, approved app store.

Anyone is free to create an app store, and most Android phones allow apps to be installed from these third-party stores.

This allows us a potentially larger distribution channel for our applications.

Windows Phone applications are distributed to users via the Windows Store.

We need to submit our apps to the Windows Phone Dev Center for approval, after which they appear in the Store. When we submit our apps to the Windows Store, we can also provide an install link to the testers before the app is reviewed and published.