Hi guys, Arief here from the Intersoft Consultant team. Today I will talk about how to use iOS Collection View and Android Grid View in order to create a beautiful cross-platform navigation menu. At the end of this tutorial, you’ll learn how to use the collection view in your Crosslight applications, which looks similar to the following illustration.

Introduction

Collection View / Grid View (will be referred as Collection View from now on) is a very versatile user interface. As a matter fact, both iOS and Android have always been using it as a native pattern for Springboard (iOS home) as well as lots of other Android launchers. Nowadays those trends start to spread throughout business apps considering how user-friendly and eye-pleasing when compared to the plain old list view.

If you are interested in creating a gorgeous and cool business apps, using collection view is a must! In this tutorial, I will guide you step by step how you can create collection view using the Crosslight style.

Here are the steps that you need to follow:

• Core Preparation
• Assets Preparation
• Designing Android Grid View
• Designing iOS Collection View
• Capturing Selection

Without further ado, let’s get started!

Preparing the Project

The first thing you’ll need is, of course, the project itself. Start by creating a new project using Crosslight Project Wizard and choose the Blank template. To do this, from Visual Studio 2012 and upwards, choose New, Project. From the dialog that appears, choose Crosslight and choose to create a new Crosslight application with the Blank template. For the purposes of this tutorial, we’ll name this project: CollectionView. Now that you have your project ready, let’s move on.

Core Preparation

Here are several things you need to prepare at the project Core level:

• Prepare the ViewModel
• Prepare the BindingProvider

Prepare the ViewModel

Begin by creating a new ViewModel in CollectionView.Core/ViewModels folder. Simply right-click on the ViewModels folder and choose Add, New Item. We will be repeating this method several times in later sections to add new items to our project, so keep this in mind.

Crosslight also ships with built-in item templates that are integrated with Visual Studio, so you can quickly create Crosslight classes right within Visual Studio or Xamarin Studio. In the next dialog that appears, choose Visual C#, Crosslight, then choose Crosslight List View Model. Name this ViewModel as CollectionViewModel.

Copy-paste these codes to the newly-created CollectionViewModel.cs:

using Intersoft.Crosslight;
using Intersoft.Crosslight.ViewModels;
using System.Collections.Generic;

namespace CollectionView.Core.ViewModels
{
    public class CollectionViewModel : ListViewModelBase
    {
        #region Constructors

        public CollectionViewModel()
        {
			List items = new List();

			items.Add(new NavigationItem("Ride", typeof(SimpleViewModel)) { Image = "CrosstransRide.png" });
			items.Add(new NavigationItem("Delivery", typeof(SimpleViewModel))  { Image = "CrosstransDeliver.png" });
			items.Add(new NavigationItem("Food", typeof(SimpleViewModel))  { Image = "CrosstransFood.png" });
			items.Add(new NavigationItem("Shop", typeof(SimpleViewModel))  { Image = "CrosstransShop.png" });

			this.SourceItems = items;
        }

        #endregion
    }
}

Let’s take a quick look at the above code. In the constructor of the CollectionViewModel, we initialize a list of NavigationItems that holds the navigation menus. NavigationItem is a very useful class provided by Crosslight that you can utilize to create a menu, as it holds all the common properties you need to create a navigation item. All you have to do is simply populate it with the menu title, image/icon name, and the target ViewModel as navigation target.

Preparing the BindingProvider

Next step would be adding a new Crosslight List Binding Provider under your CollectionView.Core/BindingProviders folder. Give it a name of CollectionBindingProvider.cs.

And change the code to the following:

using Intersoft.Crosslight;

namespace CollectionView.Core.BindingProviders
{
    public class CollectionViewBindingProvider : BindingProvider
    {
        #region Constructors

        public CollectionViewBindingProvider()
        {
            ItemBindingDescription itemBinding = new ItemBindingDescription
            {
                DisplayMemberPath = "Title",
                ImageMemberPath = "Image",
                NavigateMemberPath = "Target"
            };

            this.AddBinding("GridView", BindableProperties.ItemsSourceProperty, "Items");
            this.AddBinding("GridView", BindableProperties.ItemTemplateBindingProperty, itemBinding, true);
            this.AddBinding("GridView", BindableProperties.IsBatchUpdatingProperty, "IsBatchUpdating");
            this.AddBinding("GridView", BindableProperties.SelectedItemProperty, "SelectedItem", BindingMode.TwoWay);
            this.AddBinding("GridView", BindableProperties.SelectedItemsProperty, "SelectedItems", BindingMode.TwoWay);
            this.AddBinding("GridView", BindableProperties.IsEditingProperty, "IsEditing", BindingMode.TwoWay);

            this.AddBinding("RefreshButton", BindableProperties.RefreshCommandProperty, "RefreshCommand");

            // navigation
            //this.AddBinding("TableView", BindableProperties.DetailNavigationTargetProperty, new NavigationTarget(typeof(TViewModel)), true);

            // edit commands
            this.AddBinding("AddButton", BindableProperties.CommandProperty, "AddCommand");

            this.AddBinding("DeleteButton", BindableProperties.CommandProperty, "DeleteCommand");
            this.AddBinding("DeleteButton", BindableProperties.CommandParameterProperty, "SelectedItems");
        }

        #endregion
    }
}

In the above code, we simply comment out the DetailNavigationTargetProperty, as it won’t be needed because our goal is only to create a navigation menu. It will be needed if you want to create Master-Detail Navigation. We also assign the MemberPaths with the properties from NavigationItem, such as ImageMemberPath for the icon, DisplayMemberPath for displaying the title, and NavigateMemberPath for the target ViewModel menu. To learn more about Crosslight Binding Provider, check out this link.

Your Core is up and ready. Let’s prepare our assets next.

Assets Preparation

Previously in the Binding Provider, you have already specified the Image property in NavigationItem from ViewModel which contains the filename for the .png file that we will use. When you bind it to the BindableProperties.ImageProperty or ImageMemberPath, it will find the appropriate files to use in CollectionView.Android/Resources/drawable or in CollectionView.iOS/Resources. So you need to put these files inside both folders because we will be using it for our app’s interface.

Tip: Make sure to optimize the size of your image files. In some phones, images with humongous file size will be ignored and they won’t show. Okay, since you have finished preparing the assets, let’s continue to Android GridView!

Designing Android GridView

Designing a view for Android is relatively easy and simple. In overall, we’ll be doing these tasks:

• Create an Activity for CollectionActivity.
• Create the view layout.
• Define the ContentLayoutId and ItemLayoutId.

To start, simply add a new item and use Crosslight Android Activity to get started. Put it inside the CollectionView.Android/Activities folder and name it CollectionActivity.cs.

After your CollectionActivity is created, change the contents of the class to the following code.

using Android.App;
using Intersoft.Crosslight;
using Intersoft.Crosslight.Android;

namespace CollectionView.Android.Activities
{
    [Activity(Label = "Menu")]
    [ImportBinding(typeof(CollectionBindingProvider))]
    public class CollectionActivity : GridActivity
    {
        public override ListViewInteraction InteractionMode
        {
            get{ return ListViewInteraction.Navigation; }
        }

        protected override int ContentLayoutId
        {
            get{ return Resource.Layout.CollectionLayout;}
        }

        protected override int GridItemLayoutId 
        {
	       get{ return Resource.Layout.ItemLayout; }
	    }

        protected override void InitializeView()
        {
            base.InitializeView();
            this.GridView.NumColumns = 2;
        }
    }
}

We need to replace the Activity with GridActivity, in which then you have more properties to override: ListViewInteraction. By overriding the ListViewInteraction into ListViewInteraction.Navigation, it allows the user to use the grid as a navigation button when an item is tapped.

ContentLayoutId is also overridden since we want to customize the appearance of our GridView, which we will do in just a moment. The ItemLayoutId is overridden to customize the item layout to be used with the GridView. Both ContentLayoutId and ItemLayoutId refers to Android layout files which exist in the CollectionView.Android/Resources folder.

Since we only have two columns for this scenario, we can simply provide the number of columns to show in the overridden InitializeView method by setting this.GridView.NumColumns to 2. The advantage of using this method is: you actually don’t need to specify the width of the Grid. The GridActivity automatically adjusts the optimal number of items by taking account the viewport width.

Earlier, we’ve specified the ContentLayoutId and ItemLayoutId in our Activity. Now let’s create those layouts. You will need to create two layouts inside CollectionView.Android/Resources/layout folder using Android Layout item template. We will name it CollectionLayout.axml & ItemLayout.axml.

Here’s the code for CollectionLayout.axml and ItemLayout.axml respectively.

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:background="@drawable/CrosstransBg"
    android:minWidth="25px"
    android:minHeight="25px">
    <LinearLayout
        android:orientation="horizontal"
        android:layout_marginBottom="25dp"
        android:layout_marginTop="50dp"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:id="@+id/linearLayout1"
        android:gravity="center_horizontal">
        <ImageView
            android:src="@drawable/CrosstransLogo"
            android:layout_width="wrap_content"
            android:layout_height="100dp"
            android:id="@+id/imageView1" />
    </LinearLayout>
    <GridView
        android:minWidth="25px"
        android:minHeight="25px"
        android:layout_margin="20dp"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:verticalSpacing="20dp"
        android:horizontalSpacing="20dp"
        android:id="@+id/GridView" />
</LinearLayout>

From the designer’s view, the CollectionLayout looks like the following:

and here’s the contents for ItemLayout.axml:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:minWidth="25px"
    android:minHeight="25px"
    android:background="#CC2368C0"
    android:gravity="center_horizontal">
    <LinearLayout
        android:orientation="vertical"
        android:layout_width="100dp"
        android:layout_height="100dp"
        android:id="@+id/linearLayout1"
        android:gravity="center_horizontal|center_vertical">
        <ImageView
            android:src="@android:drawable/ic_menu_gallery"
            android:scaleType="centerCrop"
            android:adjustViewBounds="true"
            android:layout_width="wrap_content"
            android:layout_height="50dp"
            android:id="@+id/ImageView" />
    </LinearLayout>
    <TextView
        android:text="Medium Text"
        android:textAppearance="?android:attr/textAppearanceMedium"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_marginBottom="20dp"
        android:id="@+id/TextLabel"
        android:gravity="center_horizontal" />
