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

Good news! For those of you who’ve waited for so long for Crosslight Field Service sample, it’s now available here. This sample highlights many of the best practices found when developing Crosslight applications with no tedious workarounds whatsoever. Works on iPhone, iPad, Android phones and tablets, this sample sets a new standard for Crosslight app development.

Features highlight:

• Works on iOS and Android, on both phones and tablets devices.
• Showcases best coding practices when using Crosslight.
• Supports Dialog Presenter on tablet mode.
• True data binding capabilities with UI live updates.
• Saving and loading data through SQLite.
• Crosslight Form Builder to create a truly versatile form that works consistently on iOS and Android.
• FooterViewTemplate on iOS that mimics Apple-style app.
• The use of Crosslight Signature Pad to obtain customer’s signature upon assignment completion.
• Deep navigation to the completion screen when attempting to complete an assignment.
• Full iOS storyboard support.
• Use of CollectionView/GridView for photos.
• Supports changing ViewController’s Status Bar Style at runtime.
• Showing directions with the Crosslight Location Service.

If you haven’t figured out why we made this sample, I highly recommend you to check out the my previous blog post where I highlight many parts of the sample that can be fixed and enhanced to produce a better app with Crosslight.

In the next blogpost, I’m going to elaborate more on the interesting scenarios found in this sample and the code behind to achieve each scenarios gracefully, which will hopefully be of great tips for seasoned and pro Crosslight developers alike.

Stay tuned,
Nicholas Lie

In our past releases, getting started with Intersoft Premier Studio was quite inconvenience and tedious. With tons of shortcuts to choose from, you can be easily confused where to start from. In this release, we think hard on what’s the best possible scenario for users to get started quickly with our products. At the end, we came to a conclusion: samples.

Samples provide a hands-on experience for developers as well as practical code for implementing the desired features to their applications. We’ve made it super easy for you to run the samples and opening the sample solution in Visual Studio, all right from a single web interface.

Introducing the New Get Started Experience

When you install Premier Studio, you’ll get the following dialog box.

When you click Finish with the checkbox ticked, a new browser will be opened, this will lead you to a landing page that will help you get started with our products (assuming that you have a working internet connection).

Simply select one of the products you would like to get started with, you will be immediately presented with the available samples designed in stunning card view interface. Then hover on the samples you’re interested in to perform an action.

Note that the Get Started experience works only on Windows with Premier Studio (2016 and above) properly installed.

Getting Started with WebUI

Nothing explains better than a video. Here’s a 1-minute video experience on how to get started with WebUI through the new Get Started experience.

The samples for WebUI is categorized according to its respective controls, so you can quickly jump to the controls you’re interested in.

When you hover on a sample, you’ll get the following experience.

When you click on Open Solution, a new Visual Studio instance that contains the sample will be automatically opened. When you click on Run Sample, a locally-running sample for that particular sample will be launched. Clicking on Learn More takes you to the WebGrid documentation.

Getting Started with Crosslight

And here’s a minute-and-a-half video that shows the Get Started experience with Crosslight.

The samples for Crosslight are categorized as follows:

• Basic Samples: These are the basic and recommended samples if you’re just starting out with Crosslight. It contains the basic fundamentals of Crosslight development, such as MVVM pattern, data binding, display data list, perform CRUD operation, and more.
• App Samples: These samples showcases small, working apps made with Crosslight.
• UI Samples: These samples showcases various UI components available in Crosslight, such as Crosslight Charting, Crosslight Material Design, Crosslight Signature Pad, Crosslight Maps, Crosslight View Slider and more.
• Services Samples: These samples demonstrates how you can work with Crosslight services which are built-in to the Crosslight ViewModel and other library extensions as well. For example, performing calls, scanning barcode, sending emails, sharing content to social media and more.
• Data Samples: These samples shows you how to work with data-related operations with the built-in repositories and how they work together in harmony with the open-source Crosslight App Framework.

When you hover on an item, you’ll be presented with the following.

When you click on Download, you’ll immediately get a zip file that is immediately runnable using Xamarin Studio or Visual Studio (works on either Mac or Windows). If you click on Learn More, you’ll be taken to the respective sample page in the Developer Center.

Getting Started with ClientUI

Last but not least, here’s another minute-and-a-half video that shows the Get Started experience with ClientUI.

The samples for ClientUI are categorized as follows.

