When the row is selected, a new search is issued and the resulting images are updated in the UICollectionView. To connect the selection in the UISplitViewController’s master controller, which is an MT.D DialogViewController in this case, to the UICollectionViewController contained in the UISplitViewController’s detail controller, an event is raised when a row is selected:

public AnimalsController () : base (null)
{
    Root = new RootElement ("Animals") {
        new Section () {
            from animal in animals
            select (Element) new StringElement(animal, () => {
            if(AnimalSelected != null)
                AnimalSelected(this, new AnimalSelectedEventArgs{Animal = animal});
            })
         }};
 }

Then the UISplitViewController’s implementation handles this event to communicate to the UICollectionViewController:

animalImageController = new BingImageGridViewController (layout);

animalsController.AnimalSelected += (sender, e) => {
    animalImageController.LoadImages (e.Animal);
};

In the LoadImages method, the UICollectionViewController calls Bing for the selected item and uploads the UICollectionView when the data is returned by calling ReloadData:

public void LoadImages (string search)
{
    UIApplication.SharedApplication.NetworkActivityIndicatorVisible = true;

    bing = new Bing ((results) => {
        InvokeOnMainThread (delegate {
            imageUrls = results;
            CollectionView.ReloadData ();
            UIApplication.SharedApplication.NetworkActivityIndicatorVisible = false;
        });
    });

    bing.ImageSearch (search);
}

The sample is available at https://github.com/mikebluestein/BingImageGrid/tree/master/BingImageGridSplit

Note: you’ll need a Bing API key, which you can get at http://datamarket.azure.com

Consuming the Bing service with Xamarin on iOS can be accomplished just like anywhere else C# is available.  The UI here consists of a UICollectionView, using a UICollectionViewFlowLayout to achieve the grid display. Programming against a UICollectionView is very similar to using a UITableView, the big difference being that UICollectionView works with a layout class to achieve any layout you desire. iOS provides a very flexible UICollectionViewFlowLayout class that can be used  when a line-based layout is needed. Also, you can subclass UICollectionViewLayout directly as well to implement layouts that aren’t line-based.

You can get the code for this example here: https://github.com/mikebluestein/BingImageGrid

To run the exmaple, you need to sign up for an API key from the Windows Azure Marketplace.

For more information on using Collection Views, see this article in Xamarin’s Developer Center:

http://docs.xamarin.com/ios/tutorials/Introduction_to_CollectionViews

6/26 – Buffalo http://www.meetup.com/MSDevWNY/events/67359302/

6/27 – Rochester http://vduny.org/FutureMeetings.aspx

6/28 – Syracuse http://www.cnydevelopers.net/

I’ll be giving a presentation on using the Xamarin.Mobile API for cross platform, native mobile development with MonoTouch, Mono for Android and Windows Phone at New England Code Camp 17 on March 31.

I’m honored to be speaking at the Voices That Matter: iOS Developers Conference in Boston November 12-13. The conference organizers sent me a speaker’s priority code to pass along, which is good for $150 discount off the price of the core conference. The discount even applies in addition to the early bird pricing. My code is BSTSPK6. Also, I’ll receive $50 for every person that registers with my code, the proceeds of which I will be donating to the Jimmy Fund. I hope to see you at the conference in November.

• There are many existing customers of MonoTouch.
• The community around MonoTouch loves the product.
• There have been some nice success stories recently of apps built with MonoTouch.
• The team that developed MonoTouch and Mono for Android are top-shelf developers.
• Several new books were near release for MonoTouch and Mono for Android.

I got involved with MonoTouch at the beginning of the first beta. I had already been doing some iPhone work with Apple’s tool chain and was (and still am) quite happy with it, but since I have always liked the C# language and .NET, I thought this would be an interesting technology to try out. Initially I was mainly intrigued with the fact that they could even create such a product from outside of Apple. As I learned more about it, I was nothing but impressed with how nicely they blended the C# language with CocoaTouch. All the knowledge I had from the Objective-C side was totally applicable, but I suddenly could bring other technologies to the table, such as being able to take advantage of nice C# language features like Linq, the ability to reuse non-UI code and additional library support via Mono’s implementation of the .NET framework class libraries.

As the technology builds on Apple’s stack, I didn’t have to trade away platform capabilities in any way. At the same time, I found a vibrant community of like-minded developers both from the Mono team as well as outside. I was having such a good time with the technology and the community that I decided to take some time to write about it a little bit on this blog, which eventually led to a book project with Addison-Wesley. I couldn’t have been more excited.

Then, in April of last year, Apple introduced licensing changes that effectively prohibited the use of technologies such as MonoTouch. Although in practice nothing ever got rejected for being built with MonoTouch, the looming threat of this resulted in my book project being placed on hold. I kept doing MonoTouch on my own, because I truly enjoy using it and participating in the community. However, business interests that I was doing MonoTouch development for, quite reasonably, could not proceed with such ambiguity, resulting in my moving some work over to Objective-C.

As you may imagine, I was pretty disappointed by all this, but then late in the summer, Apple changed the licensing again and everything was set back in motion. Excited as ever, I turned my attention back to reworking the parts of the book I had already written for the changes that came out over the time I was in limbo, and proceeded working on the remainder of the book. This work took me up to the end of last year, with the technical review following earlier this year. The book has entered the production process with my publisher and I’m proud of the result and grateful for all the fine people that helped me along the way. My publisher was planning a summer release, which would put the book out around the time of the upcoming Monospace conference. Things were looking great.