</LinearLayout>

From the designer’s view, it looks like this:

In summary, what I do in CollectionLayout.axml is setting the background for the page, add a header, and provide enough spacing between GridView items. The most important things to note is I’ve defined the GridView id,  @+id/GridView. The will be the reference that we defined in BindingProvider to the property in ViewModel, so make sure the id name is right!

We will be doing a similar task with ItemLayout.axml, where we assign both ImageView to the Image Property in ViewModel and TextView to Title Property in ViewModel. By default, Crosslight provides two built-in ids for showing an image and a text for item template, which has the name ImageView and TextLabel respectively. But if you want to add additional view elements to the item template, then you can simply add a new binding definition in the binding provider like this which must be done in BindingProvider:

itemBinding.AddBinding ("CustomView", BindableProperties.TextProperty, "Title");

Run the project. You should get a result similar to the following:

Next, let’s create the iOS version.

Designing iOS CollectionView

Similar to Android, building CollectionView on iOS follows a pretty similar path:

• Create a ViewController for MainCollectionView.
• Create the cell and the header.
• Set the outlets.

Let’s start from the ViewController. Add a new item using Crosslight iOS Collection View Controller template and put it inside your CollectionView.iOS/ViewControllers folder and name it MainCollectionView.cs.

This is the code for the ViewController.

using CollectionView.ViewModels;
using CollectionView;
using Intersoft.Crosslight;
using Intersoft.Crosslight.iOS;
using Foundation;
using UIKit;

namespace CollectionView.iOS
{
	[Register ("MainCollectionView")]
	[ImportBinding (typeof(CollectionBindingProvider))]
	public class MainCollectionView : UICollectionViewController
	{
		#region Constructors

		public MainCollectionView ()
			: base ("MainCollectionView", null)
		{
		}

		#endregion

		#region Properties

		public override UIViewTemplate CellTemplate {
			get { return new UIViewTemplate (CollectionViewCell.Nib); }
		}

		public override CollectionViewInteraction InteractionMode {
			get { return CollectionViewInteraction.Navigation; }
		}

		public override bool ShowSectionHeader {
			get { return true; }
		}

		public override UIViewTemplate SectionHeaderTemplate {
			get { return new UIViewTemplate(CollectionHeader.Nib); }
		}

		#endregion

		#region Methods

		protected override void InitializeView ()
		{
			base.InitializeView ();

			this.NavigationItem.Title = "Home";
                        UIImageView backView = new UIImageView(UIImage.FromFile ("CrosstransBg.png")); 
                        backView.ContentMode = UIViewContentMode.ScaleAspectFill; 
                        this.CollectionView.BackgroundView = backView;
			// Register Views
			this.RegisterViewIdentifier ("GridView", this.CollectionView);
		}

		#endregion
	}
}

Let’s take a look at some of the overridden methods and properties.

• CellTemplate: This property is the equivalent of Android’s ItemLayoutID, which will define the view to be used as navigation item inside the Collection View.
• InteractionMode: This method is the equivalent of Android’s ListViewInteraction, that defines the interaction when users tap on the navigation item.
• SectionHeader & SectionHeaderTemplate: It will be used to specify the header for the Collection View.
• InitializeView: This method is called when the view is initialized. Here, we set the background view of the Collection View. Afterward, this.RegisterViewIdentifier (“GridView”, this.CollectionView); is used to associate the Collection View with the GridView view identifier to be used by the Binding Provider.

Now your view controller is done! Next, we’ll create the CollectionView Header and Cells. Inside your CollectionView.iOS/Views, add 2 new items: Crosslight iOS Collection Cell, we will name it CollectionViewCell.cs (feel free to choose between iPhone or iPad) and  Crosslight iOS Collection View Group Header which we will name it CollectionHeader.cs.

If you check back your MainCollectionView.cs, you can see that both CollectionViewCell.Nib & CollectionHeader.Nib are now detected. The Nib represents both .cs files that we’ve created before. However, we won’t touch any codes, instead we will play around with the layout using iOS XCode.

Let’s first open the MainCollectionView.xib inside your CollectionView.iOS/Views using Apple XCode. Inside the Document Outline, you can select File’s Owner, then the Identity Inspector will change according to what  you selected. Specify the Custom Class as MainCollectionView.

Using the Connections Inspector, control + drag the view from Outlets to the Collection View to set the outlet, as shown in the following illustration.

Then, in the File Inspector, turn off Auto Layout.

In the Size Inspector, specify the cell’s width and height, also adjusting the auto-resizing behaviors so that it will layout nicely when the device is rotated.

Now you are done configuring your MainCollectionView.xib.

Let’s continue to CollectionViewCell.xib, in this case, you don’t need to worry about  your File’s Owner,  Simply drag and drop a Label and ImageView from the Object Library to the view.

Select your Label (or anything in your designer interface), Press the conjoined circle button on the right top. A panel with codes will appear, this is the Assistant Editor which will help you create Binding without having you to code anything.

Next, let’s set the outlets using the Assistant Editor. Select your CollectionViewCell.m and change it to CollectionViewCell.h, control + drag your Label into the panel and give it TextLabel as a name, then set the ImageView outlet with the name of ImageView.

You need to turn off the auto layout from both image, label, and their parent to use auto resizing. Here’s what I’ve done to each of them:

• View: Change the background color, turn on the horizontal and vertical scaling so that it won’t grow or shrink when the display rotates.
• TextLabel: Change the alignment to the middle,  Pin it to the bottom using auto resizing and change the width to 120 and height to 50
• ImageView: Change the view mode to Aspect fit, turn on the horizontal and vertical arrow inside auto-resizing, and changes the width and height to 60

In CollectionHeader.xib, what we do is just drag and drop an ImageView. Here are the settings for ImageView:

• Change the image with CrosstransLogo.png,
• View Mode to Aspect Fit,
• Width = 150,
• Turn on the horizontal and vertical arrow inside auto resizing

Here is the result:

Your app is pretty much done, but we still ned to capture what user has selected.

Capturing Selection

In this section, we’ll learn how to capture selection made when the user taps on any of the navigation items.

If you recall earlier, we’ve defined how our CollectionView should navigate, which is done in our BindingProvider in the NavigateMemberPath inside using ItemBindingDescription.

ItemBindingDescription itemBinding = new ItemBindingDescription
            {
                DisplayMemberPath = "Title",
                ImageMemberPath = "Image",
                NavigateMemberPath = "Target"
            };

As you are aware, each MemberPath represents the component of our menu. In fact, it also contains the whole data associated with the specific Item you choose from the list that you have created in your ViewModel back then.

public CollectionViewModel()
        {
			List items = new List();

			items.Add(new NavigationItem("Ride", typeof(SimpleViewModel)) { Image = "CrosstransRide.png" });
			items.Add(new NavigationItem("Delivery", typeof(SimpleViewModel))  { Image = "CrosstransDeliver.png" });
			items.Add(new NavigationItem("Food", typeof(SimpleViewModel))  { Image = "CrosstransFood.png" });
			items.Add(new NavigationItem("Shop", typeof(SimpleViewModel))  { Image = "CrosstransShop.png" });

			this.SourceItems = items;
        }

BindingProvider will obtain the target of your navigation, represented by typeof(SimpleViewModel)). However even though we already successfully navigate,  in our case each of our Item have the same Navigation target. What if we want to know which item/menu is selected? Here is how:

When you navigate to a new ViewModel, the Navigated method is called in the target ViewModel, and it contains the sender value which holds the information of the caller ViewModel. For the simplicity of this tutorial, we’ll change the SimpleViewModel to handle user input. Let’s change our SimpleViewModel.cs (CollectionView.Core/ViewModels folder):

using Intersoft.Crosslight;
using Intersoft.Crosslight.Input;
using Intersoft.Crosslight.ViewModels;

namespace CollectionView.ViewModels
{
    public class SimpleViewModel : ViewModelBase
    {
        #region Fields

        private string _footerText;
        private string _greetingText;
        private string _newText;

        #endregion

        #region Properties

        public string FooterText
        {
            get { return _footerText; }
            set
            {
                if (_footerText != value)
                {
                    _footerText = value;
                    OnPropertyChanged("FooterText");
                }
            }
        }

        public string GreetingText
        {
            get { return _greetingText; }
            set
            {
                if (_greetingText != value)
                {
                    _greetingText = value;
                    OnPropertyChanged("GreetingText");
                }
            }
        }

        public string NewText
        {
            get { return _newText; }
            set
            {
                if (_newText != value)
                {
                    _newText = value;
                    OnPropertyChanged("NewText");
                }
            }
        }

        public DelegateCommand ShowToastCommand { get; set; }

        #endregion

        #region Constructors

        public SimpleViewModel()
        {
            IApplicationContext context = this.GetService().GetContext();
            if (context.Platform.OperatingSystem == OSKind.Android)
                this.GreetingText = "Hello Android from Crosslight!";
            else if (context.Platform.OperatingSystem == OSKind.WinPhone)
                this.GreetingText = "Hello WinPhone from Crosslight!";
            else if (context.Platform.OperatingSystem == OSKind.WinRT)
                this.GreetingText = "Hello WinRT from Crosslight!";
            else if (context.Platform.OperatingSystem == OSKind.iOS)
                this.GreetingText = "Hello iOS from Crosslight!";

            this.FooterText = "Powered by Crosslight®";
            this.ShowToastCommand = new DelegateCommand(ShowToast);
        }

        #endregion

        #region Methods

        public override void Navigated (NavigatedParameter parameter)
        {
            if (parameter.Sender is CollectionViewModel) 
            {
                this.ToastPresenter.Show("You are choosing: " + (parameter.Sender as CollectionViewModel).SelectedItem.Title);
            }
        }

        private void ShowToast(object parameter)
        {
            this.ToastPresenter.Show("You entered: " + this.NewText);
            this.GreetingText = this.NewText;
        }

        #endregion
    }
}

The menu that user chooses will be represented by SelectedItem and there are two things to note here: SelectedItem actually obtained from the sender ViewModel which is from CollectionViewModel.cs and SelectedItem actually the default property provided from CollectionViewModel implementing the ListViewModelBase. In this case, we will show a toast presenter to indicate which menu the user has chosen, by obtaining the Title of SelectedItem and show it using Toast Presenter.

