Using TEF in Xamarin Forms

TEF (Typed Extensibility Framework) is similar to MEF, but was designed to be flexible, customizable, and easy to implement. In this guide, we’re going to look at how to use TEF in a Xamarin Forms project. TEF is pretty easy to get started, but certain features are not available in a portable environment, which are in a Xamarin Android or Xamarin iOS project (for instance, the AppDomain is not portable, but is available in these projects). Therefore, we need to do some customization. To start, let’s go through the following steps:

Create a Project

In Visual Studio or Xamarin Studio, create a new portable or shared Xamarin.Forms project. TEF will work with either option.

Import TEF

Using Nuget, download the TEF package using Import-Package TEF via command line, or search for TEF in the Nuget Window Search Bar.

Add an AppDomain Assembly Loader

Or whatever other strategy you like to use. The following snippet uses the AppDomain to look for the loaded assemblies and find any ExportType or ExportDependency attributes. To do this, we need to create a class that implements TEF.Consumption.IAssemblyLoader. It will return a list of assemblies, and must exist in both the iOS and Android project.

Find your iOS and Android projects and create a new folder called “Library” or “Services”, or whatever you like to call it, and include the following code snippet below in each project. Note: if you are using a shared project, this may work by placing the reference there. I haven’t tried using a shared project.

[assembly:Dependency(typeof(AppDomainAssemblyLoader))]

public class AppDomainAssemblyLoader : TEF.Consumption.IAssemblyLoader
{
	public IEnumerable LoadAssemblies ()
	{
		return System.AppDomain.CurrentDomain.GetAssemblies ();
	}
}

I chose to use Xamarin’s DependencyService, which is a service locator, as the means to register and fetch this type (you’ll see the fetch later on). To register types, see my previous blog post, which explains how the assembly attributes are used.

Add a Consumer

A consumer is the component that takes the types and produces a dependency injection container. In this example, I’m using SimpleInjector PCL. Any container can be used, and you can find more about supporting containers via the Container Integration documentation. Note: it’s not complicated to create your own IConsumer class though; see the documentation for how.

Import Types

We need to add the TypeFactory code that ties all of these components together. In the App class that the Xamarin.Forms project creates, this code can exist in OnStart, or it can also be utilized with the Lazy class. I chose a different route: define it in the property of the App class:

public class App : Application
{
	private SimpleInjector.Container _container;