The categorization follows the previous categories available in the ClientUI Live Samples. When hovering to an item, you’ll be presented with the following experience.

If the sample has a WPF counterpart, then an additional combo box will be displayed for WPF, as well as the Run Sample option. If the WPF counterpart is not available, then the combo box will not appear. When clicking on the Open Solution, then the Silverlight solution will be opened. Similarly, clicking on Run Sample will run the Silverlight sample locally on your computer.

Conclusion

We hope you enjoyed the new Getting Started experience available in this new release. Should you have any feedback with the Getting Started experience, feel free to initiate a chat with us, and we’ll be more than happy to assist you for the best on-boarding experience.

Till next post,
Nicholas Lie

Hi guys, Nicholas here. I’m back with another blog post, this time covering the Xamarin Field Service sample. Many of you have asked: “How can I transform the Xamarin Field Service sample using Crosslight?” And that tickled something in the back of our minds. This could be our next Crosslight reference sample! So we embarked on a quest to transform the Xamarin Field Service completely using Crosslight and see how much we can do about it.

Tablet-only Design?

Xamarin Field Service on Android, iPad and Windows 8.1

Before delving further, we need to take a step back and have a good look on overall UI and UX design of this app. When talking about cross-platform, yes, it would be valid to say that this app works cross-platform. But it only works on tablets. Why can’t the design be brought to the phone as well?

Let me share with you some of the design quirks found in the app, and how we decided to transform the experience in overall. We’re not talking about any code stuff first in this post. Just pure, plain UX, then we’ll move on to code sharing aspects in the next post.

The Assignments Screen

The assignments screen. At a first glance, nothing seems to be wrong with it. So, we decided to add additional swipe gesture touches to it, to change statuses quickly. Overall, I’m totally fine with it.

The Assignment Detail

Until it pushes the entire screen to display the assignment detail. Let’s take a look at Xamarin’s Field Service push navigation.

The transition between the assignments list and the assignment detail screen. It’s quite rare to see an iPad app performs a push navigation in such manner, especially in a list navigation. Most mobile apps will present itself with a SplitView on iPad, in which the push navigation will be contained within itself, not navigating the entire view. This is apparent in several iPad’s default apps, such as Mail, Contacts, Messages and Notes. I’m not saying this design is incorrect. But what if there is a way to enhance the navigation experience, much like the Apple’s native experience?

Problem: User experiences abrupt changes when navigating to detail view, hindering the user experience.
Objective: Show the detail view without abrupt, major changes in screen presentation.
Considerations: Obviously, we can’t add a SplitView to do that.
Our solution: Crosslight Dialog Presenter.

Crosslight Field Service – iPad Dialog Presenter

The Dialog Presenter is be a perfect candidate to replace the push navigation. By displaying a beautiful translucent modal panel from the right-hand side to the center that covers third-quarter of the screen, we managed to simulate the “content navigation” found in split view apps, enhancing the overall detail navigation experience. To close the dialog presenter, users can simply tap on the left hand side of the screen, outside the dialog presenter.

Have you managed to get started with the Dialog Presenter? If not, I’ve covered how to get started with the Dialog Presenter in another post.

Reusing the same view, the dialog presenter’s content can be easily adapted to iPhone’s more compact screen and uses simple push navigation, as follows.

Crosslight Field Service – iPhone Push Navigation

Crosslight is all about reusability, efficiency and design pattern consistency. You can easily design views that work perfectly in either phone or tablets, thanks to its robust, thoughtfully engineered navigation service.

Displaying the Navigation Items

Okay, we’ve managed to solve the list navigation experience. But how about containing all those navigation items in the detail view of our dialog presenter? Currently, we have 7 items: Summary, Map, Items, Labor Hours, Expenses, Documents, Confirmations. I’m not including History since it’s not supported by Xamarin just yet.

Xamarin Field Service – iPad Navigation List

Problem: The navigation items takes up too much space and exceeds the 5-items-limit for the tabs.
Objective: Display the navigation items inside the dialog presenter, while still maintaining a native and pleasant iPad UX.
Considerations: Can we simplify the navigation items even futher?
Our solution: Tabbed navigation.

Up to this point, you might have several objections in mind, such as: “What if Xamarin decided to bring that History menu back up and even adding more modules to the app? Your tabbed solution will not be able to solve that issue, no?” Yes. We admit it won’t be able fit more items inside it, as Apple has provided a maximum threshold of 5 items of the tab controllers.