Also, If you put a breakpoint in the highlighted line above and inspect the NavigatedParameter, you can see from the shot below that it holds lots of information not only the SelectedItem but the whole CollectionViewModel.

You will use this neat trick to accomplish a lot of cool things using Crosslight, so don’t forget to save this favourite this blog for later uses. Okay, now let’s run our project!

Wait… should we also change the Android and iOS? No need at all using Crosslight you only need to change it in Core and it will be applied to each platform, very convenient! Here is the result:

Wrapping Up

With Crosslight, you will never have to worry about the code behind the scene. However, in  this session, I want to emphasize the customizability of Crosslight, using minimal effort and codes we already successfully create a simple and gorgeous navigation menu. I believe the next steps for you is to discover more about Crosslight features and we still have more tutorials coming in the futures! So stay tuned with us and have fun!

You can find the source code for this post here: http://git.intersoftsolutions.com/projects/CT/repos/crosslightcollectionview/browse

See you in the next post,
Arief Handany

Since you’ve managed to get started with Crosslight Form Builder, let’s move on a bit to see how we can extend the capabilities of the Crosslight Form Builder beyond its original capabilities. In this post we’re going to learn how to add an option to choose the driver in CrosslightFormBuilder sample, as well as showing a custom view with the driver’s photo in the form, with the driver’s phone number, which when tapped, will initiate a call to the driver.

There are two major enhancements to be done:

• Providing driver selection
• Providing custom driver view

Providing Driver Selection

Let’s try to create the Driver selection. At a quick overview, here’s a list of subtasks to be done in order to achieve this functionality:

• Prepare the Driver model
• Prepare the Driver Repository that populates the list of drivers.
• Prepare the DriverListViewModel that populates the items from the repository.
• Update the Form Metadata and connect the DriverListViewModel.

Let’s go through each one, step-by-step.

Prepare the Driver model

To create the Driver model, let’s create a new file named Driver.cs under CrosslightFormBuilder.Core/Models folder. The contents are as follows.

#region Usings

using CrosslightFormBuilder.Models;

#endregion

namespace CrosslightFormBuilder.Core.Models
{
    public class Driver : ModelBase
    {
        #region Constructors

        public Driver(int id, string name, string phone, byte[] image)
        {
            this.Id = id;
            this.Name = name;
            this.Phone = phone;
            this.Image = image;
        }

        #endregion

        #region Fields

        private int _id;
        private byte[] _image;
        private string _name;
        private string _phone;

        #endregion

        #region Properties

        public int Id
        {
            get { return _id; }
            set
            {
                if (_id != value)
                {
                    _id = value;
                    OnPropertyChanged("Id");
                }
            }
        }

        public byte[] Image
        {
            get { return _image; }
            set
            {
                if (_image != value)
                {
                    _image = value;
                    OnPropertyChanged("Image");
                }
            }
        }

        public string Name
        {
            get { return _name; }
            set
            {
                if (_name != value)
                {
                    _name = value;
                    OnPropertyChanged("Name");
                }
            }
        }

        public string Phone
        {
            get { return _phone; }
            set
            {
                if (_phone != value)
                {
                    _phone = value;
                    OnPropertyChanged("Phone");
                }
            }
        }

        #endregion
    }
}

The Driver model contain 4 MVVM-ready properties: ID (int), Image (byte[]), Name (string), and Phone (string). That’s basically it. I’ve also prepared a constructor for quick and easy initialization. Now your Driver model is ready. Let’s move on.

Prepare the Driver Repository

Upon reading the heading, you might have two questions: What is this repository thingy and why do I need it? The repository pattern is more of a best-practice design pattern that handles the actual data processing for your applications. A data repository for your app.

For example, right now your app might currently retrieve data by performing queries to a database server, then one day you decided to change the data retrieval process. Rather than making changes to each and every ViewModel, you can do so by just replacing the data repository. No changes in ViewModel needed. To learn more about the Repository Pattern, check out our Developer Center documentation here.

So, let’s get started in creating our Driver repository. First thing you need to do is define the interfaces needed for the repository. Create a new interface in CrosslightFormBuilder.Core/ModelServices, named IDataRepository.cs, also creating the folder as necessary. The contents of the file are as follows.

public interface IDataRepository<TEntity, in TKey> where TEntity : class
{
    #region Methods

    TEntity Get(TKey id);
    IEnumerable<TEntity> GetAll();

    #endregion
}

We’ll prepare an interface to get the Driver entity based on the given ID. Notice that everything is defined as generic here. Also another interface to return all entities when calling GetAll() method.

Proceed by creating the interface for the Driver repository in CrosslightFormBuilder.Core/ModelServices folder, named IDriverRepository.cs, also creating the folder as necessary.

public interface IDriverRepository : IDataRepository<Driver, int>
{
    #region Methods

    Driver GetByName(string name);

    #endregion
}

There’s nothing much to see here, we simply added a new method to get the Driver entity by the driver’s Name by subclassing the previously created IDataRepository interface. Let’s move on by creating the concrete DriverRepository implementation. Create a new file called DriverRepository.cs inside CrosslightFormBuilder.Core/ModelServices folder.

public class DriverRepository : IDriverRepository
{
    #region Properties

    public List<Driver> _items { get; set; }

    #endregion

    #region Methods

    public Driver Get(int id)
    {
        return this.GetAll().FirstOrDefault(o => o.Id == id);
    }

    public IEnumerable<Driver> GetAll()
    {
        if (_items == null)
        {
            _items = new List<Driver>();
            _items.Add(new Driver(1, "John", "+123456", this.GetType().Assembly.GetManifestResourceStream("CrosslightFormBuilder.Core.Assets.john.png").ToByte()));
            _items.Add(new Driver(2, "Brad", "+134567", this.GetType().Assembly.GetManifestResourceStream("CrosslightFormBuilder.Core.Assets.brad.png").ToByte()));
            _items.Add(new Driver(2, "Charles", "+145678", this.GetType().Assembly.GetManifestResourceStream("CrosslightFormBuilder.Core.Assets.charles.png").ToByte()));
        }

        return _items;
    }

    public Driver GetByName(string name)
    {
        return this.GetAll().FirstOrDefault(o => o.Name == name);
    }

    #endregion
}

Here, you can then provide the real implementation to retrieve the list of drivers, also getting the drivers by name and ID. The highlighted line shows how the list of Drivers are populated, by utilizing the constructor we’ve provided for our Driver model earlier. Also notice that we’ve provided the image to be used for each driver. Oh yeah, before we forget, let’s go ahead and use these images for the drivers and put it inside the CrosslightFormBuilder.Core/Assets folder, also creating the folder as needed.

Make sure that these images’ BuildAction is set to EmbeddedResource so that they can be used in your application. Also, if you try to build the project now, you might get an error on the ToByte() method. To fix this, create a new file that contains an extension method to convert a Stream to array of bytes. Create a file named StreamExtensions.cs, and put it inside the CrosslightFormBuilder.Core/Extensions folder.

public static class StreamExtensions
{
    #region Methods

    public static byte[] ToByte(this Stream input)
    {
        using (MemoryStream ms = new MemoryStream())
        {
            input.CopyTo(ms);
            return ms.ToArray();
        }
    }

    #endregion
}

A handy tip for you: these extension method provides an easy way to extend the functionalities of a certain class, that is reusable within your application. For example, if you wish to create an extension, for let’s say, converting a string to a byte[], you can definitely do something similar to this.

Now that you’ve the got the repository part ready, let’s hook it up to the ViewModel.

Prepare the DriverListViewModel

Start by creating a new ViewModel file called DriverListViewModel.cs and put it inside CrosslightFormBuilder.Core/ViewModels folder. Here’s the contents of the file.

public class DriverListViewModel : ListViewModelBase<Driver>
{
    #region Constructors

    public DriverListViewModel()
    {
        this.SourceItems = this.Repository.GetAll().ToObservable();
    }

    #endregion

    #region Properties

    private IDriverRepository Repository
    {
        get
        {
            if (Container.Current.CanResolve<IDriverRepository>())
                return Container.Current.Resolve<IDriverRepository>();
            return new DriverRepository();
        }
    }

    #endregion
}

Here, we populate the SourceItems when the DriverListViewModel is constructed, just by calling the previously created GetAll() method from our interface. Also notice that we’ve provided the Repository property which is resolved upon the property’s getter. This is also called as IoC (Inversion of Control). To use the IoC pattern, you’ll need to register the previously created DriverRepository to be used globally in the application. To do this, open up the AppService.cs file in the CrosslightFormBuilder.Core/Infrastructure folder and add this line in the constructor.

public CrosslightAppAppService(IApplicationContext context) : base(context)
{
    Container.Current.Register<IDriverRepository, DriverRepository>().WithLifetimeManager(new ContainerLifetime());
}

Your ViewModel is now ready to be used to populate the list of Drivers.

Update the FormMetadata

Since you already have the list of drivers properly populated from the DriverListViewModel, we’ll need to modify the OrderFormMetadata a bit. From the initial OrderFormMetadata class in the Order.cs file, let’s modify the TaxiChoiceSection class to include the driver selection.

public class TaxiChoiceSection
{
    #region Fields

    [Display(Caption = "Car Type")]
    [Editor(EditorType.AutoDetect)]
    [Layout(Style = LayoutStyle.RightDetail)]
    public CarType CarType;

    [Editor(EditorType.Selection)]
    [SelectedItemBinding(Path = "Driver")]
    [Binding(Path = "Driver.Name")]
    [SelectionInput(SelectionMode.Single, DisplayMemberPath = "Name", ListSourceType = typeof(DriverListViewModel))]
    public Driver Driver;

    [Display(Caption = "Airport?")]
    [Editor(EditorType.Switch)]
    [Layout(Style = LayoutStyle.RightDetail)]
    public bool IsAirport;

    #endregion
}

The highlighted lines above shows the added definition for the driver selection. Let’s inspect this line by line.

• [Editor(EditorType.Selection)]
  This determines which editor type to be used.
  
