Back in November 2015 I wrote a blog post on Redesigning Xamarin Field Service Sample – Part 1. Well, in that post I’ve discussed various design quirks and what improvements can be made to made the overall Xamarin Field Service sample better. First of all, we’re glad to receive many positive responses towards that post and very happy to see many Crosslight developers are taking UI and UX very seriously in designing their cross-platform apps.

Many of you have asked when will the blogpost see the light of day. Well, now it is. We’re very excited to announce that the sample is now available for you guys to check out and experiment for yourself. It is available here: http://git.intersoftsolutions.com/projects/CS/repos/app-fieldservice/browse. Before I can delve into the technical aspects of this sample, in this second part of the post, I would like to re-highlight what we’ve promised in the first post and see it in action, in the form of shots and videos, with codes if possible. We tried to retain the business logic as much as we can to adhere to the original sample.

Better Device Compatibility

When you try to run the original sample, you won’t be able to run the sample on phone devices, which is kind of disappointing. But not with Crosslight. You can definitely deploy the sample on phones and tablet devices.

With this, you can easily target more devices as phone devices are greater in number when compared to tablets. One note: we’re discarding Windows-based platforms for now due to low market receptivity. Once it has gained more traction amongst cross-platform mobile developers, we’ll definitely revive the Windows lineup.

The Login Screen

First, let’s take a look at the original sample login screen experience.

One thing’s for sure: I can’t definitely use this screen on landscape orientation. When I try to focus on the username text box, the login box just flies away from the screen up to the point I can’t see where the text box is and input my username. You can still use this screen on portrait orientation though. Which is weird. Let’s take a look at Crosslight’s login screen.

No matter how you rotate it, it works consistently on both portrait and landscape orientation, on phones as well.

The Assignment List Screen

The assignment screen is pretty much the same, except for a few changes:

1. We don’t feel that the “sticky” header feels common in modern mobile apps, therefore we opted for “grouped” assignments instead. Sticky headers tend to take too much space, obstructing the user’s view and may cause confusion. Active assignments are put on the top of the list, followed by Completed assignments and Pending assignments. On iOS, you can easily tap the status bar to get to the topmost part of the TableView (this is the default behavior of the TableView) to see the Active Assignment quickly.
2. We removed the the button click behavior from the “assignment status”. Instead, we opted for swipe gesture, as this is more commonly used in mobile apps. If the assignment is On Hold, you can only see Active and Complete as options (as shown in the shot above). It feels counter-intuitive to have two clickable UI elements inside an assignment. The user might wonder if there’s any additional UI elements that can be clicked in addition to the “Play” button.
3. Also notice that you can’t perform the swipe gesture if the assignment isn’t accepted yet, or is currently the running assignment. The secret lies in the AssignmentListViewModel.cs inside FieldService.Core/ViewModels folder. /// <summary>
   /// Determines whether the edit command can be executed.
   /// </summary>
   /// <remarks>>
   /// Allow users to perform swipe actions only when:
   /// 1. The item status is Active or Pending
   /// 2. The active assignment is not currently running.
   /// </remarks>
   protected override bool CanExecuteEdit(object parameter)
   {
       if (parameter is EditingParameter)
       {
           EditingParameter editingParameter = parameter as EditingParameter;
           if (editingParameter.Item is Assignment)
           {
               Assignment item = editingParameter.Item as Assignment;
               if (item == this.AssignmentViewModel.Item && this.AssignmentViewModel.IsStarted)
                   return false;
               else
                   return (item.Status == “Active“ || item.Status == “Pending“);
           }
       }    return false;
   }

The Assignment Detail Screen

This is where things get pretty interesting.

As promised, on tablets, we’ve used the new Dialog Presenter that will slide from the right hand side that will cover at least 3/4 of the screen. You can easily dismiss the detail by hitting the back button on Android or tapping on the area outside the dialog. On phones, normal push navigation is used. To use the Dialog Presenter on iPad, at the TabViewController’s constructor, simply use this code:

public AssignmentDetailTabViewController()
{
    var isPad = UIDevice.CurrentDevice.UserInterfaceIdiom == UIUserInterfaceIdiom.Pad;

    this.ConfigurePresenter(o =>
    {
        o.PreferredContentSize = new CGSize(640, 768);
        o.PreferredContentSizeLandscape = new CGSize(704, 768);
        o.DismissOnTap = true;

        if (isPad)
        {
            o.PresentationStyle = ContentPresentationStyle.Edge;
            o.EdgePresentationPosition = EdgePresentationPosition.Right;
            o.EntryTransition = new SlideFromRightTransition()
            {
                FadeOutSource = false
            };
            o.ContentShadowRadius = 10;
        }
    });
}

