How to Preview your Xamarin.Forms XAML in Xamarin Studio

In my work as a Customer Success Engineer at Xamarin, I demo the tools we provide daily. One that has gained immense popularity since launch has been, without a doubt, Xamarin.Forms. For those of you new to Xamarin development, Xamarin.Forms is a framework that enables you to write your mobile UI for Android, iOS and Windows phone in a shared code layer using either C# or XAML. Many developers see this as a real asset as greater code share suggests shorter development times and getting your app faster to market. XAML based UI development is also something that WPF and C# developers are already familiar with so that means their experience will help them get up and running with mobile sooner.

With that in mind, one thing that developers desire is rapid feedback and development. At the time of this writing Xamarin.Forms currently is a programmatic solution only. That means, no visual designer or previewer to view your UI in progress. That means that the only way to ensure your UI looks good is to build and deploy your app to either an emulator or physical device. While certainly a possibility, this is not the fastest process, especially if you are trying to make minute changes and get immediate feedback.


One solution to this that has been made available is a tool call the Xamarin.Forms Player, written by Daniel Cazzulino, who also happens to be a developer at Xamarin. What this tool does is installs a plugin to Visual Studio that allows you to pair your Visual Studio instance to either an emulator or device. Then, while you are writing the XAML portion of your application, you can actually quickly preview the results live without doing a full build and deployment of the application. This serves as a great solution to many developers. While the Visual Studio add-in has been available for a while, I was recently made aware of this also being published as an Add-In for Xamarin Studio and wanted to write a quick guide on how to get it set up.

From what I understand about the tool, the Forms Player works as a pub/sub application where multiple devices will subscribe to an IDE through a paired code between your IDE and an configured application running on device. Then, as you are developing your XAML you can quickly do a compile and publish. When the IDE publishes an update, each subscriber running will update and display the result. Really cool.

There are two main parts to getting this set up

I. Install the Add-In within Xamarin Studio (On Mac)

Select Xamarin Studio -> Add-In Manager -> Gallery Tab. From there search for Forms Player, it should appear under Mobile Development

II. Create and Install a Forms Player application on device.

Here is where we set up the subscriber side of things. There are a few ways you could do this, including compiling the code from GitHub and installing it, but this approach is pretty simple.

1) Create a new cross platform Xamarin.Forms application. I would name it something like "Forms Player" or maybe equally memorable. PCL or Shared Project should be fine.

2) Add the Xamarin.Forms Player NuGet to your Android and iOS Targets. Right click both Android and iOS Projects-> Add-> Add NuGet Packages. Make sure in the bottom right you check the "Show pre-release" box.

3) Update  new App () in MainActivity.cs and AppDelegate.cs to be new Xamarin.Forms.Player.App ()






As a side note, you may need to modify some of the built references on the iOS project. When I set this up, it complained, initially, about duplicate references to System.Runtime, System.Threading and System.IO. Removing them from the References-> From Packages folder got it running fine.

4) Deploy this application to the devices/emulators you want to support. You will see a Home screen like this:

 

 

iOS on left, Android on Right

III) Start debugging your app

Now that you have these installed, what you will do is pair them. You do this by selecting the Forms Player menu and select Connect. This will create a running Session ID, which you will input in the running application you have previously installed above.

Open up the Forms application you want to work on. When you open the .xaml file, you will notice that the "Publish" option from the Forms Player menu will no longer be greyed out. Each time you select publish, or hit the hotkey, while you have a .xaml file loaded in your IDE, it will load that current XAML to any device with the app running and session paired, and then preview it.

And there you go! Hopefully you found this useful and it will help you build and ship higher quality Xamarin.Forms apps faster.

Getting started with iOS Development- No more XML

Well, I finally am making the plunge. After weeks of postponing, delays, justification and just general laziness I pulled myself together and started the iOS side of development. For those that don't know me I have always had a preference to Android (or an irrational dislike of Apple and its products) so my desire to work on iOS definitely came with a bias against it.

That being said, as a developer with a background in .NET, C#, WPF and Android moving to iOS can be TOUGH. It is a very different paradigm shift to move from xml based UI development, which I have really grown to love, to iOS Storyboards, which still confuse me. Storyboards are built with a visual flow to them, this gives you a nice ability to get a good overview of the app and how it navigates but the individual details are not as easy to manage. Additionally, coming from a world of Layout Controls, moving to the paradigm of Auto-Layout and Constraints can also be a unique challenge. Overall the shift for me hearkens back to a day of WinForms development. It is definitely something new for me.

Much as before, this will likely see a few iterations as my knowledge grows. I decided to follow a similar pattern to how I built my Android UI, first loading the main character overview page, then start building it out from there. So after setting up my initial UI I found myself with this general starting point:

I'll deal with layout later.

The first challenge I ran into was a new paradigm for my drop down selection boxes. Where android has a spinner control that provides a drop down list for you to interact with, that is not something available on iOS.

They have a picker control instead, which is described as using "a spinning-wheel or slot-machine metaphor to show one or more sets of values". If you notice, I am using Text Field's for my data display since there was no "combo box". After some research I learned that iOS actaully has a pretty cool solution set up for something like this. What i needed to do was wire the Text Field input option to be a Picker control instead of the default keyboard input. iOS, in this regard, actually makes this quite simple to do. Text Fields, and many other controls, have a property called InputView which defines what control is the selected input. Keyboard is the default when nothing is set, so instead I set it to a created Picker Control, like so:

var racePicker = new UIPickerView (CGRect.Empty);
racePickerText.InputView = racePicker;

Then a picker control is displayed when we click the Text Field like so:

Overall this is a good start. Different from what we had before, but it works. This does bring up a couple more questions however, populating our data, binding it to the Text Field itself, and then dismissing our Picker when we are done.

1. Setting up the Data.
This is an area that is actually not as documented in Xamarin, but is something that needs to be learned. In Objective-C/Swift world the UIPickerView has two main sources for data and interaction. The Delegate and DataSource. The DataSource is, as you can guess, the data that is tied to the control. You can think of Delegates kind of like the controller layer, defining interaction. 

In Xamarin, both of these properties are exposed, as well as a hybrid Object called the UIPickerViewModel. This is something specific to Xamarin, but basically serves as a hybrid of the two previously mentioned properties and is more C# styled. I learned, over time, that this is a paradigm we do quite frequently but it is something we admittedly do not have as much documentation on. For the case of my application it served my needs. Knowing I had at least four different scenarios I wanted a data source for my object, I created a general PickerModel and overrode the defined methods to use my data, and then set my model in my picker control:

var model = new MyPickerModel (RaceHelper.GetAllRaces (), info.Race.Name);
model.OnPropertySelected += (object sender, EventArgs args) =>  
{
    racePickerText.Text = model.SelectedItem;
};
racePicker.Model = model;

The constructor is how I set my initial conditions, and then if you notice I have a defined PropertySelected event so that I can feedback to my UI when items are updated. Then I was able to get my data populating within my UIPickerView:

The final piece to the puzzle was dismissing the view. This took a bit of hunting and research and then I finally found the final piece. Along with an InputView, there is also an InputAccessoryView. This gives you the ability to add a toolbar to your InputView, giving additional functionality and methods of interaction, including a "Done" button in my case. Setup was actually pretty simple:

var toolbar = new UIToolbar (new RectangleF (0.0f, 0.0f, 50.0f, 44.0f));
var myButton = new UIBarButtonItem (UIBarButtonSystemItem.Done,
     delegate {
          this.racePickerText.ResignFirstResponder (); 
     });

toolbar.Items = new UIBarButtonItem[] {
     new UIBarButtonItem (UIBarButtonSystemItem.FlexibleSpace), myButton };

racePickerText.InputAccessoryView = toolbar;
And what this gives us is the final product here:

Next step will be to organize the code to be more clean/refactored but that will be for another time.

Again I apologize for lack of diligence in getting things posted, lots going on but hopefully I will get updates on a more regular pace once more as I dig into the world of iOS.

Android Code Review- BaseAdapters are your Friend

Well, I am finally forcing myself to make the jump to iOS, but that is taking more time than I anticipated. More on that in the first iOS blog post. I did spend a little time doing some code review, bug fixing and refactoring. In that process I had a great conversation with one of the other Success Engineers at Xamarin, Colby Williams, who gave me some good feedback and reviewed some of my code. I learned one really great nuget that is worth sharing as it is not immediately apparent when getting started with Xamarin from Android.

When using collection views, it is almost always best to subclass BaseAdapter rather than use any of the out of the box adapters provided by Android (ArrayAdapter comes to mind). I was using the default ArrayAdapter for all of my drop down spinner controls and what I learned is most of the default Adapters provided by Android will give a potential performance hit because for each object in the list, an equal java object has to be created and maintained. This is due to how Xamarin and Android communicate with each other. For an in depth review, this document covers it well:

http://developer.xamarin.com/guides/android/under_the_hood/architecture

So what was happening was for every spinner I created using an Array Adapter, a general C# and Java object were being created and maintained, creating overhead. Instead, creating a BaseAdapter, the under the hood creates a single Java object that has a C# implementation within. Much better performance wise, fewer objects to maintain in memory.

My final code for the adapter is actually pretty simple:

public class SpinnerAdapter : BaseAdapter<string>
    {
        List<string> _items;
        Activity _context;
        public SpinnerAdapter (Activity context, List<string> items)
        {
            _items = items;
            _context = context;
        }

        public override long GetItemId (int position)
        {
            return position;
        }

        public int GetPosition(string selected)
        {
            return _items.IndexOf (selected);
        }

        public override string this[int index] {  
            get { return _items[index]; }
        }

        public override Android.Views.View GetView (int position, Android.Views.View convertView, Android.Views.ViewGroup parent)
        {
            var view = convertView;
            if(view == null)
            {
                view = _context.LayoutInflater.Inflate (Resource.Layout.spinner_item, null);
            }

            view.FindViewById<TextView> (Resource.Id.text).Text = _items[position];

            return view;
        }

        public override int Count {
            get {
                return _items.Count;
            }
        }
    }

Once I made that update, I noticed my views loaded much quicker.

Next time I am going to dig into iOS development, and why it can be a challenge. Given that iOS 9 just came out this past week, I am also using this as an "excuse" to learn iOS 9.

Android ListViews and Updating the Backend Data

I wanted to spend at least one more post to try to put my app in a finished state so there was a lot of time spent on both backend code and getting my skills list to display properly.

My first thought was to use a ListView to display all of my skills, it seemed logical. It was a of items, numbers and a checkbox. Time to brush off what I learned from custom spinner items. Creating adapters for your ListView is actually pretty standard as a lot of the time the default elements are going to not provide what you need.

The first step was to at least get my ListView organized and all my skills displayed. I already had all the hookups in place thanks to my work last week with implementing ViewPager. The first step was to create a new LayoutView, which housed my ListView. I then used a default ArrayAdapter to just grab a placeholder list of strings.


        public override View OnCreateView (LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
        {
            var root = inflater.Inflate (Resource.Layout.fragment_charsheet_skills, container, false);
            ListView view = root.FindViewById<ListView> (Resource.Id.skillsList);
            var skills = ((CharacterSheetActivity)this.Activity).CharacterInformation.Skills;
           view.Adapter = new ArrayAdapter<string> (this.Activity,Android.Resource.Layout.SimpleListItem1, skills);

            return root;

        }

 Pretty straight forward, and shows at least a starting point:
 

We have a successful ListView! Now to add the Custom Adapter. In this case, I want to display not only the name, but the ability mod score, whether or not the character is trained, and then the final value. (Mod + Proficiency)

The adapter is set up and in order. The first challenge I ran into was getting my items to not clump together. RelativeLayout was not really an option here, so a little searching I discovered one effective option was to use the "Weight" tag to give each item equal weight within the control. 

 





<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="horizontal"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:padding="5dp">
    <TextView
        android:id="@+id/skillName"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Placeholder"
        android:layout_weight="1" />
    <TextView
        android:id="@+id/modValue"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_weight="1"
        android:text="+3" />
    <CheckBox
        android:id="@+id/isTrained"
        android:layout_width="32.0dp"
        android:layout_height="wrap_content"
        android:layout_weight="1" />
    <TextView
        android:id="@+id/totalValue"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_weight="1"
        android:text="+5" />
</LinearLayout>

In theory that worked well, but then I realized I had a problem once I got the final result running.

Looks Perfect

Maybe I need to think this through...

As the weights are row specific, it does not help align each column. Once again, for implementation and times sake I decided to call that "good enough" for now. 

The next step was to work on my back end code. As can be seen in the above, I am hard coding all of my values, and no hookup event for the proficiency checkbox. This actually required a lot of back end work, which was good to revisit and clean up the data.

 Now, I will preface by saying I do not admit this code will be the best. I'm playing more of the functional over proper card here. As a side project it will regularly be a work in progress. 

I created both a Skill and SkillsList class on my back end. The reason for the latter is it gave me a collection that I could house some of the more static concepts like what skills have what ability mods, and a fully populated list of all possible names. Again, not proud of it, but its functional. Then, at launch all possible skills are preloaded based on starting stats. This gives me all my initial conditions that I access as accessor methods. (Loading data I will revisit at a later point).

From an input standpoint the two big changes I needed to make sure happened were 

a) update final values as proficiency was enabled
b) update mods when ability scores are changed.

For the first, I did an inline set of code, pretty straight forward.


proficient.CheckedChange += (object sender, CompoundButton.CheckedChangeEventArgs e) =>  
{ 
    CharacterSheet sheet = ((CharacterSheetActivity)_context).CharacterInformation; 
     sheet.Skills[position].IsProficient = e.IsChecked;
    skillMod.Text = sheet.Skills [position].TotalValue + ""; 
}