• [SelectedItemBinding(Path = “Driver”)]
  This attribute determines which binding path for the selected item used in the Form Builder. In this case, the item for the Form Builder is of type Order, which has the Driver property. That’s where we’re going to bind our selection into. (OrderViewModel.Item.Driver)
• [Binding(Path = “Driver.Name”)]
  The BindingAttribute determines which property of the Driver model that is going to be displayed in the form after selection has completed.
  
• [SelectionInput(SelectionMode.Single, DisplayMemberPath = “Name”, ListSourceType = typeof(DriverListViewModel))]
  The SelectionInputAttribute determines the selection editor behavior, which ViewModel provides the items source for the list, as well as the property to be displayed on the list of selection, or also often known as DisplayMemberPath.
  

By now, you’ve successfully provided a driver selection for the Form Builder. How about adding the custom view on the bottom of the form?

Providing Custom Driver View

After the user has selected the driver, it’s best for us to show the driver that the user has selected by providing a custom view at the bottom of the form. Let’s learn how you can use a custom view resource to be used along with the Form Builder, complete with data binding capabilities. In overall, there are several steps needed to achieve this:

• Provide the custom driver view for iOS
• Update the Form Metadata
• Provide the Binding Provider
• Bind to ViewModel
• Provide the custom driver view for Android

Let’s go through each step, one-by-one.

Provide the Custom Driver View for iOS

To provide the custom driver view for iOS, all you need to do is creating a new Crosslight view for iPhone. To do this, you can utilize the item template shipped with Crosslight. In your iOS project, in the Views folder, right-click and add a new file. Under Crosslight, choose Crosslight iOS View for iPhone.

Let’s give it a name of CallDriverButton. What this will do is Crosslight will create two files, namely CallDriverButton.xib and CallDriverButton.cs. All you need to do is create a new layout by opening the CallDriverButton.xib in Xcode Interface Builder.

Create your layout any way you want it. Just create an ImageView, a Label, and a Button.

Set the outlet for each.

• ImageView: DriverImage
• Label: DriverName
• Button: CallButton

I know, my layout looks awful. But all I really want to show you is how you can inject your own custom views into the form using the Form Builder. So, after your layout’s done, save it and go back to Xamarin Studio.

Update the Form Metadata

Now that your layout is done, let’s update our OrderFormMetadata a bit to include this new view in our form layout. Open up Order.cs, and let’s create a new section and call it CallDriverSection, or anything you want.

public class CallDriverSection
{
    [Editor(EditorType.Custom, CustomEditorIdentifier = "CallDriverButton")]
    public object CallDriver;
}

Now I’d like you to pay attention how easy it is to embed a custom view into a Crosslight Form. From the definition above, you can see that we simply set the editor type to custom, then set the CustomEditorIdentifier set to CallDriverButton. In iOS, this corresponds to the name of the XIB that we’ve defined for our custom view. While on Android, this also corresponds to the name of the Android Layout file we’ve defined for our custom view layout. Simple as that.

We’ve made it super easy for developers to create a beautiful platform-specific data form by combining robust pre-built editors for common input and flexible custom views for more complex user interface. This allows you to mix and match what works best for you, and let Crosslight do the magic at runtime.

After you’ve created this section, let’s add this at the bottom of our form.

[Form(Title = "Order Form")]
public class OrderFormMetadata
{
    #region Fields

    [Section(Header = "Passenger Details")]
    public PassengerDetailsSection PassengerDetails;

    [Section(Header = "Taxi Choice")]
    public TaxiChoiceSection TaxiChoiceSection;

    [Section]
    public CallDriverSection CallDriverSection;

    #endregion
}

You’re done with the form metadata. But there’s something missing. What about those outlets we’ve defined earlier? How can we bind data to it?

Provide the Binding Provider

Simple. It’s basically the way you would do any data binding with Crosslight. Yes, you should provide a BindingProvider for the form. In addition to automatic bindings, Form Builder also supports natural data binding process through the use of BindingProvider. In this case, let’s create a new BindingProvider called OrderBindingProvider.cs. Let’s put this under CrosslightFormBuilder.Core/BindingProviders folder. The contents of the OrderBindingProvider are as follows.

public class OrderBindingProvider : BindingProvider
{
    #region Constructors

    public OrderBindingProvider()
    {
        this.AddBinding("DriverImage", BindableProperties.ImageProperty, "Item.Driver.Image");
        this.AddBinding("DriverName", BindableProperties.TextProperty, "Item.Driver.Name");
        this.AddBinding("CallButton", BindableProperties.TextProperty, "Item.Driver.Phone");
        this.AddBinding("CallButton", BindableProperties.CommandProperty, "CallCommand");
    }

    #endregion
}

Here, we’ve simply used the outlets we’ve defined earlier and bind them automatically to the selected Driver in the form. We’ve also added a binding from the CallButton to the CallCommand in the ViewModel, which can be used to call the driver immediately upon click. And don’t forget to use the newly created OrderBindingProvider in your OrderViewController.

Again, Crosslight does a lot of magic behind the scene which enables you to define data binding in such a simple definition. Looking back, we just need to create a view, define the outlets, and provide the bindings. Crosslight takes care the connection between all those layers at runtime.

[Register("OrderViewController")]
[ImportBinding(typeof(OrderBindingProvider))]
public class OrderViewController : UIFormViewController<OrderViewModel>
{
    ...
}

Bind to ViewModel

Afterwards, in the OrderViewModel, we simply add a new DelegateCommand for the phone number.

public class OrderViewModel : EditorViewModelBase<Order>
{
    #region Properties

    /// <summary>
    /// Gets the type of the form metadata associated to the editor.
    /// </summary>
    /// <value>
    /// The type of the form metadata.
    /// </value>
    public override Type FormMetadataType
    {
        get { return typeof(OrderFormMetadata); }
    }
    
    public DelegateCommand CallCommand { get; set; }

    #endregion
    
    #region Constructors
    
    public OrderViewModel()
    {
        this.CallCommand = new DelegateCommand(ExecuteCall);
    }
    
    #endregion

    #region Methods
    
    private void ExecuteCall(object obj)
    {
        this.MobileService.Telephony.Call(this.Item.Driver.Phone);
    }

    /// <summary>
    /// Executes the save command.
    /// </summary>
    /// <param name="parameter">Parameter.</param>
    protected override void ExecuteSave(object parameter)
    {
        this.Validate();

        if (!this.HasErrors)
        {
            StringBuilder passengerDetails = new StringBuilder();
            passengerDetails.Append("Name: " + this.Item.Name + "\n");
            passengerDetails.Append("Pickup Time: " + this.Item.PickupTime + "\n");
            passengerDetails.Append("Going to the airport? " + this.Item.IsAirport + "\n");
            passengerDetails.Append("Car Type: " + this.Item.CarType + "\n");
            passengerDetails.Append("Driver: " + this.Item.Driver.Name);

            this.MessagePresenter.Show(passengerDetails.ToString(), "Confirm Order", new[] {"Yes", "No"}, selection =>
            {
                if (selection == 0) //Yes
                {
                    this.ToastPresenter.Show("Your order has been placed.");
                }
                else
                {
                    this.ToastPresenter.Show("You cancelled the order.");
                }
            });
        }
        else
        {
            this.MessagePresenter.Show(this.ErrorMessage);
        }

    }
    

    /// <summary>
    /// Called when this instance is navigated.
    /// </summary>
    /// <param name="parameter">Parameter.</param>
    public override void Navigated(NavigatedParameter parameter)
    {
        base.Navigated(parameter);

        this.Item = new Order();
        this.Item.PickupTime = DateTime.Now;
    }

    #endregion
}

Everything seems pretty much the same, except for the additional CallCommand we’ve defined for the CallButton. Run the project and you should now see iOS version is now working properly. Try selecting a driver and that driver detail will be automatically shown in the custom view you’ve defined. When you run this on an iPhone, you can even immediately perform a phone call to the driver’s number directly.

What about Android?

Provide the Custom Driver View for Android

This is where the Form Builder excels. Since you’ve completed the iOS version, all you need to do is just provide the custom layout and use the previously created OrderBindingProvider. Let’s take a look how to achieve this.

First, create a new Android Layout file by right clicking on the CrosslightFormBuilder.Android/Resources/layout folder. Then choose Add, New Item. Select Android, Layout. Remember to give it a name of CallDriverButton, as this corresponds to the CustomViewIdentifier defined in the FormMetadata earlier.

Provide the layout as follows.

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="wrap_content">
    <LinearLayout
        android:orientation="vertical"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content">
        <ImageView
            android:id="@+id/DriverImage"
            android:layout_width="200dp"
            android:layout_height="200dp"
            android:layout_gravity="center" />
        <TextView
            android:id="@+id/DriverName"
            android:layout_width="wrap_content"
            android:layout_height="20sp"
            android:layout_gravity="center" />
        <Button
            android:id="@+id/CallButton"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_gravity="center" />
    </LinearLayout>
</RelativeLayout>

After ensuring the IDs are correct, you’re only left to hook up the OrderBindingProvider in your OrderActivity. Let’s do that now.

[Activity(Label = "Order Form")]
[ImportBinding(typeof(OrderBindingProvider))]
public class OrderActivity : FormActivity<OrderViewModel>
{
    ...
}

You’re done. Run the project and you’ll get the same result with iOS version.

Beautiful, isn’t it?

Wrapping Up

The entire project for this tutorial can be found here. To use this sample, you’ll need to use at least Crosslight 4.0.5000.321 and above. Hopefully this will help you learn more about the Crosslight Form Builder.

You’ve seen how you can easily inject a custom view to the form by using the ViewResource custom editor. Probably some time in the future I’ll add a custom ViewBuilder tutorial as well. This will be very useful for those of you who wants to build a custom control that works seamlessly with the FormBuilder. We’ve also used this approach in building Crosslight Form Builder for each platform inside Crosslight framework.

Cheers,
Nicholas Lie

We are truly excited to announce that the ultimate cross-platform development toolset now sports even more features and stability updates. This new service pack update includes a new localizable business template, over 50+ item templates for Visual Studio, dynamic localization service, new template definitions for iOS, major stability updates for Android, support for application-wide single sign-on, and much more.