And when navigating, you can do something similar as follows:

// on phone, perform standard navigation, while on tablet show the dialog presenter for better experience
if (this.GetService<IApplicationService>().GetContext().Device.Kind == DeviceKind.Phone)
{
    this.ActiveViewModel.NavigationService.Navigate<AssignmentDetailTabViewModel>(new NavigationParameter(parameter));
}
else
{
    this.ActiveViewModel.DialogPresenter.ShowAsync<AssignmentDetailTabViewModel>(
        new NavigationParameter(parameter),
        new DialogOptions()
    {
        HideButtons = true
    });
}

You can see more detail on that inside the FieldService.Core/ViewModels/AssignmentViewModel.cs file.

Special and very important note for iOS: When using the TabViewController after push navigation, you must hide the root navigation controller in order for many correct UX to work properly, for example, the navigation controller transitions, search bar controller, and much more. This needs to be done because the TabViewController has its own NavigationController. It is simply done by calling the following code in the AssignmentDetailTabViewController.

protected override bool EnsureNavigationContext
{
    get { return true; }
}

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

    // Important: Hide the root navigation bar since the tab will have its own.
    this.NavigationController.SetNavigationBarHidden(true, true);
}

We also added a little touch.

You can click the call button to immediately call the specified number, or click on the address to launch Maps with immediate directions to the specified location. If you try to click any of the documents below, the report will be displayed in a modal ViewController.

To launch the report on Android devices, you’ll need a PDF viewer installed to the emulator or device.

The Footer View Template

On iOS, notice that the new FooterViewTemplate is used, which resembles Apple-music style view template. On Android, since the tabs are placed on the top, the view template is used at the bottom of the screen.

The FooterViewTemplate is a new feature added in Crosslight 5.1. In iOS, to use thew new FotoerViewTemplate, simply override the property in the TabViewController and return the Nib file.

public override UIViewTemplate FooterViewTemplate
{
    get { return new UIViewTemplate(AssignmentDetailTabFooter.Nib); }
}

If you’d like, you can also apply the translucent blur effect to the FooterViewTemplate by providing a Visual Effect View element using Xcode.

Here’s the result when applied.

Also note that when you use the FooterViewTemplate, Crosslight.iOS automatically calculates the height of the FooterViewTemplate and readjusts the content bounds above it, so that the contents not “overlayed” and obscured by the FooterViewTemplate. Very nifty.

On Android, you would simply override the ContentLayoutId of the AssignmentDetailTabFragment and return the layout you would like to use.

