Showing posts with label Xamarin. Show all posts
Showing posts with label Xamarin. Show all posts
  • PCL or SAP? When you first created the Hello solution in Visual Studio, you had a choice of two application templates:

     Blank App (Xamarin.Forms Portable)
     Blank App (Xamarin.Forms Shared)

    In Xamarin Studio, the choice is embodied in a pair of radio buttons:
     Use Portable Class Library
     Use Shared Library

    The first option creates a Portable Class Library (PCL), whereas the second creates a Shared Asset Project (SAP) consisting only of shared code files. The original Hello solution used the PCL template. Now let’s create a second solution named HelloSap with the SAP template.

    As you’ll see, everything looks pretty much the same, except that the HelloSap project itself contains only one item: the App.cs file.

    With both the PCL and SAP approaches, code is shared among the five applications, but in decidedly different ways: With the PCL approach, all the common code is bundled into a dynamic-link library that each application project references and binds to at run time. With the SAP approach, the common code files are effectively included with each of the five application projects at build time. By default, the SAP has only a single file named App.cs, but effectively it’s as if this HelloSap project did not exist and instead there were five different copies of this file in the five application projects.

    Some subtle (and not-so-subtle) problems can manifest themselves with the shared library approach:
    The iOS and Android projects have access to pretty much the same version of .NET, but it is not the same version of .NET that the Windows projects use. This means that any .NET classes accessed by the shared code might be somewhat different depending on the platform. As you’ll discover later in this book, this is the case for some file I/O classes in the System.IO namespace.

    You can compensate for these differences by using C# preprocessor directives, particularly #if and #elif. In the projects generated by the Xamarin.Forms template, the various application projects de-fine symbols that you can use with these directives.

    What are these symbols?

    In Visual Studio, right-click the project name in the Solution Explorer and select Properties. At the left of the properties screen, select Build, and look for the Conditional compilation symbols field.
    In Xamarin Studio, select an application project in the Solution list, invoke the drop-down tools menu, and select Options. In the left of the Project Options dialog, select Build > Compiler, and look for the Define Symbols field.

    Here are the symbols that you can use:
     iOS project: You’ll see the symbol __IOS__ (that’s two underscores before and after)

     Android project: You won’t see any symbols defined for indicating the platform, but the identi-fier __ANDROID__ is defined anyway, as well as multiple __ANDROID_nn__ identifiers, where nn is each Android API level supported.

     UWP project: The symbol WINDOWS_UWP

     Windows project: The symbol WINDOWS_APP

     Windows Phone project: The symbol WINDOWS_PHONE_APP

    Your shared code file can include blocks like this:
    #if __IOS__
        // iOS specific code
    #elif __ANDROID__ /
        / Android specific code
    #elif WINDOWS_UWP
       // Universal Windows Platform specific code
    #elif WINDOWS_APP
       // Windows 8.1 specific code
    #elif WINDOWS__PHONE_APP
       // Windows Phone 8.1 specific code
    #endif

    This allows your shared code files to run platform-specific code or access platform-specific classes, in-cluding classes in the individual platform projects. You can also define your own conditional compila-tion symbols if you’d like.

    These preprocessor directives make no sense in a Portable Class Library project. The PCL is entirely independent of the five platforms, and these identifiers in the platform projects are not present when the PCL is compiled.

    The concept of the PCL originally arose because every platform that uses .NET actually uses a some-what different subset of .NET. If you want to create a library that can be used among multiple .NET platforms, you need to use only the common parts of those .NET subsets.

    The PCL is intended to help by containing code that is usable on multiple (but specific) .NET platforms. Consequently, any particular PCL contains some embedded flags that indicate what platforms it supports. A PCL used in a Xamarin.Forms application must support the following platforms:

     .NET Framework 4.5
     Windows 8
     Windows Phone 8.1
     Xamarin.Android
     Xamarin.iOS
     Xamarin.iOS (Classic)

    This is known as PCL Profile 111.
    If you need platform-specific behavior in the PCL, you can’t use the C# preprocessor directives because those work only at build time. You need something that works at run time, such as the Xamarin-.Forms Device class. You’ll see an example shortly.

    The Xamarin.Forms PCL can access other PCLs supporting the same platforms, but it cannot directly access classes defined in the individual application projects. However, if that’s something you need to do—and you’ll see an example in Chapter 9, “Platform-specific API calls”—Xamarin.Forms provides a class named DependencyService that allows you to access platform-specific code from the PCL in a methodical manner.

    Most of the programs in this book use the PCL approach. This is the recommended approach for Xamarin.Forms and is preferred by many programmers who have been working with Xamarin.Forms for a while. However, the SAP approach is also supported and definitely has its advocates as well. Pro-grams within these pages that demonstrate the SAP approach always contain the letters Sap at the end of their names, such as the HelloSap program.

    But why choose? You can have both in the same solution. If you’ve created a Xamarin.Forms solu-tion with a Shared Asset Project, you can add a new PCL project to the solution by selecting the Class Library (Xamarin.Forms Portable) template. The application projects can access both the SAP and PCL, and the SAP can access the PCL as well.

    Source of Information : Creating Mobile Apps with Xamarin.Forms

    more

  • hello xamarin Using either Microsoft Visual Studio or Xamarin Studio, let’s create a new Xamarin.Forms application by using a standard template. This process creates a solution that contains up to six projects: five platform projects—for iOS, Android, the Universal Windows Platform (UWP), Windows 8.1, and Windows Phone 8.1—and a common project for the greater part of your application code.

    In Visual Studio, select the menu option File > New > Project. At the left of the New Project dialog, select Visual C# and then Cross-Platform. In the center part of the dialog you’ll see several available solution templates, including three for Xamarin.Forms:

     Blank App (Xamarin.Forms Portable)
     Blank App (Xamarin.Forms Shared)
     Class Library (Xamarin.Forms)

    Now what? We definitely want to create a Blank App solution, but what kind?

    Xamarin Studio presents a similar dilemma but in a different way. To create a new Xamarin.Forms solution in Xamarin Studio, select File > New > Solution from the menu, and at the left of the New Project dialog, under Multiplatform select App, pick Forms App, and press the Next button. Toward the bottom of the next screen are a pair of radio buttons labeled Shared Code. These buttons allow you to choose one of the following options:

     Use Portable Class Library
     Use Shared Library

    The term “Portable” in this context refers to a Portable Class Library (PCL). All the common application code becomes a dynamic-link library (DLL) that is referenced by all the individual platform projects.

    The term “Shared” in this context means a Shared Asset Project (SAP) containing loose code files (and perhaps other files) that are shared among the platform projects, essentially becoming part of each platform project.

    For now, pick the first one: Blank App (Xamarin.Forms Portable) in Visual Studio or Use Portable Class Library in Xamarin Studio. Give the project a name—for example, Hello—and select a disk loca-tion for it in that dialog (in Visual Studio) or in the dialog that appears after pressing the Next button again in Xamarin Studio.

    If you’re running Visual Studio, six projects are created: one common project (the PCL project) and five application projects. For a solution named Hello, these are:

     A Portable Class Library project named Hello that is referenced by all five application projects;
     An application project for Android, named Hello.Droid;
     An application project for iOS, named Hello.iOS;
     An application project for the Universal Windows Platform of Windows 10 and Windows Mobile 10, named Hello.UWP;
     An application project for Windows 8.1, named Hello.Windows; and
     An application project for Windows Phone 8.1, named Hello.WinPhone.

    If you’re running Xamarin Studio on the Mac, the Windows and Windows Phone projects are not created.

    When you create a new Xamarin.Forms solution, the Xamarin.Forms libraries (and various support libraries) are automatically downloaded from the NuGet package manager. Visual Studio and Xamarin Studio store these libraries in a directory named packages in the solution directory. However, the par-ticular version of the Xamarin.Forms library that is downloaded is specified within the solution tem-plate, and a newer version might be available.

    In Visual Studio, in the Solution Explorer at the far right of the screen, right-click the solution name and select Manage NuGet Packages for Solution. The dialog that appears contains selectable items at the upper left that let you see what NuGet packages are installed in the solution and let you install others. You can also select the Update item to update the Xamarin.Forms library.

    In Xamarin.Studio, you can select the tool icon to the right of the solution name in the Solution list and select Update NuGet Packages.

    Before continuing, check to be sure that the project configurations are okay. In Visual Studio, select the Build > Configuration Manager menu item. In the Configuration Manager dialog, you’ll see the PCL project and the five application projects. Make sure the Build box is checked for all the projects and the Deploy box is checked for all the application projects (unless the box is grayed out). Take note of the Platform column: If the Hello project is listed, it should be flagged as Any CPU. The Hello.Droid project should also be flagged as Any CPU. (For those two project types, Any CPU is the only option.) For the Hello.iOS project, choose either iPhone or iPhoneSimulator depending on how you’ll be testing the program.

    For the Hello.UWP project, the project configuration must be x86 for deploying to the Windows desktop or an on-screen emulator, and ARM for deploying to a phone.

    For the Hello.WinPhone project, you can select x86 if you’ll be using an on-screen emulator, ARM if you’ll be deploying to a real phone, or Any CPU for deploying to either. Regardless of your choice, Visual Studio generates the same code.

    If a project doesn’t seem to be compiling or deploying in Visual Studio, recheck the settings in the Configuration Manager dialog. Sometimes a different configuration becomes active and might not include the PCL project.

    In Xamarin Studio on the Mac, you can switch between deploying to the iPhone and iPhone simula-tor through the Project > Active Configuration menu item.

    In Visual Studio, you’ll probably want to display the iOS and Android toolbars. These toolbars let you choose among emulators and devices and allow you to manage the emulators. From the main menu, make sure the View > Toolbars > iOS and View > Toolbars > Android items are checked.

    Because the solution contains anywhere from two to six projects, you must designate which pro-gram starts up when you elect to run or debug an application.

    In the Solution Explorer of Visual Studio, right-click any of the five application projects and select the Set As StartUp Project item from the menu. You can then select to deploy to either an emulator or a real device. To build and run the program, select the menu item Debug > Start Debugging.

    In the Solution list in Xamarin Studio, click the little tool icon that appears to the right of a selected project and select Set As Startup Project from the menu. You can then pick Run > Start Debugging from the main menu. If all goes well, the skeleton application created by the template will run and you’ll see a short message:

    As you can see, these platforms have different color schemes. The iOS and Windows 10 Mobile screens display dark text on a light background, while the Android device displays light text on a black background. By default, the Windows 8.1 and Windows Phone 8.1 platforms are like Android in dis-playing light text on a black background.

    By default, all the platforms are enabled for orientation changes. Turn the phone sideways, and you’ll see the text adjust to the new center. The app is not only run on the device or emulator but deployed. It appears with the other apps on the phone or emulator and can be run from there. If you don’t like the application icon or how the app name displays, you can change that in the individual platform projects.

    Source of Information : Creating Mobile Apps with Xamarin.Forms

    more

  • Xamarin - Anatomy of an app The modern user interface is constructed from visual objects of various sorts. Depending on the operating system, these visual objects might go by different names—controls, elements, views, widgets—but they are all devoted to the jobs of presentation or interaction or both.

    In Xamarin.Forms, the objects that appear on the screen are collectively called visual elements. They come in three main categories:

     page
     layout
     view

    These are not abstract concepts! The Xamarin.Forms application programming interface (API) defines classes named VisualElement, Page, Layout, and View. These classes and their descendants form the backbone of the Xamarin.Forms user interface. VisualElement is an exceptionally important class in Xamarin.Forms. A VisualElement object is anything that occupies space on the screen.
    A Xamarin.Forms application consists of one or more pages. A page usually occupies all (or at least a large area) of the screen. Some applications consist of only a single page, while others allow navigating between multiple pages.

    On each page, the visual elements are organized in a parent-child hierarchy. The child of a ContentPage is generally a layout of some sort to organize the visuals. Some layouts have a single child, but many layouts have multiple children that the layout arranges within itself. These children can be other layouts or views. Different types of layouts arrange children in a stack, in a two-dimensional grid, or in a more freeform manner. In this chapter, however, our pages will contain just a single child.

    The term view in Xamarin.Forms denotes familiar types of presentation and interactive objects: text, bitmaps, buttons, text-entry fields, sliders, switches, progress bars, date and time pickers, and others of your own devising. These are often called controls or widgets in other programming environments. This book refers to them as views or elements. In this chapter, you’ll encounter the Label view for displaying text.

    Source of Information : Creating Mobile Apps with Xamarin.Forms

    more

Subscribe to: Posts (Atom)