The Crosslight Project Wizard now includes an additional and noteworthy template, which is the localizable business template. The new localizable business template allows you to change the language of the application dynamically at runtime, thanks to the dynamic localization service. If automatic language is set, when the device’s language is set to the one supported by the application, then the language changes automatically. However, you can also force an application to use a specific language of your choice, regardless of the language setting used by the device. The following screenshots show the improved Crosslight Project Wizard and the running app respectively.

We have also shipped more than 50 templates for Visual Studio, ranging for variety of projects, this includes, Android, iOS, Windows Phone, and shared Core project. The templates itself is clear and concise, with instructions inside each template on how to use it. Your development process will be significantly accelerated since you can now quickly add common Crosslight items to your project. Say goodbye to the tedious, error-prone copy and paste.

In addition, Crosslight for Android platform has received major stability improvements, including the support of Xamarin.Android.Support.v4 library, revamped overall lifecycle, elegant rotation handling to ensure that view state is restored without performance degradation, improved tab caching, and reliability of the Android services, such as camera service, location service, social services, and more.

So far, we’ve only touched the surface of what’s revamped in this SP1 release. For a complete list of the updates, make sure you check out the Crosslight 2.3 release notes in our Developer Center page.

All the installers on our site have also been updated to reflect the new bits. Of course, this update is free of charge for customers with existing subscription for Mobile Studio or Premier Studio. Click here to sign in and access your downloads. If you haven’t tried Crosslight today, request a trial now and see how Crosslight transform the way you build cross-platform apps entirely.

Last but not last, we hope you enjoy Crosslight as much as we love building it! Stay tuned for our upcoming video tutorials and hands-on guide to apply these exciting features in your apps!

Cheers,
Nicholas Lie

Since the inception of Crosslight last year, we have seen a number of approaches which attempt to address cross-platform development, particularly on the native mobile platforms. We have received frequently asked questions regarding the best practices for cross-platform mobile development, and what would be the ideal solution for building cross-platform apps that are highly flexible, maintainable and extensible. Since then, we have helped a lot of our customers understanding the design patterns which allow them to better architect their solutions. In this blog post, I will share some insights based on our past successful experiences.

There are various approaches in designing cross-platform solution depending on the development goals. At the simplest, you can come up with basic code sharing solution without applying design pattern, i.e., through file linking to each platform-specific project. However, that will be definitely less-than-ideal and is not recommended. In this blog post, I’ll be focusing on approaches with applied design pattern such as unified view abstraction pattern and ViewModel pattern.

Unified View Abstraction Pattern

This design pattern comes from the idea that the user-interface element (View) in each platform can be unified into a single intermediate API that reside in the shared project. The intermediate View API represents only the abstraction of the View, while the actual implementation is done at each platform behind the scene. The unification of the View seems interesting and promising at a glance, but it actually exposes more problems than the gained benefits.

One of the biggest problems is that view abstraction pattern makes sense only if the user interaction logic is defined within the View implementation itself. The nature of this pattern commonly disregards the separation of concern (SoC) between the user interaction logic and the view implementation — which is very similar to outdated patterns such as WinForms. This means that your application and user interaction logic will be “tightly coupled” to the view.

To help you understand it better, see the following code snippet which shows an example of a View implemented with this pattern.

public class ItemDetailPage : DetailPage
{
    public ItemDetailPage()
    {
	public MainPage ()
	{
 	    var panel = new Panel();
	    var label = new Label();
	    var button = Button() { Text = “Click me!” };

	    button.Clicked += (sender, e) => 
		{
		    label.Text = “Button clicked”;
   		};

	    panel.Children.Add(label);
	    panel.Children.Add(button);
			
	    Page = panel;
	}
    }
}

As seen in the code above, the application and user interaction logic are tightly coupled to the view definition, mostly through event handlers. With such design, we can quickly identify some of the major limitations and design issues such as:

• Limited UI Definitions — the impact of the design creates limitation in which only the lowest common denominations of the features across platforms are supported. It’s obvious that you cannot easily leverage the feature available only in certain platform.
• Poor Maintainability — the code is hard to maintain and extend since logics are coupled to the view.
• Not Testable — Functional layer cannot be unit tested since the implementation requires event initiated from the actual user interface elements.
• Not Designable — View definition must be done with hand-coding to comply with the intermediate View API. There are typically no designer support for such view abstraction.
• Not Scalable — As view is defined through code, all works are done by developers, including both coding and implementing the design. You cannot have a design team specialized in implementing the iOS screen, while another separate team implementing Android screen.
• Low Adaptability — Changing views will often breaking functionality since the application logic is coupled to the view. As the results, modifying views can be tedious, complex, and commonly break the existing code, for instance, consider changing a list view into a collection view.

It is tempting to think that you can also create Model and ViewModel layers to use in conjunction with the unified view pattern. However, doing so brings us back to zero degree. Applying the view abstraction pattern will be pointless when you find yourself needing to create extra layers. So it’s an one-off approach — you can choose to apply the unified view pattern with the imposed limitations and design drawbacks, or choose the ViewModel pattern that emphasize on strong separation of concerns principle.

That said, the view abstraction pattern is actually one that we avoided at best since the first day we laid out our apps infrastructure and components design. Our architect team never consider this approach as a feasible solution due to the limitations and issues it brought. Unless you are implementing super simple apps that do not concern on code’s maintainability, testability and extensibility; you should avoid building cross-platform apps with this pattern.

ViewModel (MVVM) Pattern Comes to Rescue

An ideal cross-platform development based on our years of experience in building cross-platform apps and tools is to adapt the SOLID principle in our design pattern. The principles suggest the architectural pattern to be designed in ways that produce the following results:

• Low coupling between layers, high cohesion within them.
• Separation of concerns, user interaction logic and view should be implemented in separate layers, resulting in greater code maintainability, testability, extensibility and scalability.
• User interface (View) layer should contain no business or interaction logic, enabling changes or modification to the views without affecting user interaction logic.
• Business/application logic layer contains no user interface (view) and don’t refer to any of the view layers.

It is imperative to conform to these principles if your goal is to create great cross-platform apps that are highly scalable, maintainable, and can be easily scaled at times.

One of the popular design patterns today called Model-View-ViewModel (MVVM) allows you to achieve most of the principles described above. By nature, MVVM separates the user interaction logic out from the view layer, but still cohesive within them through the use of two-way data binding. This enables you to easily implement the user interaction logic in a separate layer called ViewModel — without concerning the views. Likewise, you can flexibly design the views without concerning or fearing to break the functional logic. This makes MVVM pattern one of the most appealing solutions for cross-platform development.

The following diagram illustrates a typical architecture implementation with MVVM design pattern.

The only issue with this pattern is that you require a seriously solid MVVM framework and tools that are built with the MVVM pattern. This includes the frameworks for the ViewModels, dependency delegation, event aggregators, commands, as well as View components that support data binding and the ViewModel paradigm.

Well, the good news is that we’ve got you covered. Read on.

Cross Platform Mobile Development Done Right

By now, you should already have insights what’s the most ideal solution for building cross-platform apps. Applying a design pattern is required to build highly successful one, and choosing the right design pattern is crucial in determining the future of the apps.

When our team engineered Crosslight last year, we decided to build it on a solid design pattern — one that can serve as a foundation for mission critical apps. We chosen MVVM, not only because it’s real good, but because we have great success in building cross-platform tools with it. And more importantly, we’ve helped countless of enterprise customers building highly successful apps with this pattern. We’ve experienced it, and seen how development team get real results — clear responsibility, improved productivity and accelerated development speed.

Instead of unifying the heterogenous views across different platforms into a single API, Crosslight lets you build cross-platform mobile apps in the most natural way possible. You write the user interaction logic code entirely in ViewModel, while freely designing the view in each IDE of the platform. The view doesn’t contain any UI logic, so the designer team is free to unleash their creativity to build great user experiences that matter on each platform. It’s the best of three worlds — developers, designers, and users.

The following illustrations show how a Crosslight view is designed in iOS and Android respectively:

As seen in the above screenshots above, you can easily design the view and layout to your liking – all within your favorite IDE. More importantly, you can access all the properties and modify them conveniently in a flick of finger. In contrast, accessing platform-specific properties is something you’re limited to do with unified view abstraction pattern.

The comprehensive data binding support in Crosslight means that you are free to use any existing controls available in your toolbox, arrange and size them the way you want, and set the behaviors and appearance settings the way you desire. As long as the ID matches the binding definition, everything will work beautifully at runtime. No new API to learn. No code required for implementing design. It just works.

With MVVM, Crosslight offers great benefits not available in other solutions such as:

• Targets multiple platforms at once (efficiency)
• High code reusability (maintainability)
• Great native user experiences (usability)
• High extensibility (customizability)
• Loosely-coupled components (testability, scalability)

To learn more about Crosslight architecture and how it applies the MVVM design pattern, see Understanding Crosslight Architecture.

To see Crosslight in action with the supported MVVM capabilities, download the MVVM Samples here.

Fostering Innovative Design, Yet Sharing Single Codebase

While building cross-platform apps, you want to reuse as much code as possible, from the domain models, data access layer, to the application and user interface logic. Yep, we got that! Crosslight allows you to share 100% of these code base, thanks to the solid architecture. And even better, you don’t have to sacrifice the design and user experiences of each platform. Building apps with great user experiences is arguably the most important aspect particularly in native mobile platforms.

One of the features that our developers love the most is the ability to instantly change the user interface elements (view) without breaking any of the existing business and interaction logic. In short, you can have a single ViewModel and have it presented in various type of views. That’s just one of the many benefits of using MVVM pattern.

For example, consider you have a list of items displayed with a table view on the phone. Later, you realized that it doesn’t look so good in the tablet and wish to change it to a collection view. You can easily achieve such scenarios with Crosslight since it embraces the MVVM design pattern. Thinking to use unified view abstraction to achieve this simple goal? Good luck with that : )

The following illustration shows the list view on the iPhone and collection view on the iPad — all done in a single ViewModel.

As seen in the above illustrations, creating great experiences that are unique for each platform and even for each device kind becomes so straightforward and manageable, thanks to the MVVM pattern which emphasizes clear separation of concerns. More than just static user interface elements, Crosslight ships dozens of UI components that are optimized with native user experiences – such as the one shown in iPad screenshot above.