<?xml version=“1.0“ encoding=“utf–8“?>
<LinearLayout xmlns:android=“http://schemas.android.com/apk/res/android“
    xmlns:app=“http://schemas.android.com/apk/res–auto“
    android:layout_width=“match_parent“
    android:layout_height=“match_parent“
    android:orientation=“vertical“>
    <android.support.design.widget.TabLayout
        android:id=“@+id/tab_layout“
        android:layout_width=“match_parent“
        android:layout_height=“wrap_content“
        app:tabTextAppearance=“@style/CustomTabText“ />
    <FrameLayout
        android:id=“@+id/fragment_container“
        android:layout_width=“match_parent“
        android:layout_height=“match_parent“
        android:layout_weight=“1“ />
    <LinearLayout
        android:id=“@+id/FooterLayout“
        android:layout_width=“match_parent“
        android:layout_height=“50dp“
        android:orientation=“horizontal“
        android:paddingLeft=“10dp“
        android:paddingRight=“10dp“
        android:background=“#DADADA“>
        <LinearLayout
            android:orientation=“horizontal“
            android:layout_weight=“1“
            android:layout_width=“0dp“
            android:layout_height=“50dp“>
            <FrameLayout
                android:id=“@+id/StartButtonLayout“
                android:orientation=“horizontal“
                android:layout_width=“30dp“
                android:layout_height=“wrap_content“>
                <ImageButton
                    android:id=“@+id/StartButton“
                    android:layout_gravity=“center“
                    android:scaleType=“fitCenter“
                    android:layout_width=“match_parent“
                    android:layout_height=“match_parent“
                    android:background=“#00000000“
                    android:src=“@drawable/Start“ />
            </FrameLayout>
            <TextView
                android:id=“@+id/FooterElapsedTimeLabel“
                android:layout_width=“wrap_content“
                android:layout_height=“wrap_content“
                android:layout_marginLeft=“10dp“
                android:text=“ElapsedTime“
                android:layout_gravity=“center_vertical“
                android:textColor=“#000000“ />
        </LinearLayout>
        <LinearLayout
            android:orientation=“vertical“
            android:layout_weight=“1“
            android:layout_width=“0dp“
            android:gravity=“center_horizontal“
            android:layout_height=“match_parent“>
            <LinearLayout
                android:orientation=“horizontal“
                android:layout_weight=“1“
                android:layout_width=“wrap_content“
                android:layout_height=“0dp“>
                <TextView
                    android:id=“@+id/FooterNameLabel“
                    android:layout_width=“wrap_content“
                    android:layout_height=“wrap_content“
                    android:text=“Name“
                    android:textStyle=“bold“
                    android:singleLine=“true“
                    android:layout_gravity=“center_vertical“
                    android:textColor=“#000000“ />
            </LinearLayout>
            <LinearLayout
                android:orientation=“horizontal“
                android:layout_weight=“1“
                android:layout_width=“wrap_content“
                android:layout_height=“0dp“>
                <TextView
                    android:id=“@+id/FooterContactPersonLabel“
                    android:layout_width=“wrap_content“
                    android:layout_height=“wrap_content“
                    android:text=“ContactPerson“
                    android:singleLine=“true“
                    android:layout_gravity=“center_vertical“
                    android:textColor=“#000000“ />
            </LinearLayout>
        </LinearLayout>
        <FrameLayout
            android:orientation=“horizontal“
            android:layout_weight=“1“
            android:layout_width=“0dp“
            android:layout_height=“match_parent“
            android:gravity=“right“>
            <LinearLayout
                android:id=“@+id/ActivePendingLayout“
                android:orientation=“horizontal“
                android:layout_width=“70dp“
                android:layout_gravity=“right|center_vertical“
                android:layout_height=“30dp“>
                <Button
                    android:id=“@+id/ActivePendingButton“
                    android:text=“ACTIVE“
                    android:textColor=“#3BD606“
                    android:textSize=“10sp“
                    android:layout_gravity=“right|center_vertical“
                    android:layout_width=“70dp“
                    android:layout_height=“30dp“
                    android:background=“@drawable/circularTextViewGreen“ />
            </LinearLayout>
            <LinearLayout
                android:id=“@+id/AcceptRejectLayout“
                android:orientation=“horizontal“
                android:layout_width=“80dp“
                android:layout_height=“match_parent“
                android:layout_gravity=“right“>
                <LinearLayout
                    android:orientation=“vertical“
                    android:layout_width=“0dp“
                    android:layout_height=“match_parent“
                    android:gravity=“center“
                    android:layout_weight=“1“>
                    <Button
                        android:text=“✓“
                        android:textColor=“#ffffff“
                        android:textSize=“22sp“
                        android:layout_width=“32dp“
                        android:layout_height=“32dp“
                        android:gravity=“center“
                        android:background=“@drawable/circularButtonBlue“
                        android:id=“@+id/AcceptButton“ />
                </LinearLayout>
                <LinearLayout
                    android:orientation=“vertical“
                    android:layout_width=“0dp“
                    android:layout_height=“match_parent“
                    android:layout_weight=“1“
                    android:gravity=“center“>
                    <Button
                        android:text=“X“
                        android:textColor=“#ffffff“
                        android:textSize=“22sp“
                        android:gravity=“center“
                        android:layout_width=“32dp“
                        android:layout_height=“32dp“
                        android:background=“@drawable/circularButtonRed“
                        android:id=“@+id/RejectButton“ />
                </LinearLayout>
            </LinearLayout>
        </FrameLayout>
    </LinearLayout>
</LinearLayout>

One thing to note is the middle FrameLayout with the ID fragment_container. You’ll need to provide this or the fragment transaction would not work properly.

Single-Responsibility Principle

Before we proceed, I want you to think about this problem for a second: since an assignment can be manipulated from so many places: the list screen, the detail screen and the map screen, what design approach is best used to “sync” the assignment state from any screens, but in an elegant way? For example, the user can start an assignment from the list screen, then from the detail screen, the user pauses, changes the assignment status, then go back to the map screen, plays the assignment once more, change the assignment status to Active, and so on.