	public SimpleInjector.Container Container {
		get 
		{
			if (_container == null) {
				_container = TypeFactory.Configure ((c) => {
					c.AssemblyLoader (
						DependencyService.Get (DependencyFetchTarget.GlobalInstance)
					).Consumer (
						new SimpleInjectorConsumer()
					);
				}).Initialize () as SimpleInjector.Container;
			}

			return _container;
		}
	}

Here we use the TypeFactory to tie everything together. The configure method takes the assembly loader and consumer references, while the Initialize() uses this to construct the container. The container is returned and can be used in your app (weakly typed). In my example, to use the container in your application, use ((App)Application.Current).Container. And that’s all it takes to incorporate TEF into an assembly. The benefit is we can mark a type like:

[ExportType(typeof(ISomeType))]
public class SomeType : ISomeType
{

or as:

[ExportAssembly(typeof(ISomeType), typeof(SomeType))]

public interface ISomeType { }

public class SomeType : ISomeType { }

And these will be automatically consumed for us and put in our dependency injection container.

Introduction to Xamarin Forms

For the longest time, developers have dreamed to write one set of code to support multiple application platforms. PhoneGap was one product that achieved that dream; it only had one caveat: it isn’t native. PhoneGap runs within the operating system’s browser, essentially making it a localized web application. It’s certainly a valid option for developing mobile applications.

When it comes to Xamarin, the iOS and Android interfaces were separate, but code sharing could occur between the backend code, by using PCL’s, shared projects, or code linking. Either way, most of the code was separated, but only the UI code was differentiated.

In comes Xamarin Forms 3.0, a new way to share 100% of the code. Xamarin forms offers an API for building applications using pages or views. For instance, below is a sample page that works in both iOS and Android:

var page = new ContentPage {
    Title = "My Profile",
    Icon = "MyProfile.png",
    Content = new StackLayout {
        Spacing = 15, Padding = 25,
        VerticalOptions = LayoutOptions.Center,
        Children = {
            new Entry { Placeholder = "Name" },
            new Entry { Placeholder = "Address" },
            new Entry { Placeholder = "City/State" },
            new Button {
                Text = "Save",
                TextColor = Color.Black,
                BackgroundColor = Color.White }}}
};

Additionally, Xamarin Forms has content views that use a XAML interface with an associated code-behind, giving a WPF feel to application development. With this approach, you can create 100% SHARED CODE, a remarkable achievement. To get an idea of what Xamarin Forms can do, check out the online samples.

I plan to continue to write more about Xamarin Forms in the year to come. Stay tuned.

Xamarin Shared and PCL Projects – A Comparison

Developers have always had problems supporting multiple platforms in application development, mainly because even though a lot of the code was repetitive, there wasn’t many options available for code sharing. What would often happen is that developers (say wanting to support classes for an ASP.NET web site and a Windows Phone Library application) would write the code for one project and then link the file to the other project. This solved the problem, but adds the extra step of adding the files (plus potential synchonization issues if you forget to add the file). Microsoft offered up Project Linker, a free tool that linked code in projects together. This did work, and solved some of these problems. You were dependent on an external tool for that ability.

A while back, portable class library (PCL) support was added, which addressed this very need: provide the ability to create a project that can be shared across all of these different platforms. This works create to write common code like interfaces, DTO’s, and utility classes, but doesn’t necessarily cover platform-specific features.

When it comes to sharing code, PCL’s don’t quite stretch into the mobile arena, which is where Xamarin comes into play. Since it uses C#, Xamarin supports portable class library (PCL) projects in Visual Studio, and have recently added support within Xamarin Studio. But they also have provided another feature to address code sharing: shared projects. Xamarin documented how shared projects work with great detail. Essentially a shared project works by copying its code into any project that references it. If you have an iOS, Android, or Windows Phone app, the code is copied to each of the projects that refer to it, and thus this shared code is pushed into (similar to how Project Linker works) the dependent projects. This is yet another way that project sharing can work within Xamarin.

Code-sharing probably provides a little more capability than PCL; PCL only contains a subset of assemblies it can refer to, and thus the sharing feature provides you with a little more capability, at the reduced cost of needing separate projects to compile the code into (although, you probably have a project setup for each environment anyway). The Sharing feature is just another tool available to developers to create great applications.

Launching the Browser in Android with Xamarin

If you like the Android interface and have used an app like Facebook or Twitter, you’re no doubt used to the ability to click a link and get a list of browser-based applications to choose from. This ability to choose your browser to open a link is a feature in Android called an “intent”. An intent is an asynchronous message to request some action on behalf of another application. Intents serve many purposes, such as sending data to Facebook, or a browser. Intents also navigate between activities in an application.

For sharing to a browser, it requires using a special intent with is the Intent.ACTION_VIEW in Android, or Intent.ActionView in Xamarin Android. This intent, along with the URL, signals to Android to open the requested resource in a browser. For instance, let’s take a look at the following method:

private void ShareToBrowser(string url)
{
	if (!url.StartsWith ("http")) {
		url = "http://" + url;
	}

	Android.Net.Uri uri = Android.Net.Uri.Parse(url);
	Intent intent = new Intent (Intent.ActionView);
	intent.SetData (uri);

	Intent chooser = Intent.CreateChooser (intent, "Open with");

	this.StartActivity(chooser);
}

In our utility method, from an URL string, we ensure there is an “http” prefix on the URL; otherwise, the intent doesn’t quite work right. From the URL, we create an Android URI, and pass it as the data of the intent. The constructor of the intent takes the name of an action, which in our case, is the view action. In most other common situations, we’d use the Send action. The View action is used for browsing, whereas Send is used for app sharing (to Facebook, etc.)

If we were to start the activity without the chooser, Android would pick the first browser installed and launch it. By adding a “chooser” intent, we get that nice “Open with” dialog, listing all of our installed browsers. And it’s that simple to launch the browser in our application.

If you are looking for a nice overview of intents, Lars Vogel has a nice overview available at Vogella.

UITableViews Part 3: Showing a View Over a UITableViewCell in Xamarin iOS

An iOS UI is comprised of a view, which is what the user sees, and a controller, which is the functional logic. A view can have one or many subviews, but this is not required. Within iOS, there are specialized controlles that work with a particular type of view. For instance, the UITableViewController works with a UITableView as it’s user interface.

Step 1: Initial Setup

Setup a UITableViewController, and a view and/or controller to overlay. There is nothing complex here, and I’m not going to go into any more specificity.

Step 2: Setup Globals

We’ll need a reference to our controller to overlay (within our custom UITableViewController class), so that we only have one static reference to use as the popup. I created the controller in the ViewDidLoad method.

private LinkItemActionController _actionController = null;
public override void ViewDidLoad ()
{
base.ViewDidLoad ();

_actionController = new LinkItemActionController ();
_actionController.View.Hidden = true;
//My own custom method
this.AddViewControllerToView (_actionController, this.View);

Step 3: Responding to the Selection

Now that we have a controller in place, anytime an item is selected, we need to change the current frame that the controller’s view draws in. On click of a cell, the UITableViewSource triggers the RowSelected delegate method. From here, we can notify the controller to draw the LinkItemActionController view within the bounds of the cell. Below is a snippet of how I do that.

//Data source for tableviewcontroller
protected class LinksSource : Nucleo.UI.BaseTableViewSource
{
public event EventHandler ItemSelected;

public override void RowSelected (UITableView tableView, NSIndexPath indexPath)
{
	var cell = this.GetCell (tableView, indexPath);

	var dataItem = this.GetDataItem (indexPath);
	if (dataItem == null)
		return;

	if (ItemSelected != null)
		ItemSelected (this, new SelectEventArgs { Cell = cell, DataItem = dataItem, IndexPath = indexPath });

	tableView.DeselectRow (indexPath, true);
}

}

//controller, responds to ItemSelected event
public partial class LinksController : Nucleo.Controllers.BaseUITableViewController 
{

void HandleItemSelected (object sender, SelectEventArgs e)
{
	var rect = this.TableView.RectForRowAtIndexPath (e.IndexPath);
	_actionController.View.Hidden = false;
	_actionController.View.Frame = rect;
	_actionController.RefreshUI(rect.Width - 40, rect.Height);

	_selectedItem = e.DataItem;
}

In this snippet, the UITableViewSource (from the snippet given in a previous post) notifies the controller that the row was selected. An ItemSelected event bubbles up to the controller, and the HandleItemSelected method handles loading the UI. First, it uses RectForRowAtIndexPath to get the underlying frame to use for the drawing. Next, the view is shown and given the cell rectangle. Lastly, a RefreshUI method does the actual drawing of the buttons, and we store the current selected item for safekeeping.

Step 4: Loading the Buttons

When I first learned how to frame a house, I learned about how to place the studs that support a wall every 16 inches, except for the second stud, which is 15 1/4 inches away from the first stud. The reason for this is simple: to make sure the plywall overlaps a stud evenly on both sides (essentially centering each end evenly over the stud). We’re doing something similar here; we’re going to try to render each button evenly over the cell row, but we have to offset the first button by half of the width to ensure each image appears correctly within its quarter segment (as there are 4 buttons, I broke each out evenly). To do this, I used the following code and a little bit of math to do it (this is our LinkItemActionController):

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

	this.View.BackgroundColor = UIColor.FromRGBA (255, 154, 35, 50);

	//TODO: display evenly-spaced buttons
	_cancelButton = this.CreateButton ("icon_back.png");
	_cancelButton.TouchUpInside += HandleCancel;
	this.View.AddSubview (_cancelButton);

	_shareButton = this.CreateButton ("icon_share.png");
	_shareButton.TouchUpInside += HandleShare;
	this.View.AddSubview (_shareButton);

	_deleteButton = this.CreateButton ("icon_delete.png");
	_deleteButton.TouchUpInside += HandleDelete;
	this.View.AddSubview (_deleteButton);

	_viewButton = this.CreateButton ("icon_view.png");
	_viewButton.TouchUpInside += HandleView;
	this.View.AddSubview (_viewButton);
}

public void RefreshUI(float availableWidth, float availableHeight)
{
	var quarterWidth = availableWidth / 4f;
	var centerWidth = quarterWidth / 2f;
	var currentY = (availableHeight - IMAGE_SIZE) / 2f;
	var currentX = centerWidth - (IMAGE_SIZE / 2f);


	_cancelButton.Frame = new RectangleF (currentX, currentY, IMAGE_SIZE, IMAGE_SIZE);
	currentX += quarterWidth;

	_shareButton.Frame = new RectangleF (currentX, currentY, IMAGE_SIZE, IMAGE_SIZE);
	currentX += quarterWidth;

	_deleteButton.Frame = new RectangleF (currentX, currentY, IMAGE_SIZE, IMAGE_SIZE);
	currentX += quarterWidth;

	_viewButton.Frame = new RectangleF (currentX, currentY, IMAGE_SIZE, IMAGE_SIZE);

}

The IMAGE_SIZE constant is 44 pixels. As a rough example, assume that the total width is 400 pixels. Each quadrant is 100 pixels wide. We want the button to be in the center of the quadrant, so we subtract half of the 100 pixels to arrive at 50. We also need to ensure that we factor in the button image width, which is 44 pixels wide; not factoring this in would throw off the centering, and therefore the algorithm also subtracts another 22 pixels, arriving at a first coordinate value of 28,0 (the cell happens to have a height of 44, so no offset there). Every image afterward has a value of 100 added to it, leaving the next coordinates as 128,0; 228,0; 328,0, with the end of each image finishing at coordinates 72,0; 172,0; 272,0; 372;0.

Finish

Below is a snapshot of the finished product. While not the final color scheme and icon colors, it gives you an idea of what our final product has the potential to become.

iosviewoverscreenshot

UITableView Part 2 – DataSources and Sources

In every programming language and operating system, there is always a grid control, which needs data. How the grid gets it data varies slightly; however, conceptually the grid gets the data through a data source. Sometimes the data source is the raw data itself, and sometimes it’s a wrapper around the data, which the wrapper offers some additional functionality. In iOS, there are two ways to bind the UITableView, through a UITableViewDataSource object and a UITableViewSource object. Both forementioned classes, similar in nature, are delegate classes that act as an intermediary between the underlying data and the tableview. In iOS, a delegate is a construct much different from the class that drives the behavior of the tableview. In Xamarin iOS, the UITableViewSource is a class with a bunch of optional methods. Overriding particular methods allow a developer to tap into certain functionality of and receive feedback from the tableview.

This post is going to discuss how to bind to a UITableView, and assumes you are familiar with the basic features of iOS and the UITableView. To begin, in order to use a UITableViewSource for a TableView in Xamarin iOS, follow these steps.

First, create a new class that inherits from UITableViewSource:

public class MySource : UITableViewSource

Next, override the following method:

UITableViewCell GetCell (UITableView tableView, NSIndexPath indexPath)

The GetCell method is responsible for creating and populating a UITableViewCell that the UI will return to the current user, and may look like the following implementation:

public override UITableViewCell GetCell (UITableView tableView, NSIndexPath indexPath)
{
	var cell = tableView.DequeueReusableCell ("StringIdentifier");
	if (cell == null)
		cell = new UITableViewCell(UITableViewCellStyle.Default, "StringIdentifier");

	//Load data into cell from data source

	return cell;
}

First we see if a cell has already been created for this identifier. The iOS framework will try to reuse an existing cell if it’s already created. If it isn’t created, then the cell is instantiated and returned. Additionally, the RowsInSection method is used to determine the number of rows in the current section. RowsInSection is useful for grouping of tables (which is supplied in the constructor of the UITableViewController, but that’s for another discussion). When the table is grouped, the RowsInSection method needs to return the number of rows (in integer form) for the given groups at the specified index path (since the NSIndexPath contains the current section and the current data item pointers).

The GetCell and RowsInSection methods are the most critical methods because it controls how the data is loaded in the UI.

There are plenty of other useful methods to know about to. For instance, if you want to handle the click of a row, handle the RowSelected event:

public override void RowSelected (UITableView tableView, NSIndexPath indexPath)
{
    //DO something

    tableView.DeselectRow (indexPath, true); // iOS convention is to remove the highlight
}

The UITableViewSource has methods for overriding the height of the row, and header/footer (if using grouping), as well as change the current view used for the header and footer. For instance, the view could be changed to use an image as the header and footer, as I wrote about before.

Note that the UITableViewSource class doesn’t retain your data source; you need to store the data in a variable so it can be retrieved through the index path later. Also, note that the source needs to be created for every controller you may want to use it in, leading to a lot of repetition.

Now I’m not one for repetition; I really don’t like the idea of writing boilerplate code just for the sake of writing boilerplate code. Therefore, I decided to create a reusable base class that abstracts most of the functionality away. It takes away a lot of the repetitiveness, while also offering the full functionality. To use it, all you need to do is inherit from Nucleo.UI.BaseUITableViewSource, and override the GetCellIdentifier and PopulateCell methods, and set the Data or GroupedData properties (depending on whether the table is grouped or not). This means you really could define a UITableViewSource like:

public class MySource : Nucleo.UI.BaseUITableViewSource
{
    public override string GetCellIdentifier() { return "My"; }

    public override MyClass PopulateCell(UITableViewCell cell, T dataItem, NSIndexPath path)
    {
        //Cell is already dequeued or created, only populate the cell here
    }
}

The process of creating the cell is abstracted away for you; however, if you are using a custom cell (more on this later), then you can override the CreateNewCell class and return your custom cell, and cast the cell reference in the PopulateCell method. Additionally, all of the grouping functionality is handled for you automatically by setting GroupedData property; RowsInSection and SectionFor methods, all used for grouping, are already wired up.

If you want to view the full code sample, you can do so from here. You can also find my project where I have this code at my Nucleo Mobile bitbucket.org repository.

UITableView Part 1: Styling a Grouped Table

I’ve been struggling to come up with a good tableview design that looks decent and doesn’t use the existing vertical-striped background of the grouped table view. In playing around with the various settings, I found a few things I decided to post upon. While I’m not the greatest at UI design, and I’m not a graphic designer, I hope this may help you determine what you can tweak with the UITableView. Note that I’m using Xamarin Studio and C#, instead of Objective-C. However, what code I write should be very easily translatable.

To start, the grouped tableview provides a header/footer with a series of rounded corner tables. It also naturally applies a padding to put spacing on the left and right side. In searching around, I found a good resource to remove this padding and “lengthen” the table to take up the full screen. To do this is very simple; simply apply a Frame with an added width, such as the following.

this.TableView.Frame = new RectangleF (
  this.TableView.Frame.X - 20, 
  this.TableView.Frame.Y, 
  this.TableView.Frame.Width + 40,
  this.TableView.Frame.Height);

This code runs in the ViewDidAppear method. Notice the subtracted width, removing the default width of the frame by twenty and adding 40 to the width, which expands the table to the entire frame.

The key is adding the rounded header. The first approach I’ve seen is to use a custom cell image for the top and bottom rounded corners. This certainly works as an approach to rounding. The alternative approach I’ve taken is to create a custom header and footer, like the following below:

public override UIView GetViewForHeader (UITableView tableView, int section)
{
	var root = new UIView ();
	root.Frame = new RectangleF (20, 0, 320, 30);

	UIImage img = UIImage.FromFile ("tableroundedtop_iphone.png");
	var imgView = new UIImageView (img, img) { Frame = root.Frame };
        root.AddSubview(imgView);
	.
	.

        return root;
}

In this code above, the root view comprises of a UIImageView as it’s child. A second child, a label, is also added and centered within the header, which worked from utilizing a need trick, as shown here:

var label = new UILabel { Text = "HEAD", BackgroundColor = UIColor.Clear };
label.SizeToFit ();
label.Center = root.Center;

First, the label adds the text and color information. Secondly, the SizeToFit() method sizes the label appropriately based on the size (font width and font size) of the text. Using the Center property, which returns the center of the object, the label’s center now becomes the root control’s center, which in effect centers the element. Very interesting.

To size the header and footer, we can override the GetHeightForHeader and GetHeightForFooter:

public override float GetHeightForFooter (UITableView tableView, int section)
{
	return 60;
}

The value returned becomes the height of the cell; sometimes the content of the footer stretches to meet the height; but note in the code above, we define a Frame of only 30 pixels high. The Frame essentially controls the area the view will draw in; the footer specifies that it will draw in the first 30 pixels. With a height of 60 pixels for the footer, a 30 pixel space fits within each tableview, as you’ll see in the image.

How do we style the table cells? There are several options. Depending on the style of the table, such as Default style, you can style the cell directly by setting it’s BackgroundColor to the TextLabel label control, or on the cell. Additionally, you can set the BackgroundView property on the cell itself and supply a view to use as the background (which can be an image, etc.), as another alternative.

Also, to change the grouped table background and remove the vertical striping, you can use the following code to set a static color for the table, but remove the background view.

this.TableView.BackgroundColor = UIColor.White;
this.TableView.BackgroundView = null;
this.TableView.Opaque = false;

The final result? Not the prettiest, but at least it was a good learning lesson.

iOS Grouped UITableView

Using JSON in Facebook C# API without the need for dynamic

If you happen to look at a lot of the examples that the Facebook C# API uses, you’ll notice a some of examples utilize the dynamic keyword (another example). This makes sense because it’s supported by the C# language and is a very nice feature to use.

In case you didn’t know, dynamic defers any type checking until runtime; this means that you can dynamically refer to a type, without intellisense in the Visual Studio designer, only to be met with type checking at runtime. If you call a property or method that doesn’t exist on an object reference, for instance, an exception will be thrown at runtime, but the code will still compile.

Recently, I’ve been using Xamarin Android and iOS frameworks for developing mobile applications, and I stumbled upon a limitation: dynamic is not supported, which this code broke when I tried to port it from Android to iOS:

var attributes = fb.Get<IDictionary<string, object>>("/me?fields=id,name,first_name,last_name,picture");
.
.

if (attributes.ContainsKey ("picture"))
{
   dynamic pictureObj = attributes["picture"];
   if (pictureObj != null) {
      dynamic data = pictureObj ["data"];

      if (data != null)
         pictureUrl = data ["url"].ToString ();
   }
}

The facebook API returns the current user’s picture as a complex object, that is represented by the following:

picture: { data: { url: "urltoimage" } }

That’s not all that comes along, but is mostly what we care about for this discussion. Anyway, to parse it using dynamic created a problem in iOS, as this generated errors. The solution was to use the following instead:

if (attributes.ContainsKey ("picture"))
{
   var pictureObj = attributes["picture"] as Facebook.JsonObject;
   if (pictureObj != null) {
      var data = pictureObj ["data"] as Facebook.JsonObject;

      if (data != null)
         pictureUrl = data ["url"].ToString ();
   }
}

The Facebook C# team does not want you using JsonObject directly, which is why it doesn’t show up in intellisense, but it is supported, and is the only representation of an object that allows you to easily extract the URL from the picture object, without a lot of reflection. This then works seamlessly in both Android and iOS.

Utilizing the Android Options Menu

You may have noticed the three button icon in the lower right-hand corner of the window, the options button, that Android provides to you within the context of an application. For many applications, this provides the options available for the current view. The options provided within the current view are customizable from within the activity. The Activity has two methods that work with the options menu, which are:

– OnCreateOptionsMenu
– OnOptionsItemSelected

The first method creates the instance of the menu, while the second method actually controls what happens when a menu item is selected. To begin, let’s create a menu:

public override bool OnCreateOptionsMenu (IMenu menu)
{
	menu.Add (0, 0, 0, "Fragment Demo");
	menu.Add (0, 1, 1, "Maps Demo");
	menu.Add (0, 2, 2, "Webs Demo");

	return true;
}

Here we have some menu items being added to the menu. Each of the items is a textual item that points to a specific demo in a demo app I’ve created. When you select the menu item, the actual text of these items appears in the bottom menu (note that images can also be used within the menu item). This method has many overrides, but the override I used has two methods, described as the following:

– groupID – The ID for the grouping of menu items.
– itemID – The ID of an item for the item in the list; this is a generic ID you assign to your item, used next.
– sortOrder – The order to display within the list.
– text – The text of the item.

On selecting an item, the ItemID is passed to the caller and available for the following type of logic:

public override bool OnOptionsItemSelected (IMenuItem item)
{
	if (item.ItemId == 0)
		StartActivity (typeof(FragmentDemoActivity));
	else if (item.ItemId == 1)
		StartActivity (typeof(MapsActivity));
	else if (item.ItemId == 2)
		StartActivity (typeof(WebsActivity));
	else
		return base.OnOptionsItemSelected (item);

	return true;
}

Each option starts an activity using the StartActivity method on the given activity. The item ID is used to differentiate between the menu item selected; otherwise, if none are selected, the base behavior is used.

See how simple it is to add items to the options menu? And in case you are wondering, this translates pretty well to the Android equivalent, sort of. From the Android documentation, you can see we have the same two methods; the only differential is that Android uses resource ID’s in place of the item ID’s, and that a menu inflater is used to load the menu items. All the menu inflater actually does is take a given XML file, and transform them into menu items, as we have done above. The process between the two options is pretty similar.

Develop Applications With Xamarin on a Mac

I wanted to start getting into mobile development, so to begin my mobile application development journey, I bought a Mac Mini computer and monitor. If you have come from a pure Windows environment like I have, and only have briefly worked with Macs in the past, there are some things you have to get used to, but all in all it’s not that bad. Once you get your computer setup and associated to an email account, you can begin setting up your Mac. The Mac ties into the Mac app store, where you can download or purchase apps similar to the app store on an iPad or Android device. It can also install programs, so you can install programs like Oracle VirtualBox or Parallels for virtualization (meaning you can get Windows back :-D), or anything else.

To begin using Xamarin, you’ll have to use Xamarin studio, which can be run on the Mac Mini. There are some pre-requisites, but the Xamarin installer manages most of them. There was one pre-requisite I had missed before I setup Xamarin: XCode. To do iOS development, you need XCode downloaded and installed. I didn’t know at the time, and installed it after, which still worked fine, no problems.

The installer works pretty smoothly, though I had one weird message popup. It was installing the Java SDK, and the message told me to leave the popup notification open until after the Java SDK was completely installed. I let the window wait for a while, and eventually clicked it. What I believe the message meant was click this to continue on, and I got caught up in the wording (don’t remember it exactly). In case you run into that.

Xamarin has been pretty smooth, and the studio works similarly to Visual Studio; however, it is missing some nice features that Visual Studio has. Still, it gets the job done. You can add external DLL’s in the same fashion as Visual Studio, plus utilize the Xamarin components store, which allows you to download free or paid add-ons to Xamarin.

I’ll be posting about Xamarin in the future, and more about mobile on this blog. I won’t leave out the web, after all I named the blog “On All Things Web” for a reason 🙂