Then all these great Mono developers got laid off. First and foremost, I feel awful for any of the great people on the Mono team. They do spectacular work and provide amazing passion with everything they do. Such a team should have a better fate. As it turns out they just may.

Never one to give up so easily, not in the face of licensing issues and not even now with the entire team being dismissed, Miguel and his team are spinning up a new company, Xamarin, to continue what they started. He announced, among other things, that they would be bringing a new iOS product to the market that will be compatible with MonoTouch. This leads me to the current plan for my book.

UPDATE: My publisher has decided to send the book to print. It will be in available in bookstores by late July.

After discussing all the options with my publisher we have decided to go forward with the book in electronic form for now. We will be holding back from doing a print copy until more details emerge regarding Xamarin’s new offering. If we were to go ahead and print the book now it would be, well, printed. By sticking with an eBook we can make the information available to the many existing people using MonoTouch and still potentially offer an updated version for the new product in the future. I’m personally looking forward with great excitement to see what Miguel and his team create next.

Preview

 

To use Bonjour with MonoTouch, you deal primarily with two classes, NSNetService and NSNetServiceBrowser. NSNetService is used to publish and resolve services. NSNetServiceBrowser, as the name suggests, allows you to browse for services. Once you have discovered a service via a browse, you resolve it in a separate operation, after which you can implement whatever networking code you like to communicate with the service.

In this simple example I publish a service when the application finishes launching and browse from a view controller that includes a table and a text view. The table displays each service as it is discovered. Selecting the row in the table associated with a particular service calls resolve on the service. Adding, removing and resolution of services is logged in the text view.

Here’s the relevant code that does the service publication:

        NetDelegate _netDel;
        NSNetService _ns;

        void InitNetService ()
        {
            _ns = new NSNetService ("", "_testservice._tcp", UIDevice.CurrentDevice.Name, 9999);
            _netDel = new NetDelegate ();
            _ns.Delegate = _netDel;
            _ns.Publish ();
        }

        class NetDelegate : NSNetServiceDelegate
        {
            public override void Published (NSNetService sender)
            {
                Console.WriteLine ("published {0}", sender.Name);
            }

            public override void PublishFailure (NSNetService sender, NSDictionary errors)
            {
                Console.WriteLine ("publish failure {0}," + sender.Name);
            }
        }

The browsing is done by calling the NSNetServiceBrowser’s SearchForServices method. I keep a list of NSNetServices as they are discovered in the FoundService callback and register for the AddressResolved event. Similarly, I remove them from the list via ServiceRemoved. Each service is registered to an AddressResolved handler as it is found. The resolve call, something you would do when you want perform actual networking calls with the service, is made here in the UITableViewSource’s RowSelected implementation. When the callback to ServiceAddressResolved happens, you’ll have an NSNetService complete with information that you can use to perform networking as you see fit.

Here’s the code for the controller with the service browsing and resolution:

    public partial class TestViewController : UIViewController
    {
        List _serviceList;
        NSNetServiceBrowser _netBrowser;
        ServicesTableSource _source;

        // constructors omitted for brevity …

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

        internal void InitNetBrowser ()
        {
            _serviceList = new List ();
            _netBrowser = new NSNetServiceBrowser ();
            
            _source = new ServicesTableSource (this);
            servicesTable.Source = _source;
            
            _netBrowser.SearchForServices ("_testservice._tcp", "");
            
            _netBrowser.FoundService += delegate(object sender, NSNetServiceEventArgs e) {
                
                servicesTextView.Text += "\r\n" + e.Service.Name + " added";
                
                _serviceList.Add (e.Service);                
                e.Service.AddressResolved += ServiceAddressResolved;
                
                //NOTE: could also insert and remove rows in a more fine grained fashion here as well
                servicesTable.ReloadData ();
            };
            
            _netBrowser.ServiceRemoved += delegate(object sender, NSNetServiceEventArgs e) {
                
                servicesTextView.Text += "\r\n" + e.Service.Name + " removed";
                
                var nsService = _serviceList.Single (s => s.Name.Equals (e.Service.Name));
                _serviceList.Remove (nsService);
                servicesTable.ReloadData ();
            };
        }

        void ServiceAddressResolved (object sender, EventArgs e)
        {
            NSNetService ns = sender as NSNetService;
            
            if(ns != null)
                servicesTextView.Text += "\r\n" + ns.Name + " resolved";
            
            // at this point you could use any networking code you like to communicate with the service
        }

        class ServicesTableSource : UITableViewSource
        {
            TestViewController _controller;
            const string SERVICE_CELL_ID = "servicecell";

            public ServicesTableSource (TestViewController controller)
            {
                _controller = controller;
            }

            public override int RowsInSection (UITableView tableview, int section)
            {
                return _controller._serviceList.Count;
            }

            public override UITableViewCell GetCell (UITableView tableView, NSIndexPath indexPath)
            {
                var serviceCell = tableView.DequeueReusableCell (SERVICE_CELL_ID) ?? new UITableViewCell (UITableViewCellStyle.Value1, SERVICE_CELL_ID);
                
                NSNetService ns = _controller._serviceList[indexPath.Row];
                
                serviceCell.TextLabel.Text = ns.Name;
                
                return serviceCell;
            }
            
            public override void RowSelected (UITableView tableView, NSIndexPath indexPath)
            {
               NSNetService ns = _controller._serviceList[indexPath.Row];
               ns.Resolve(60);
            }
        }
    }

Here’s the app running on the device while another instance is running in the simulator:

You can download the sample project here.