We need to access the assignment from various ViewModels across the app, but we must ensure that the assignment states are correct whenever it is accessed anywhere. In this sample, we’ve used the Single-Responsibility Principle to address this problem, exhibited by AssignmentViewModel.cs located inside FieldService.Core/ViewModels folder. This single class holds a unified information for the Active Assignment as well as any other commands that can interact with the assignment, such as accepting, rejecting, starting, changing status, etc.

Crosslight provides an elegant solution to this problem with the IoC (Inversion of Control) pattern. By registering the ViewModel once in the Container class, you can easily resolve and use this ViewModel anywhere. To begin with, open the AppService.cs file inside FieldService.Core/Infrastructure folder where you’ll an entry that looks similar to the following.

// the assignment view model streamlines all assignment–related logics
// which is resolved in numerous ViewModels such as list, map, and detail
Container.Current.Register<AssignmentViewModel>(c => new AssignmentViewModel()).WithLifetimeManager(new ContainerLifetime());

To resolve the registered ViewModel anyhwere, all you need to do is create a getter-only property that resolves the ViewModel from the Container. For example, as follows.

public AssignmentViewModel AssignmentViewModel
{
    get
    {
        return Container.Current.Resolve<AssignmentViewModel>();
    }
}

Once this is done, you can easily use the object inside your BindingProvider and ensure that the data bindings work flawlessly across screens.

// Command bindings
this.AddBinding(“ActivePendingButton“, BindableProperties.CommandProperty, “AssignmentViewModel.ChangeStatusCommand“);
this.AddBinding(“ActivePendingButton“, BindableProperties.CommandParameterProperty, “Assignment“);
this.AddBinding(“RejectButton“, BindableProperties.CommandProperty, “AssignmentViewModel.RejectCommand“);
this.AddBinding(“RejectButton“, BindableProperties.CommandParameterProperty, “Assignment“);
this.AddBinding(“AcceptButton“, BindableProperties.CommandProperty, “AssignmentViewModel.AcceptCommand“);
this.AddBinding(“AcceptButton“, BindableProperties.CommandParameterProperty, “Assignment“);
this.AddBinding(“StartButton“, BindableProperties.CommandProperty, “AssignmentViewModel.StartCommand“);

Very simple and elegant.

The Items Screen

Let’s take a brief look at the Items screen.

At a first glance, there’s nothing quite special in the Items screen. Until you try to swipe down.

Notice that when you hit on the search bar, the status bar color changes according to the overridden PreferredStatusBarStyle.

public override UIStatusBarStyle PreferredStatusBarStyle()
{
    if (this.SearchDisplayController != null && this.SearchDisplayController.Active)
        return UIStatusBarStyle.Default;
    else
        return UIAppearanceSettings.StatusBarStyle;
}

When you try to run this project on an iPad, you’ll get a popover controller when you try to add an item, and when you edit an item, you’ll get a nice modal ViewController that is displayed in the middle of the screen.

This corresponds to the BindingProvider defined for this view.

if (isTablet)
    this.AddBinding(“TableView“, BindableProperties.SelectedCommandProperty, “NavigateToEditorCommand“);
else
    this.AddBinding(“TableView“, BindableProperties.DetailNavigationTargetProperty, new NavigationTarget(typeof(AssignmentExpenseEditorViewModel)), true);

And in the ViewModel, the NavigateToEditorCommand invokes the following method.

public void ExecuteNavigateToEditor(object parameter)
{
    this.DialogPresenter.ShowAsync<AssignmentItemsEditorViewModel>(
        new NavigationParameter(parameter),
        new DialogOptions()
        {
            NeutralButtonStyle = new DialogButtonStyle(Colors.Red)
        });
}

When executing the Add command:

protected override void ExecuteAdd(object parameter)
{
     this.NavigationService.Navigate<AssignmentItemsEditorViewModel>(
        new NavigationParameter(this.TabViewModel.Assignment)
        {
            NavigationMode = NavigationMode.Modal,
            EnsureNavigationContext = true,
            ModalPresentationStyle = ModalPresentationStyle.FormSheet,
            PreferPopover = true,
            CommandId = “Add“
        });
}

The Labor Hours Screen

In the Labor Hours screen, the experience is pretty similar when adding or editing an item.

Perhaps one particular interesting technique is how to update the footer total Labor Hours at runtime. If you notice closely, when you edit any of the labor hours or add a new entry with a specified Labor Hours, the total labor hours sums up automatically.

To achieve that effect, we provide the FooterViewTemplate for the Labor Hours screen.