However, we can improve the navigation item categorization to include lesser items and display them as needed. Remember, as a UI/UX designer, you have to keeps things simple for your users. And contextual. Imagine you’re designing the app for your mom, therefore, you have to keep it as simple as possible.

Crosslight Field Service – iPad Tabs

Our answer was to reduce the number of navigation items into maximum of 5 items: Summary, Items, Labor Hours, Expenses, and Confirmations. The Map and Documents can easily fit into the Summary tab. It all makes sense, considering that the Map and Documents do not contain any data entry capabilities and does not require any user interactions whatsoever. In other words, they’re designed to be read-only, which would fit the Summary tab. Why use 7 tabs if you can manage with just 5? And here’s how it looks on the iPhone.

Crosslight Field Service – iPhone Tabs

As for the History problem, since users can’t perform any data interaction with it, you can simply add a History icon button within the Summary tab that displays the previous records related with the assignment, or if you would like to separate each the list of Documents and list of History records, you can introduce a segmented button, like the one found in Apple’s App Store Purchased screen, especially the “All” and “Not on This iPad“.

App Store – iPad – Purchased

The Summary Screen

When I think of Summary, I always assume that the user expects the view to contain read-only information. For that same reason, the Summary screen is perfect to display static list of items, in which the user can perform only one action upon it.

Xamarin Field Service – iPad – Summary

Problem: The number of items to be included tab navigation can only contain max. 5 items.
Objective: Reduce the number of navigation items and display relevant information in a simpler manner.
Considerations: Decide which navigation menus that don’t need user interaction.
Our solution: Put Maps and Documents inside the Summary screen.

Crosslight Field Service – Maps and Documents in Summary

Therefore, we decide to inject Map and Documents inside the Summary screen. Including the Map was pretty simple. We display then Map on the top header, along with other relevant information about the customer. If users were to click on the map view, then Apple Maps will be fired up with a placemark showing more details about the location in the form of map annotations. As for the Documents, it is achievable simply by adding the documents list at the very bottom of the Summary page.

The Items Screen

How many times have you encountered an iPad app with adding and editing experience that is not located in the navigation bar? I’m sure, not much. For me, it’s my first time.

Xamarin Field Service – Items

And because of that, I’m pretty sure this is not Apple’s standard design.

Problem: The user actions are not part of the navigation bar and it’s confusing.
Objective: Provide a method for the user to display the relevant information as needed.
Considerations: What does the user usually expect when perform user actions?
Our solution: By removing the sticky header altogether, we’ve managed to place the user actions where it truly belongs.

Crosslight Field Service – Items

The addition and editing of items generally occurs from the navigation bar, in which we have done so with the dialog presenter approach. Since the Items screen is similar to the Labor Hours and Expenses screen, we’re taking the same approach to both of the screens.

The Sticky Header

Xamarin Field Service – Sticky Header

Problem: With the sticky header gone, what is the best place to put it?
Objective: Find an alternative to place the sticky header with global accessibility.
Considerations: The information should be globally accessible, anytime, anywhere.
Our solution: Provide a header callout that displays the removed information.

In my personal opinion, it’s the “sticky header” in the content detail view is what breaks the overall iPad experience. This is why we have removed this view and opted to stick it in only the Summary view, the correct place where it belongs. Users also do not have to see this information the whole time.

Crosslight Field Service – iPad

However, if the user wants to see that quick information, he can just tap on the top header anytime and a callout will present the temporary information he needed.

The “Active Work” Indicator/Player

Before we proceed, we might have forgotten one other thing. The “active work” indicator/player. If you notice, when the assignment is marked as Active, the player pops out from the bottom of the screen to let the user know that the current assignment is active and he can pause at any time. This will count automatically as a new entry in the Labor Hours screen.

Problem: Display globally-available information that shows the current work is active that adheres to Apple’s standard user experience.
Objective: Display the “active work” indicator/player in the dialog presenter content detail.
Considerations: It has to be global (user should be able to see it all the time). The dialog presenter content is already cramped up. Where would be the correct place to put the view?

Before I present you with our approach to the above problem, I want you to think how to solve this problem. Think of all the possible places and approaches to tackle this problem. And yes, Apple did have this exact same problem in one of their apps. Can you guess what the app is?

Did you come up with any solution to the above problem? If not, let me tell you what our solution is: Apple’s Music Player View.