You can download the Inventory samples here and try it for yourself. Seeing is believing.

Wrapping Up

So far, I have only scratched the surface of the benefits of MVVM design pattern, and how Crosslight is built to leverage it to the fullest. Notably, applying a solid design pattern is crucial in apps development, particularly if you are targeting cross-platform. Hopefully this post gives you inspirations and better insights in understanding design patterns for cross- platform development.

You can quickly get started and learn more from the Crosslight Developer Center. In the next blog, I will discuss more UI goodness included in Crosslight, which features to use for particular scenarios, and how you can use them together to build great apps experiences.

Best,
Jimmy

It’s just a few weeks ago that we released Premier Studio 2013, our best release ever. Today, we’re pleased to announce our first update to Crosslight, our flagship cross-platform native mobile development tools. In case you missed the news, the 2013 release delivers a wide-range of exciting new tools across current lineups such as ASP.NET, Silverlight, and WPF – as well as the expansion to new mobile platforms including iOS, Android, Windows Phone 8 and Windows 8. Check out the complete details here.

In this update, Crosslight adds full support for iOS 7, Apple’s latest mobile operating system. Unlike HTML-based mobile tools, Crosslight adheres to the strict iOS 7 user experience and design guidelines which includes upgrade to the beautiful look and feel, tint color, translucency, ultra-smooth animation, and much more. In this blog post, I’d like to share the new enhancements and changes specifically for iOS 7 that we’ve made in this update.

Gorgeous Form Editor. Redesigned for iOS 7.

Apple’s latest iOS 7 is the most significant overhaul since its first inception which delivers dramatic changes to the user interface and user experience aspects in addition to many other new features. One of the biggest changes is the introduction of translucent and motion to create beautiful interface with sense of depth in favor to heavier, real-life illustration design. If you’re a UI/UX designer, like us, this means it’s time to upgrade your design skillset and rework your iOS mobile apps.

The iOS 7’s new interface design is so interesting in how it makes minimal design looks not only great – but done right and well balanced. With translucent, hair-line precise rendering, yet incredibly stunning visual effects, iOS 7 redefines the experiences of modern apps. The first in the industry, the entire user interface components in Crosslight are now upgraded to adhere to the iOS modern experience, including the form builder, navigation controls and nearly 20+ editing controls. See the following illustration for details.

As seen in the above visual, Crosslight’s Form Builder now leverages the new design elements and guidelines introduced in iOS 7. This includes improvements to the composite layout which sports minimal design and fluid entry layout similar to the Contacts app.

It also introduces a gorgeous circular photo mask which you can easily enable with a property set, and revamped picker components presentation which show the picker inline to the form field in favor to the modal view. The inline picker presentation is proven to be more intuitive than the modal view as users can conveniently select an item and scroll without dismissing the selection. In addition, when users opened another picker, the previous displayed picker will be smoothly hidden with transition – delivering elegant user experiences similar to the built-in Calendar app.

Every Detail. Meticulously Considered.

Apple’s revamped interface design in iOS 7 is thoughtfully-designed in every little detail. As the leading component provider for Apple’s platforms, we leverage the new visual changes in every detail too. In only a week timeframe, we redesigned every UI component, pixel-by-pixel, to match the new design principles and guidelines introduced in iOS 7. For instances, the form builder design that produced for the smaller screen such as iPhone – should look great not only in the iPhone, but in the iPad as well, in either modal view or popover view, in either portrait or landscape orientation – and in any scenarios you could think of.

The new update also adds new color tint support to help you easily branding your app’s design. By easily setting the new TintColor property of the application delegate, the buttons, icons, and other tint-aware visual indicators will reflect the specified tint color. This applies to the new date time editor in the form builder as well.

The sample code below shows how easy it is to take advantage the tint color in your iOS apps.

[Register("AppDelegate")]
public partial class AppDelegate : IntersoftCore.UIApplicationDelegate
{
	protected override UIViewController WrapRootViewController(UIViewController contentViewController)
	{
		if (contentViewController is UISplitViewController || contentViewController is UITabBarController)
			return contentViewController;

		return new UINavigationController(contentViewController);
	}

        public override UIColor TintColor
        {
            get
            {
                return UIColor.Red;
            }
        }
}

Furthermore, a new useful feature is added to allow automatic hiding of the keyboard as users drag the screen – similar to the behavior in the iOS 7’s revamped calendar app. You can easily enable this feature by setting the HideKeyboardOnScroll property.

Both iOS 6 and iOS 7. Supported in a Single Assembly.

Crosslight sets a rock-solid foundation for cross-platform native mobile development which enables you to write user interaction logic elegantly in the ViewModel. And now, with the iOS 7 officially supported, you can easily upgrade your Crosslight-powered iOS apps to take advantage of iOS 7 features in just a simple few steps such as assembly update and rebuild – without any changes to your application codebase. And that’s a priceless benefit.

It’s important to note that the new iOS 7 support is added to Crosslight without affecting the features and user interface design that target iOS 6. In the case you want to selectively enable the iOS 7 features, you can do it in the view controller by conditionally customizing the form builder attributes at runtime. See the example code below.

public partial class ItemEditViewController : UIFormViewController<ItemEditorViewModel>
{
        protected override void InitializeView()
        {
            base.InitializeView();

            // customize form metadata
            var thumbnailImage = this.Form.GetProperty("ThumbnailImage");
            var imageAttribute = thumbnailImage.GetAttribute<ImageAttribute>();

            if (this.IsOS7())
            {
                imageAttribute.UseCircleMask = true;
            }
        }
}

To learn more about Crosslight, its key features and advantages, please visit the Crosslight home page.

In addition to iOS 7 support, the latest Crosslight update also includes enhancements and stability improvements to the Android and Windows platforms. The navigation transition for the Windows Phone 8 and Windows 8 have been much improved to resemble the default platform’s experiences. For more details, please refer to Crosslight Version History.

Along with the announcement, we’ve also updated the Mobile Studio installer for both Mac and Windows. You can sign-in to your account to download the updated installer, or request a trial here. Feel free to ask any questions or drop your feedback in the comments box below.

Best,
Jimmy

The Inventory Tracker sample shipped with Intersoft Mobile Studio is a great reference sample that simulates the real-world condition of how a basic, yet still providing a great user experience app should be. The Inventory Tracker is designed for workers that in a warehouse who want to track the items they have in store. The sample provides intuitive CRUD operation that extends beyond common applications with CRUD functionality. Some details are meticulously considered and thoughtfully designed to provide the user with a great form input experience, when usually form inputs have an impression of being a boring chore.

This blog post aims to elaborate the details that made this reference sample app different from other app with form inputs in the market, while exposing the features of form builder built into Crosslight framework. By just defining one form metadata, you can rest assured that the forms you create in one platform will easily work in another and provide a great and consistent user experience.

Supports Multiple Platforms

The Inventory Tracker sample runs on a shared application logic, and runs great on iOS, Android, WIndows Phone and WinRT, while conforming to each platform UI guidelines. The sample does not enforce the same design throughout different platforms, this is because different platforms have different design guidelines and if you try to imitate one platform’s experience with another, this would greatly crimp the user experience.

Automatic Rotation Handling

The Inventory Tracker responds fluidly to orientation changes, while keeping the bindings intact. Take Android for example, by standard measures, you would have to eventually store the values entered by the user back and forth yourself every time the Activity is recreated after rotation. Handling this scenario will definitely take a lot of your precious development time. Crosslight has taken care of this from the back-end, so you can rest assure that your data integrity is maintained even after countless orientation changes and the bindings will remain intact.

Master-Detail Navigation

The user experience when using a tablet must differ, as you have more screen estate to utilize. In a tablet, you would probably want to split the screen into two parts, a smaller left portion for the items list and the rest of the screen for the detail view. The Inventory Tracker executes this scenario beautifully by adapting itself to tablet devices, using a single codebase. Try to deploy the sample on a tablet device or emulator and see for yourself. More importantly, Crosslight ships with this template by default, so you can easily create such experience with greater ease.

Powerful Data Bindings

By default, when you are either in add new item screen or editing an item screen, the bindings are set two-way by default. This allows hassle-free editing of items, and the changes made truly reflects the underlying model of the item. The add item command and the save item command are also bound to the button using the robust data binding feature introduced by the form builder of the Crosslight framework.

Versatile Visibility Bindings

When adding new items using the form metadata, you can hide a specific section using the visibility binding attribute. The item form metadata has a specific SoldSection that can be hidden during addition of new item, since it would be counter-intuitive if you add a new item then immediately mark that item as sold.

In the editing item screen, when the IsSold switch is turned on, the Sold Date property immediately responds by making the sold date editor to visible, on the other hand, when the IsSold switch is turned off, the sold date editor is hidden from the view. This is possible because of the solid MVVM binding framework introduced in Crosslight.

public class SoldSection
{
	[Editor(EditorType.Switch)]
	[Display(Caption = "Is Sold")]
	public static bool IsSold;

	[Display(Caption = "Sold Date")]
	[Editor(EditorType.Date)]
	[VisibilityBinding(Path = "IsSold")]
	[Binding(StringFormat = "{0:d}")]
	public static DateTime SoldDate;
}

Batch Operations

You can execute batch operations on multiple items at once, for example, deleting multiple items at once, or marking them as sold. When marked as sold, the UI immediately responds by giving the label a strikethrough effect to provide a solid user experience. Batch operations allows for greater time saving when executing redundant operations for a batch of items. Apps developed using Crosslight will save a lot of time, not only for you, but also for the users of your app.

Data Presentation Variations

We have shipped two different variations for the iPad version. The first variation of Inventory Tracker sample presents the list of items in a master-detail fashion, whereas the other one showcases the items in a grid-view like structure. These two samples follows the Apple HIG (Human Interface Guidelines) for iPad, therefore giving users a better experience when using the app. Editing screen is also shown differently, one in a detail view, whereas the other one in a popover controller.

Efficient Memory Management