public override UIViewTemplate FooterViewTemplate
{
    get { return new UIViewTemplate(DetailFooterLayout.Nib); }
}

And here’s the DetailFooterLayout.

Then in the BindingProvider, we bind the label to.

this.AddBinding(“StatusLabel“, BindableProperties.TextProperty, new BindingDescription(“TabViewModel.Assignment.TotalLaborHours“) { StringFormat = “Labor Hours ({0:0.#})“ });

Which corresponds to the parent ViewModel (TabViewModel) property’s active Assignment with its TotalLaborHours property.

[IgnoreDataMember]
public double TotalLaborHours
{
    get
    {
        return TimeSpan.FromTicks(this.Labors.Sum(o => o.Ticks)).TotalHours;
    }
}

This way, we should be able to centralize the labor hours binding to the same property, eliminating unnecessary workarounds to elegantly achieve this effect.

Validating Input Using Form Validation Metadata

When you input a new labor hour entry, or edit an existing one. If you open the FieldServiceModel.Metadata.cs file inside FieldService.Core/DomainModels folder, you’ll see the following.

If you notice there, there are two validation metadata, one is for the Expense entry and one is for the Labor entry. In this example, we’ve ensured that the Ticks property is a Required Entry and the minimum number for the ticks is 1. Once these conditions are satisfied, then the form is considered a vaild entry and the changes will be saved. Similar to the Expense entry, we’ve enforced that the Price should be greater than 1.

The important thing to ensure that the validation metadata works properly is that you create a partial class from the model that you want to validate, and decorate it with the EntityMetadataAttribute.

[EntityMetadata(typeof(Labor.LaborValidationMetadata))]
partial class Labor
{
    class LaborValidationMetadata
    {
        [Required]
        [Min(typeof(long), “1“, ErrorMessage = “Hours must be greater than 0“)]
        public long Ticks { get; set; }
    }
}

The Expense Screen

The Expense screen also uses pretty much the same technique with the Items and Labor Hours screen, which uses popover for adding new items and modal ViewController for the editing screen.

When you go to the editor screen, we improved on the Form Builder experience a bit to support the image editor detail scenario as follows.

And in Android,

The FormMetadata is as simply as follows.

public class ImageSection
{
    [Editor(EditorType.Image)]
    [Layout(Style = LayoutStyle.DetailOnly)]
    [Image(Height = 200, Placeholder = “photo.png“, Padding = 8, ScaleMode = ImageScaleMode.ScaleAspectFill)]
    [ImagePicker(ImageResultMode = ImageResultMode.Both, UseThumbnailResult = false, PickerResultCommand = “FinishImagePickerCommand“)]
    public static byte[] Image;
}

Jump to Complete Screen

Another interesting interaction in this app is how you can directly jump to the Complete screen when you decide Complete the assignment, either from the List screen, Map screen, or from the assignment detail.

Due to the Single Responsibility principle that we’ve used in this application, achieving this scenario is very easy. In the AssignmentViewModel, simply navigate to the Confirmation screen.

public void ExecuteComplete(object parameter, bool isFromConfirmationPage = false)
{
    if (isFromConfirmationPage)
    {
        this.ExecutePendingOrComplete(parameter, “Complete“);
    }
    else
    {
        if (this.ActiveViewModel is AssignmentDetailTabViewModel)
        {
            // already in the detail view, focus to the confirmation screen
            this.SetDetailSelectedIndex();
        }
        else
        {
            // we‘re in the main view, perform navigation to detail
            this.AutoFocusToConfirmation = true;
            this.ExecuteNavigateToDetail(parameter);
        }
    }
}

The Completion Screen

In the Completion screen, you’ll be greeted with two major UI elements: the Photos Grid/Collection View and a Signature Pad. If you try to complete the assignment immediately without entering any signature, you’ll get a toast message as follows.

You can add additional photos when completing the assignment for extra information.

The code to execute the completion of an assignment is pretty straightforward.

public void ExecuteComplete(object parameter)
{
    if (this.Assignment.Status == “Complete“)
    {
        this.ToastPresenter.Show(“This assignment already completed“);
    }
    else if (this.Assignment.Status == “Active“)
    {
        if (this.Signature == null)
        {
            this.ToastPresenter.Show(“To complete this assignment, please draw your sign in the signature pad.“);
            return;
        }

        this.Assignment.Signature = this.Signature;
        this.TabViewModel.AssignmentViewModel.ExecuteComplete(this.Assignment, true);

        this.IsSignatureImageViewVisible = true;
        this.IsSignatureCanvasVisible = false;
        this.CompleteCommand.RaiseCanExecuteChanged();
        this.AddPhotoCommand.RaiseCanExecuteChanged();
        this.ClearSignatureCommand.RaiseCanExecuteChanged();

        this.ToastPresenter.Show(“Assignment completed“);
    }
    else
    {
        this.ToastPresenter.Show(“You need to activate the assignment first“);
    }
}

You can also clear the signature you’ve entered by hitting the Clear button above the Signature Pad.

Disable Editing After Completed

After you’ve completed an assignment, you won’t be able to make any changes to any of the items available in the Assignment Detail. This includes Items, Labor Hours, Expenses, Photos and Signature. This is possible because we simply need to check for the current Assignment’s Status and see if an operation can be completed.

[MaxLength(255)]
public string Status 
{ 
    get { return (string)this.GetValue(StatusPropertyMetadata); } 
    set { this.SetValue(StatusPropertyMetadata, value); } 
}

In the ViewModel, you would simply override the CanExecute method and see if the assignment is completed before executing your method.

protected override bool CanExecuteSave(object parameter)
{
    if (!this.IsNewItem && this.Item.Assignment.Status == “Complete“)
        return false;

    return base.CanExecuteSave(parameter);
}

This is done so elegantly that you don’t have to access any of the platform-specific views to accomplish this.

Wrapping Up

Hopefully this post provides you with even more insights on what’s happening behind the scenes with the new Crosslight Field Service sample. If you’d like to see more Xamarin samples to be converted to Crosslight, please do let us know in the comments section below.

Till next post,
Nicholas Lie

In my previous post, I’ve shown you how to use a header and footer with custom views in a list/table view. Now, what if I want to show a dockable view at the bottom of the screen? Let’s take the previous sample a bit further to look like the following.

Starting off

To start off, I’ll just copy off the previous sample. If you haven’t read the previous post on how to provide header and footer to your TableView / ListView, it is highly recommended for you to do so before continuing.

If you have done so, let’s move on.

Creating dockable view on iOS

To create the dockable view on iOS, you’ll need to do the following:

• Preparing custom table root view
• Modifying the View
• Modifying the View Controller

Preparing custom table root view

To provide the custom table root view, you’ll need to create a new Crosslight iOS View for iPhone, which is accessible from the Item Templates, available after you’ve successfully installed Crosslight.

Right click on the Views in HeaderAndFooter.iOS/Views folder and select Add, New Item.

Then choose, Crosslight iOS View for iPhone. Give it a name of CustomTableRootView.

First, let’s try to create a the custom table root view. Open the CustomTableRootView.xib in Xcode Interface Builder.

Adding the Docked View

Drag a new View from the Object library, set the outlet as DockedView, and provide the following constraints:

• Horizontal Space Constraint: from Superview.Trailing equal to the View.Trailing with the following values.
  
• Vertical Space Constraint: from Superview.Bottom equal to the View.Bottom with the following values.
  
• Horizontal Space Constraint: from DockedView.Leading equal to the Superview.Leading with the following values.
  

Now that the docked view is ready, let’s drag a Label, set the outlet as TxtHeader, and drag a button, set the outlet as BthHeader. Both of them are given the previous outlet names, so that no code changes will be required in the BindingProvider side. If you wish, you can set the following constraints:

• Give the DockedView a height of 45.
  
• Vertically align the label as well as the button.
  
• Give an inner padding of 20.
  

That’s pretty much it. Let’s modify the View a bit.

Modifying the View

Let’s open the CustomTableRootView.cs and modify that a bit by adding a new ResizeTableView method.

using System;
using System.Drawing;
using System.Linq;
using CoreGraphics;
using Foundation;
using UIKit;

namespace HeaderAndFooter.iOS
{
    public partial class CustomTableRootView : UIView
    {
        #region Constructors

        public CustomTableRootView(IntPtr handle) : base(handle)
        {
        }

        #endregion

        #region Fields

        public static readonly UINib Nib = UINib.FromName("CustomTableRootView", NSBundle.MainBundle);

        #endregion

        #region Methods

        public static CustomTableRootView Create()
        {
            return (CustomTableRootView) Nib.Instantiate(null, null)[0];
        }


        internal void ResizeTableView(nfloat top)
        {
            var tableView = this.Subviews.FirstOrDefault(o => o is UITableView);
            tableView.Frame = new CGRect(0, top, tableView.Bounds.Width, this.Bounds.Height - top - this.DockedView.Bounds.Height);
        }

        #endregion
    }
}

Here, we prepare a handy method to resize the table view when the view is used, called ResizeTableView. By calling this method, the TableView that contains this dock view will have its bounds re-adjusted. This is done so that the scrolling container in the TableView does not exceed the docked view. Take a closer a look at the contents of the method.

In line 36, we first search for the TableView that is added as a subview of the ViewController. In line 37, we set a new bounds for it, not changing the width at all, but just by adjusting the height by taking account the DockedView.Bounds.Height as well.

Modifying the View Controller

Next, open up the MainViewController.cs. Here’s the contents.

using CoreGraphics;
using Foundation;
using HeaderAndFooter.ViewModels;
using Intersoft.Crosslight;
using Intersoft.Crosslight.iOS;
using UIKit;

namespace HeaderAndFooter.iOS.ViewControllers
{
    [Register("MainViewController")]
    [ImportBinding(typeof(MainBindingProvider))]
    public class MainViewController : UITableViewController<MainViewModel>
    {
        #region Properties

        public override UIViewTemplate FooterViewTemplate
        {
            get { return new UIViewTemplate(CustomFooter.Nib); }
        }

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

        public override bool ShowGroupHeader
        {
            get { return false; }
        }

        public override UITableViewStyle TableViewStyle
        {
            get { return UITableViewStyle.Plain; }
        }

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

        #endregion

        #region Methods

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

            // set navigation title
            this.NavigationItem.Title = "Crosslight App";
        }

        protected override UIView GetCustomRootView()
        {
            return CustomTableRootView.Create();
        }

        public override void ViewWillLayoutSubviews()
        {
            base.ViewWillLayoutSubviews();

            // adjust tableview frame based on top layout guide	
            ((CustomTableRootView)this.View).ResizeTableView(this.TopLayoutGuide.Length);
        }

        #endregion
    }
}

Here, we removed the overridden property for HeaderViewTemplate, since we’re going to use the new DockedView to replace the header. Therefore, we then override a new property called UseCustomRootView and return true.

After we’ve done that, we then override the GetCustomRootView() method to return the CustomTableRootView that we’ve just created by calling CustomTableRootView.Create();

The custom root view is one of the unique features introduced in Crosslight’s advanced UITableViewController. It allows you to easily replace the root view with a custom one with just a few property sets, while still retaining the developer experience and automatic binding feature. In the case above, when UseCustomRootView is returning a true value, the GetCustomRootView method will be automatically called when the controller is initializing.

Lastly, we override the ViewWillLayoutSubviews method. This method is called when a new subview is added to the ViewController, which can be done at any time, whether during ViewController creation or programmatically adding a subview at runtime, therefore, when the DockedView is added, we then call our handy method to resize the TableView so that the scrolling container wouldn’t “bleed” past the DockedView.

That’s it. Run the project and you should get the result similar to the following video.

Creating dockable view on Android

Now that we’ve finished the iOS version, let’s create the Android version. To create the docakble view on Android, you’ll need to complete the following:

• Preparing custom layout
• Replacing the content layout in Activity

Preparing custom layout

First things first, let’s create a new Android Layout, and let’s name it CustomLayout.axml. To do this, right click on the HeaderAndFooter.Android/Resources/layout folder.

Select Add, New Item. Under Android, select Layout.

Provide the layout for the CustomLayout.axml as follows.

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <LinearLayout
        android:id="@+id/Footer"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:layout_alignParentBottom="true"
        android:orientation="vertical">
        <LinearLayout
            android:layout_width="fill_parent"
            android:layout_height="1px"
            android:background="#f2f2f2" />
        <LinearLayout
            android:layout_width="fill_parent"
            android:layout_height="wrap_content"
            android:orientation="horizontal"
            android:paddingLeft="20dp"
            android:paddingRight="20dp">
            <TextView
                android:id="@+id/TxtHeader"
                android:layout_width="fill_parent"
                android:layout_height="30dp"
                android:layout_weight="1"
                android:gravity="left"
                android:textSize="20sp" />
            <Button
                android:id="@+id/BtnHeader"
                android:layout_width="wrap_content"
                android:layout_height="wrap_content" />
        </LinearLayout>
    </LinearLayout>
    <ListView
        android:id="@android:id/list"
        android:layout_width="fill_parent"
        android:layout_height="fill_parent"
        android:layout_above="@id/Footer" />
</RelativeLayout>

Let’s take a closer look. Here, we’ve used a RelativeLayout as the root ViewGroup and we’ve added 2 major elements to the RelativeLayout, which is a LinearLayout that will act as our DockedView and ListView.

At a glance, you might be wondering why the ListView is defined after the LinearLayout. This is purely for build purposes. The XML parser parses the text from top to bottom. Since in the ListView, we’ve defined android:layout_above=“@id/Footer”, the build will fail if the LinearLayout is not defined beforehand. Hence, the ListView is defined after the LinearLayout.

One important thing to notice that the ListView’s id is set to @android:id/list. This conforms the standard method to override the built-in ListActivity’s layout in native Android development itself. For more information on that topic, click here. This is done because in the ListActivity class, you can reference the ListView as simply as calling this.ListView, however since you’ve overridden the whole layout, then the ListView must be re-referenced this way so that the Android understands. Everything else is just standard Android layouting process.

Replacing the content layout in Activity

After the layout is prepared, let’s modify some codes in the Activity. Open up MainActivity.cs inside HeaderAndFooter.Android/Activities folder and see the contents as follows.

using Android.App;
using HeaderAndFooter.ViewModels;
using Intersoft.Crosslight;
using Intersoft.Crosslight.Android;

namespace HeaderAndFooter.Android
{
    [Activity(Label = "Crosslight App", Icon = "@drawable/icon")]
    [ImportBinding(typeof(MainBindingProvider))]
    public class MainActivity : ListActivity<MainViewModel>
    {
        #region Properties

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

        protected override int FooterLayoutId
        {
            get { return Resource.Layout.CustomFooter; }
        }

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

        #endregion

        #region Methods

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

            this.RegisterViewIdentifier("TableView", this.ListView);
        }

        #endregion
    }
}

In the ContentLayoutId property, we’ve replaced the old layout to the new CustomLayout that we’ve created earlier and we’ve also removed the HeaderLayoutId. You’ve completed the Android version. Let’s run this project and you should get the result similar to the following.

Wrapping Up

You’ve seen how easy and elegant it is to provide a dockable view to your table view on iOS as well as list view on Android. Achieving the same task without Crosslight would be really tedious and time consuming. The dockable view also comes with automatic binding support, so you can take advantage of native binding process with whatever layout you have. Nice and simple.

You can find the code to the sample here:
http://git.intersoftsolutions.com/projects/CT/repos/crosslightdockableview/browse. To use this sample, you’ll need at least Crosslight build 4.0.5000.323 and above.

See you in the next post,
Nicholas Lie

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

When building applications, I always encourage the team in-charge, to look up and apply the appropriate design patterns for the application.

In our latest release (Crosslight 2), we introduced several new services such as RestClient, SQLite, EntityContextProvider, EntityContainer, etc, enabling you to easily create data aware apps across multiple mobile platforms.

These are the tools that can get the job done. However using all these services without applying design patterns can make your code redundant and much harder to manage.

I’ve created a video explaining several new design patterns to tackle data access challenges using Crosslight. Check it out below.

These design patterns are also extensively used in our Enterprise App Framework. In the next video, I’ll show you how to create data aware application from scratch using the new tools provided in Crosslight 2 and Enterprise App Framework which leverage the design patterns you just learn in this video.

To learn how to work with data using Crosslight, see our online documentation at
http://developer.intersoftpt.com/display/crosslight/Working+with+Data

With Regards,
Andry

We have posted another video tutorial to help you better understand how screen navigation works in Crosslight apps. In this video we covered the tabbed navigation and the most popular navigation pattern seen in mobile apps nowadays, the navigation drawer. This video will highlight the features of the two and also how you can easily integrate the navigation drawer into your Crosslight-enabled apps. See the rest of the video for more details.

You have seen how Crosslight greatly takes care of the intricate details of the navigation in overall mobile apps development: whether it is push, modal, list, tabbed, or the navigation drawer, so you can focus on what is really important for your app, all done right within the centralised and streamlined view model development pattern. So, grab a copy of Mobile Studio on our site to see for yourself! In the next video, I will explain how you can create your own custom service into Crosslight development.

To learn more about Crosslight navigation, check out Designing Consistent Navigation Interface in our online documentation. Should you have any further questions, feel free to raise a thread in our forum. Stay tuned for more Crosslight video tutorials. Don’t forget to subscribe to our YouTube channel as well!

Cheers,
Nicholas Lie