Apply Music – Player

Think about it. The Music app introduced in iOS 8.4 has this exact same problem. When the music is playing, how can Apple show the user on what music is playing, globally, and whether the user can perform any actions upon it?

Crosslight Field Service – Active Work View

Yes, we dealt with the problem the same way. Both of the solutions are consistent in iPhone and iPad.

The Confirmation Screen

The last, but not the least view in the app: the confirmation screen. This screen also presents quite a challenge to be redesigned and optimized.

Xamarin Field Service – Confirmation

Take a look at the design above. And imagine running it on a phone.
The design is quite tricky to address, since it has one list and a signature pad.

Problem: The screen’s design cannot be adapted to phones.
Objective: Revamp the screen in such a way that will accommodate users running on tablets and phones.
Considerations: The vertical-scrolling list might be a problem.
Our solution: Change the vertical-scrolling list into a horizontal-scrolling list and add the signature pad directly beneath it.

Crosslight Field Service – Confirmation Screen

Therefore, we’ve elegantly redefined how things work in the Confirmation screen by making the Photos section acts as a carousel view with Signature Pad placed directly underneath it. This way, it can work on smaller screens like phones.

How about Android?

Android fans, do not fret. Let’s take a look at the Android designs of the Field Service app.

Here’s a gallery of how it looks on the phone.

And here’s how it looks on Android tablets.

Umm, wait, the images above look very similar with iOS rather than Android, particularly the swipe-to-action screens. Could it be possibly that I attach wrong images, you might asked. Nope! We’ve great surprises for you, Android fans! Stay tuned for my answer in the next post.

Wrapping Up

I hope this post may give you meaningful insights on better design for cross-platform, especially one that works for both tablets and phones. By streamlining the design and user flow at the beginning, jumping into development becomes much an easier task with clearer goal in mind.

If you haven’t try out Crosslight, you can quickly jump start by requesting your free 30 day trial here. You will be guided by our consultant team during your evaluation period.

In the next post, we’ll see how can we use Crosslight to create this app and make it work across all platforms of different screen sizes and see how much code for this app can be optimized to work for multiple platforms.

Update

Read the part 2 here, which contains highlights of the finished sample along with snippet codes and detailed explanations.

Till 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

This topic describes how you can easily display your data in a grid view for Android in Crosslight apps. You will learn how to configure GridFragment and create the binding provider for GridFragment. If you haven’t familiar with simple list in Crosslight, please check out Displaying Simple List. It is expected that you have successfully displayed a simple list and created the required View Model before continuing. Learn more.

The sample code is available to download in our Git server here. Feel free to leave any comment or feedback.

Cheers,
Martin Lie

Nowadays, you can see a lot of mobile apps displaying circular image on list view. This how-to topic shows how you can customize the appearance and presentation of cell template with image in a table view to achieve round corner in iOS, Android and Windows platforms. Learn more.

The sample code is available to download in our Git server here. Feel free to leave any comment or feedback.

Cheers,
Martin Lie

This how-to topic describes how to implement data synchronization using Crosslight Enterprise Framework. There is no doubt that data synchronization has becoming essential requirement in today’s business apps that allows online offline synschronization.

This post guides you how to implement data synchronization by creating a new Crosslight app from the Crosslight Business Template. You will learn how to enable the local data storage feature, configure the synchronization settings, preparing the domain models, and calling the synchronization API to perform two-way data sync. Learn more.

You can download the sample code from our Git server here. Feel free to leave your comment or feedback if any.

Cheers,
Martin Lie

This blog post shows you in-depth how to create apps that use SQLite as its local data storage using Crosslight Business Template. You will learn how to configure SQLite for the first time, setting up the domain model through Intersoft Entity Designer and add some simple settings and code to enable SQLite. Learn more.

We have made the sample code available to be downloaded from out Git server here. Feel free to post any comment or feedback.

Cheers,
Martin Lie

This blog post will discuss topic on how you can use Crosslight SQLite as a local data storage for your apps. Before you start using Crosslight SQLite, it is recommended that you have basic knowledge about data binding and MVVM design pattern. Learn more.

We have created a sample that lets you learn how to create SQLite tables with capability to insert, update and delete the record, use LINQ Query and custom SQL Query and many more. The sample code can be downloaded from our Git server here.

Happy Learning!

Cheers,
Martin Lie