The list view introduced in Inventory Tracker sample highlights one of the most important feature that a listing app should have: efficient memory management. This feature is efficiently achieved through smart cell reuse, all done in background. The table cell gets reused when it is out of the view, so you don’t have to worry of having a large amount of footprint when your item list gets too large. All you have to do is provide the items source in the view model and let Crosslight do the rest. Did I forgot to mention that you can freely customize the item template yourself?

Built-in Search

If you have hundreds and thousands of items in the list, how can you filter items accordingly? Well, the Inventory Tracker for Android and iOS platforms are shipped with a powerful built-in search feature that allows you to filter items in a fast, efficient manner. On iOS, items are filtered along as you type, so you can quickly choose an item when it comes to view. On Android, the items will be shown at the exact same time after you have hit the search button on your keyboard.

Powerful Image Picker Editor

Inventory Tracker ships with a powerful image picker editor that allows you to take pictures from the device camera, with added support for cropping and scaling, native to the platform level. More importantly, this is all done just by defining the form metadata using the form builder. You can also add your own custom logic after the you have retrieved the image from the camera by defining commands from the view model.

The Form Metadata definition:

[ImagePicker(ImageResultMode = ImageResultMode.Both, ActivateCommand = "ActivateImagePickerCommand", PickerResultCommand = "FinishImagePickerCommand")]
            public static byte[] ThumbnailImage;

You can intercept the commands in the view model:

private void ExecuteActivateImagePicker(object parameter)
        {
            ImagePickerActivateParameter activateParameter = parameter as ImagePickerActivateParameter;
            if (activateParameter != null)
            {
                activateParameter.CustomCommands = new Dictionary();
                activateParameter.CustomCommands.Add("View Larger", this.ViewLargeImageCommand);
            }
        }

        private void ExecuteFinishImagePickerCommand(object parameter)
        {
            ImagePickerResultParameter resultParameter = parameter as ImagePickerResultParameter;

            if (resultParameter != null && resultParameter.Result != null)
                this.Item.LargeImage = resultParameter.Result.ImageData;
        }

Intelligent Layout Awareness

Apps built on the WinRT platform introduces many visual states that many apps might forget to cover: landscape, filled, snapped and portrait. In the WinRT version of the Inventory Tracker sample, we have covered this scenario in depth, while introducing the wrapped LayoutAwarePage that smartly responds to the various screen states introduced in WinRT platform.

<VisualStateManager.VisualStateGroups>
            <!-- Visual states reflect the application's view state -->
            <VisualStateGroup x:Name="ApplicationViewStates">
                <VisualState x:Name="FullScreenLandscape"/>
                <VisualState x:Name="Filled"/>
                <!-- The entire page respects the narrower 100-pixel margin convention for portrait -->
                <VisualState x:Name="FullScreenPortrait">
                    <Storyboard>
                        <ObjectAnimationUsingKeyFrames Storyboard.TargetName="BackButton" Storyboard.TargetProperty="Style">
                            <DiscreteObjectKeyFrame KeyTime="0" Value="{StaticResource PortraitBackButtonStyle}"/>
                        </ObjectAnimationUsingKeyFrames>
                        <ObjectAnimationUsingKeyFrames Storyboard.TargetName="ItemGridView" Storyboard.TargetProperty="Padding">
                            <DiscreteObjectKeyFrame KeyTime="0" Value="96,137,10,56"/>
                        </ObjectAnimationUsingKeyFrames>
                    </Storyboard>
                </VisualState>
                <!--
                    The back button and title have different styles when snapped, and the list representation is substituted
                    for the grid displayed in all other view states
                -->
                <VisualState x:Name="Snapped">
                    <Storyboard>
                        <ObjectAnimationUsingKeyFrames Storyboard.TargetName="BackButton" Storyboard.TargetProperty="Style">
                            <DiscreteObjectKeyFrame KeyTime="0" Value="{StaticResource SnappedBackButtonStyle}"/>
                        </ObjectAnimationUsingKeyFrames>
                        <ObjectAnimationUsingKeyFrames Storyboard.TargetName="PageTitle" Storyboard.TargetProperty="Style">
                            <DiscreteObjectKeyFrame KeyTime="0" Value="{StaticResource SnappedPageHeaderTextStyle}"/>
                        </ObjectAnimationUsingKeyFrames>
                        <ObjectAnimationUsingKeyFrames Storyboard.TargetName="ItemListView" Storyboard.TargetProperty="Visibility">
                            <DiscreteObjectKeyFrame KeyTime="0" Value="Visible"/>
                        </ObjectAnimationUsingKeyFrames>
                        <ObjectAnimationUsingKeyFrames Storyboard.TargetName="ItemGridView" Storyboard.TargetProperty="Visibility">
                            <DiscreteObjectKeyFrame KeyTime="0" Value="Collapsed"/>
                        </ObjectAnimationUsingKeyFrames>
                    </Storyboard>
                </VisualState>
            </VisualStateGroup>
        </VisualStateManager.VisualStateGroups>

Tactical Use of Presenters with Data Validation Support

The Inventory Tracker sample offers data validation support with targeted use of presenters. For example, when you try to add an item and you have not entered a product name, a message presenter will be shown, notifying the error. Also, a toast presenter will be shown after you have finished editing. This subtle, yet important toast message informs the user that changes have been made and saved successfully. Giving users the right feedback at the right time is one of the key fundamentals of creating a rich experience for the users of your app. More importantly, you can be invoke the toast presenter from the view model, making sure that all your apps behave in the same, consistent manner.

this.ToastPresenter.Show("Changes saved.");

Wrap-Up

Now you have just seen the features exposed in the inventory tracker sample. This is great news for you because you can easily obtain the same user experience in your app by utilizing the powerful form builder feature in Crosslight. The form builder feature allows you to build forms in minutes, just by specifying partial class for the model which acts as the metadata and giving the corresponding attributes. You can try all of this exciting features by grabbing a copy of Intersoft Mobile Studio from this link: http://www.intersoftpt.com/RequestTrial. Learn more about Crosslight at: http://www.intersoftpt.com/Crosslight/.

Cheers,

Nicholas Lie

We are pleased to announce the release of our next-gen toolset for cross-platform mobile development: Intersoft Mobile Studio. Shipped with powerful features with small footprint, Intersoft Mobile Studio marks the next industry-standard for cross-platform development. Built with the proven MVVM design pattern on its core, Mobile Studio will definitely change the way you develop cross-platform mobile apps. Designed with the future in mind, meaning that you can easily support new platforms easily as Crosslight is easily extensible to support even hundreds of platforms; you can rest assured knowing that the apps built on top of Crosslight will be future-proof. Remember, you are not developing cross-platform apps that works on in a ported environment; you will create cross-platform native apps that will give your audience a rich and pleasant experience when using your apps.

Crosslight ships with a wealth of resources to help you quickly jump start with cross-platform mobile development. In this blog post, I will provide a quick overview of the available resources and where to start your first mobile development journey. If you haven’t installed Crosslight yet, head to Request Trial page and download the free trial.

Four Powerful Templates

Once you have installed Intersoft Mobile Studio, open up VS 2012 and create a new project under Visual C# Templates / Intersoft Solutions / Mobile.

Click OK, and you will be presented with the Crosslight Project Wizard.

Designed with robustness and flexibility, Intersoft Mobile Studio provides you with four powerful templates that is immediately available for your perusal.

Blank Template

The Blank template is great to help you jump-start development with Crosslight with minimal configuration. It is designed as such for you to quickly grasp the concept of development and design pattern when developing apps using Crosslight.

Navigation Template

Looking for designing a great-looking app with navigation features? The Navigation template is here to help you. The Navigation template provides you with navigation templates that can be adjusted using either split navigation or list navigation, depending on your choice.

Master-Detail Template

This is a truly time-saving template that allows you create master-detail apps easily and quickly. The template deals with the split master-detail view for tablets and is equipped with grouping feature, so you don’t have to scratch your head for a long time on how to build a pleasant master-detail app.

Tabbed Template

Crosslight supports multi-screen apps in the form of “tabs”, also known as pivot and panorama pages on Windows Phone. Just with a click of a button, you are given apps with tabbed templates that works the consistently that conforms to each platform’s UI guidelines. Did I also mention it is MVVM-enabled as well?

Crosslight Solution Structure

After you have finished choosing one of the templates, you will get the following solution structure. Just set as one of the projects as your startup project, and watch the magic happens.

Comprehensive Documentation

If you ever get stuck when developing apps with Crosslight, Intersoft Mobile Studio ships with 300 pages covering the best practices, walkthroughs and concepts for building highly scalable enterprise mobile apps. The Crosslight documentation covers a wide range of in-depth topics such as fundamentals of Crosslight, understanding MVVM, defining consistent navigation interface, utilizing the built-in presenters for basic user interactions, working with data, building rich data-entry form, and much more. It also covers platform specific topics such as how to define different layouts for iPhone and iPad, using Fragments in Android, understanding navigation patterns in Windows Phone, handling layout changes in WinRT, and much more.

Robust Samples

To help you get started, Intersoft Mobile Studio ships with four projects that comprises of hundreds of samples across all supported platforms to help you better understand how to develop apps using Crosslight framework.

MVVM Samples

The MVVM Samples is a great place to start as it covers many MVVM features offered in Crosslight, such as demonstrating the basics of MVVM and binding capabilities, for example, binding mode, update source trigger mode, and converter. It also includes several reference samples – such as loan calculator and currency converter – to help you understand how the binding features work together.

Data Samples

This project includes a collection of samples showcasing the data-aware features such as presenting as a simple list, grouped list and searchable list. It also shows how to deal with data management in common business scenarios such as data editing, update and delete, as well as batch updating. In addition, it also demonstrates a number of built-in list styles available in each platform as well as showing the customization of list item template.

Services Samples

This project includes a collection of samples showcasing various prebuilt services available in Crosslight such as navigation services, presenter services, platform services and mobile services. All services are programmable in the shared application layer which allows you to streamline the user interaction logic as well as enable maximum code sharing. Mobile services demonstrate a vast array of services commonly available to mobile platform such as telephony services, location services, camera services, social services, map services and much more.

Inventory Tracker

Thoughtfully designed and well-defined user interfaces, the Inventory Tracker is a a reference sample that works consistently across platforms and conforms to the de facto UI specifications for each platform. The Inventory Tracker provides a lot of meticulous features that offers a pleasant user experience. Features of the Inventory Tracker will covered in depth on the upcoming post.