On the flip side, with all of my Attribute code, I added this line:

character.UpdateSkills (Attributes.AttributeName.STR);

Which is essentially calling an update method within my SkillsList:

public void UpdateSkillMod (Attributes.AttributeName type, int mod)
{
    foreach(Skill skill in _skills)
    {                
        if(skill.ModType == type)
        {
            skill.ModValue = mod;
        }
    }
}

This is simply an enumeration through all skills that updates the ModValue of the associated type. That gets us to our final version, which we will hold with for now.

On the back end I also did a lot of cleanup for better preparation for when I need to load character data. At this point I am going to call the Android version of the app in a good spot and now move to get an iOS skin running with this.

Implementing the Toolbar and Scrolling Tabs

After spending a lot of time working on what was essentially a single page view, I felt like I had enough blocked functionality to really start broadening my horizons. There is too much data on a single character sheet to warrant it all on one view, nor would that make for pretty UI Code.

As a reference, here is what we are basing everything off of, pulled straight from the Dungeons and Dragons Website

 

This does not include the spells page, that will be its own beast that I will tackle later, but there are some logical groupings of information that we can use. What makes the most sense is to add a Tab Control based layout to scroll through sections of information.

First step was the Toolbar. I wanted to try to use all the new latest and greatest and was previously using an ActionBar. Luckily James Montemagno gave a great overview for adding a Toolbar to your app to replace the ActionBar, I suggest starting with a read there:

https://blog.xamarin.com/android-tips-hello-toolbar-goodbye-action-bar/

From a visual side of things everything looked roughly the same, but gives me greater flexibility in the long run. Next step was to add new menu items. I have learned that Android really likes its .xml files and menus are no different. For now, we will start with a new, save and load button. For spacial consideration I am just showing the add button for now, but it gives the app a nice look I think:

 

I also am going to remove the floating action button for the time being. I have some ideas for it down the line, but likely will only resurface once I get a more complete product (much later).

The next step was to add a TabLayout to the toolbar. I also wanted to include both tap and swipe navigation as it adds a logical flow to the app. This is where I also had to learn about fragments and ViewPagers. This definitely took a bit of research as there were a number of parts to get a handle on.

From a high level overview, Fragments are a way for Android to both compartmentalize UI into component pieces, to allow you to better support multiple screen sizes, and just break down your UI easier. A good overview that helped me can be found here:

http://developer.xamarin.com/guides/android/platform_features/fragments/

To create my desired setup, this guide on the Android developer docs was highly valuable:

http://developer.android.com/training/implementing-navigation/lateral.html

You break it down by having your TabLayout add 2+ ViewPager objects to represent each tab. Each ViewPager object is going to be a unique Fragment on the back end, or basically a UI view. Really cool stuff.

So the first thing I need to do is set up each of my ViewPager objects, so that they are grouped together and can be "swipable". The following code handles all of that.

var viewPager = FindViewById<ViewPager> (Resource.Id.viewPager);
SetupViewPagers (viewPager);

private void SetupViewPagers(ViewPager viewPager)
{
      var adapter = new MyAdapter (SupportFragmentManager);
      adapter.AddFragment (new CharSheetOverviewFragment (), "Overview");
      adapter.AddFragment(new CharSheetSkillsFragment(), "Skills");
      viewPager.Adapter = adapter;
}

This will create my ViewPager object, where the SetupViewPagers method creates each individual Page, and then sets the adapter to group them together. The final result is a ViewPager object, or a number of views that are side by side and have built in scrolling. Pretty neat. SupportFragmentManager is a predefined Adapter provided by the Android Support Package that we need to set all this up. the viewPager resource is simply something that I added to my main .axml file that will house the ViewPager spells.

From there you are following the same process as normal. You create a Fragment .axml file and a correspoding Activity class to load it. The difference being instead of inheriting from "Activity" you are inheriting from Fragment. Your OnCreateView method inflates the fragment UI and returns the view.
   public override View OnCreateView (LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
{
     var root = inflater.Inflate (Resource.Layout.fragment_charsheet_overview, 
container, false);
     return root;
}

One of the cool side effects of using Fragments is they also maintain a reference to the parent Activity which loaded them. So in my case, the parent Activity, a CharacterSheetView has a loaded set of character Data. Each of my fragments can pull from that data by using this.Activity.

A view of what we see now can be found below, I have been updating some of the code to modify how my attributes are being displayed, moving from a TableLayout to GridLayout

I am going to spend a little more time polishing the attribute list and then actually look to start replicating this in iOS to help broaden my skillset. I do know that I will likely use a ListView for the skills so I may just tackle that next. We will see.