What’s Next?

This is just the beginning. With iOS 7 just around the corner, we will be going to fully support iOS 7 within a week after it has been released to the public. In the upcoming milestone, we will enhance Crosslight with powerful and robust data access framework with sync support, saving you the hassle of writing hundreds lines of codes just for data syncing purposes. Also, we will shift our sprint tasks to a more fast-paced, dynamic progression; giving you regular updates that will tremendously enhance your development experience with Crosslight.

Cheers,
Nicholas Lie

As the Crosslight development is maturing and we’re entering the last few sprints of our R1 milestone, I’m pleased to share more details about Crosslight and also providing insights and answers to many questions that have landed to my inbox since the introduction. In my previous blog post, I’ve shared about our 2013 roadmap and the new exciting direction that we’re heading to – particularly in the mobile development space.

We’re very excited with several new product lineups that we’ve got in the labs so far, and I’m sure you can feel the same excitement as well. We’re going to have new stuff in all the three existing platforms (ASP.NET, Silverlight and WPF), plus a range of new mobile platforms. Sneak the previews of the upcoming ASP.NET lineups here and here.

In this first part of my blog series on Crosslight, I’ll be strongly focused on the high level overview of the product – mainly discussing the architectural overview, what it does, and how it works. Alright, enough appetizer, let’s move forward to the main course.

Native Mobile Development Goes Cross Platform

Cross platform mobile development has inevitably becomes one of the hottest subject in the programming world today. Our recent survey supports that fact very well with over 83% respondents stating they’re planning to build mobile apps targeting two or more mobile platforms in the near future. The main question here is, what tools are available today and whether the tools are ready to accomodate the fast-pacing needs – and more importantly, which is the right tool to get the job done?

Before we started the Crosslight project, there were already a number of tools for cross platform mobile development in the market such as PhoneGaps and Titanium. These tools definitely did a great job for HTML and Javascript savvy. But how about developers with particularly Silverlight/WPF skillset? While we all felt left out, it’s going to change very soon. Read on.

A Deeper Look at Crosslight

The main objective of Crosslight is to bring MVVM design pattern – a pattern that most Silverlight & WPF developers are familiar with – to the iOS and Android world. Integrated to Xamarin technologies, Crosslight opens up a whole new level of possibilities in the way you build mobile apps. Instead of writing code for each platform in their own language with completely different set of API, Crosslight lets you write application logic once with a common API which can be shared to multiple projects targeting different platforms.

This is made possible thanks to the Crosslight Foundation that provides powerful data binding implementation, high-performance messaging and commanding framework, and thoughtfully engineered application services. On the other end, Crosslight will be available on each different platform to provide the service implementation specific to the platform. Called Crosslight UI Platform, it also includes numerous pre-built user interface components and controllers that are essential to create great mobile business apps with consistent user experiences.

See the following illustration to get deeper insights on Crosslight architecture. It also shows how different technologies are stacked together in a high level perspective.

As seen in the above architecture diagram, Crosslight builds on the mobile development platforms provided by Xamarin and Microsoft to introduce a host of innovative view components that span across all of the 4 major mobile platforms including iOS, Android, Windows Phone, and Windows App Store.

Future new platforms can be easily supported without major changes to existing code – thanks to the Crosslight Foundation that is built upon portable technology. This obviously gives many benefits as you can avoid getting locked to certain technologies that apply only to a specific platform.

Code Reusability Accelerated to A New Height

With each mobile platform designed by different vendor – iOS designed by Apple, Android designed by Google, and Windows Phone designed by Microsoft – each platform exposes completely different API and design pattern. This makes application logic sharing one of the biggest challenges in cross-platform mobile development. To get a grasp on the API and design pattern differences of each platform, take a look at the simple Hello World implementation below.

Hello World in Xamarin.iOS:

public class MyViewController : UIViewController
{
    public override void ViewDidLoad()
    {
        base.ViewDidLoad();

        ...

        button.SetTitle("Click me", UIControlState.Normal);

        button.TouchUpInside += (object sender, EventArgs e) =>
            {
                UIAlertView alertView = new UIAlertView();
                alertView.Title = "My MobileApp";
                alertView.Message = "Hello world from my mobile app";
                alertView.AddButton("OK");
                alertView.Show();
            };
    }
}

Hello World in Xamarin.Android:

[Activity(Label = "AndroidApplication1", MainLauncher = true, Icon = "@drawable/icon")]
public class Activity1 : Activity
{
    protected override void OnCreate(Bundle bundle)
    {
        base.OnCreate(bundle);

        ...

        Button button = FindViewById<button>(Resource.Id.MyButton);

        button.Click += delegate
            {
                AlertDialog.Builder dlgAlert = new AlertDialog.Builder(this);

                dlgAlert.SetMessage("Hello world from mobile app");
                dlgAlert.SetTitle("My MobileApp");
                dlgAlert.SetPositiveButton("OK", (o, e) => { });
                dlgAlert.SetCancelable(true);
                dlgAlert.Create().Show();
            };
    }
}

Hello World in Windows Phone:

public partial class MainPage : PhoneApplicationPage
{
    ...

    private void MainPage_Loaded(object sender, RoutedEventArgs e)
    {
        this.MyButton.Click += (object s, RoutedEventArgs e2) =>
            {
                MessageBox.Show("Hello world from mobile app");
            };
    }
}

As seen in the above examples, none of the application logic code are shareable which is natural due to the API differences of each platform.

In the examples above, notice that the iOS and Android code was written in C# instead of Obj-C or Java – thanks to the Xamarin platforms that solve the language barriers in cross-platform mobile development. Xamarin provides developers the ability to share (on average) 75% of their C# code between iOS, Android, and Windows, and can reach as high as 90%. Crosslight builds on this by adding a cross-platform MVVM framework, allowing developers to consistently reach nearly 96% code reuse.

The following code samples show how to use Crosslight to build your iOS, Android, and Windows UI, reusing the same ViewModel across each platform:

Crosslight iOS App:

[ImportBinding(typeof(HelloWorldBindingProvider))]
public class MyViewController : UIViewController<HelloWorldViewModel>
{
}

Crosslight Android App:

[Activity(Label = "AndroidApplication1", MainLauncher = true, Icon = "@drawable/icon")]
[ImportBinding(typeof(HelloWorldBindingProvider))]
public class Activity1 : Activity<HelloWorldViewModel>
{
}

Crosslight Windows Phone App:

[ImportBinding(typeof(HelloWorldBindingProvider))]
[ViewModelType(typeof(HelloWorldViewModel))]
public partial class MainPage : PhoneApplicationPage
{
}

It’s awesomely clean, agree? That’s made possible as the UI logic is moved from the platform-specific views to the core MVVM project. Now the UI logic code looks like the following.

public class HelloWorldViewModel : ViewModelBase
{
    public HelloWorldViewModel()
    {
        this.HelloCommand = new DelegateCommand(this.ExecuteHelloCommand);
    }

    public DelegateCommand HelloCommand { get; set; }

    private void ExecuteHelloCommand(object parameter)
    {
        this.MessagePresenter.Show("Hello world from Crosslight mobile app", "My App");
    }
}

If you’ve built Silverlight or WPF apps with Intersoft ClientUI – which I highly presumed you have – then you should recognize the above code at the first look. It leverages the design pattern similar to ClientUI such as delegate command and view presenter. Later on, you’ll find more APIs that you’re already accustomed to – which allow you to get started quickly with very minimal learning curves.

As always, our goal is to simplify developer’s life and make the jobs done with the right tool. Crosslight was designed to do just that. With app UI logic now sharable, it boosted the overall code reusability to nearly 96%, leaving the small percentage on the app-specific layers such as views and controllers.

The above illustration visualizes the typical code reusability in cross-platform mobile development and shows how Crosslight supercharge it to a whole new, never-before-possible level.

True Native Mobile Apps

In the past few weeks, I received numerous emails asking if Crosslight uses HTML as its main presentation layer but wrapped as native app. That’s what the other solutions such as PhoneGaps are doing. In contrast, Crosslight is a cross-platform solution that completely uses native platform API. This doesn’t only give you the best user interface that conforms to the platform guidelines, it also delivers great performance and extremely smooth UX that cannot be simulated with HTML. See the illustration below to get a proper understanding on the platform-specific user experiences enabled in Crosslight.

Obviously, it’ll be always the best option to build apps in native user experiences as you can leverage many of the pre-built platform API, including the high-performance UI virtualization, multi-touch gestures, navigation, animations and much more. The only question is whether it’s possible to do so with the skills you already accustomed to – well, now it is.

Wrapping Up

At this point, I hope you’ve got it clear that Crosslight targets pure native platforms. No HTML or Javascript is required. You use C# to write code and layer your apps in 3-tier architecture as you may have done in Silverlight or WPF applications. Because Xamarin.iOS and Xamarin.Android apps are 100% native, the final output are real native binaries that conform to the platform byte code and processor instructions. They are not virtualized, cross-compiled, or interpreted – in fact they feature the same level of performance and resources management as in the apps produced by the original platform’s compiler.

In this blog post, I’ve only scratched the surface of the Crosslight architecture. As an official Xamarin Premier Partner, we are working closely with Xamarin in our vision to create the most comprehensive sets of cross-platform frameworks and reusable view components that help developers build cross-platform mobile apps in dramatically less time with less effort. As the results, you will be able to rapidly create amazing mobile business apps with native user experiences while maximizing code sharing.

In the next blog series, I will share more details such as more code-level tutorials and basic API usage, UI & UX design best practices and how they conform to each platform guidelines, as well as many great features like universal data management, streamlined navigation and various mobile services. Anyway, I hope this post gives you a comprehensive overview of Crosslight and how we leveraged different pieces of latest technologies to deliver the most elegant solution for cross-platform native mobile development.

Sign Up for Beta

Last but not least, we’re opening a private beta for selected candidates who are willing to contribute significant feedback and help us testing the product features in details. If you believe that you’re the right candidate we’re looking for, please click here to sign up for a beta. Thanks for reading and stay tuned for the next posts!

All the best,
Jimmy