Skip to content


Thoughts on the Day of Mobile conference

Here is a collection of thoughts that I had about the Day of Mobile conference held at IIT last Saturday.  This was the inaugural conference put together by the Tech in the Middle guys, and I thought that they did a great job.  I look forward to seeing what they do next.

Overall Themes

Two main themes that emerged during the sessions: the future of mobile is web-based apps rather than device specific apps, and the road to mobile riches probably doesn’t run through an app store.

Multi-platform development is hard

Certainly scenarios exist where multi-platform apps make sense, but it is imperative that the risk/reward ratio be in your favor to have a chance to be successful.  Don’t underestimate the amount of effort and headaches that developing and supporting multi-platform apps will create.  Going the mobile web app route has it’s limitations, but it is the closest thing to “write once, run anywhere” that mobile has.

Cool Tools

Really cool tools like PhoneGap and jQTouch are out there that help lower the barriers to making apps and, in the case of PhoneGap, multi-platform apps.  Both tools have been released under MIT licenses and are free to use.

One Man’s Secret Sauce for Success

David Whatley gave a funny presentation that provided a lot of laughs and some great insights into how the iPhone app store works.  Even better was his ability to back up what he was saying with some real sales data and numbers.  His secret sauce for success:  PR, code re-use, and playing to your strengths.

App stores are glorified catalogs

Standing out or even being noticed amongst all the other apps is extremely difficult.  Relying only on the app catalog to drive sales is effectively a “post and pray” strategy akin to trying to win the lottery.  Try to find a niche and solve a problem.  Focus on creating value for markets not just an app for it.  Mark Murphy described many ways to make money in mobile other than direct app sales during his talk and in a series of blog posts about Android Business Models.

Links

Books Recommended During the Conference

Overall, the signal-to-noise ratio at the conference was good but not great.  I did manage to glean at least one or two new ideas from most of the sessions I attended, and it was great to see the enthusiasm that the Chicago tech community has for events like this.

Posted in conferences, dayofmobile, mobile. Tagged with , , , , , , , , , , , , , , , , , , , , .

Monotouch Binding Gotcha

I stumbled across a subtle gotcha while exploring binding Objective-C types in MonoTouch.  As luck would have it, someone else did also and posted a question about it on the MonoTouch IRC channel.  The poster of the question eventually came across the answer and shared it there, and I am going to post it here in case anyone else makes the same mistake and is looking for some answers.

I was following along with the documentation for binding new Objective-C types on the MonoTouch site, and as a way to ease into the binding process, I chose a class to define from the CloudMade SDK that I am looking to expose in MonoTouch.  The class selected was the BBox class (bbox.h) and I went about creating the following API definition shown below:

using System;
using MonoTouch.Foundation;
using MonoTouch.ObjCRuntime;

namespace CloudMade
{
    [BaseType(typeof (NSObject))]
    interface BBox
    {
        [Export("westernLongitude")]
        float WesternLongitude {get;set;}

        [Export("southernLatitude")]
        float SouthernLatitude {get;set;}

        [Export("easternLongitude")]
        float EasternLongitude {get;set;}

        [Export("northerLatitude")]
        float NorthernLatitude {get;set;}

        [Export("asString")]
        string AsString();
    }
}

Once completed, I saved it as BBox.cs and attempted to generate the bindings by invoking btouch on the file.  You can see below the unsuccessful message I received.
 
$ btouch BBox.cs
/var/folders/E4/E44PAZnZGKGpVrmseo2N3++++TI/-Tmp-/9qgrm9nm.lnv/CloudMade/BBox.g.cs(46,71): error CS0117: `CloudMade.BBox' does not contain a definition for `Messaging'
/var/folders/E4/E44PAZnZGKGpVrmseo2N3++++TI/-Tmp-/9qgrm9nm.lnv/CloudMade/BBox.g.cs(28,30): (Location of the symbol related to previous error)
/var/folders/E4/E44PAZnZGKGpVrmseo2N3++++TI/-Tmp-/9qgrm9nm.lnv/CloudMade/BBox.g.cs(57,71): error CS0117: `CloudMade.BBox' does not contain a definition for `Messaging'
/var/folders/E4/E44PAZnZGKGpVrmseo2N3++++TI/-Tmp-/9qgrm9nm.lnv/CloudMade/BBox.g.cs(28,30): (Location of the symbol related to previous error)
Compilation failed: 2 error(s), 0 warnings
btouch: API binding contains errors.

After looking at the errors and seeing the `CloudMade.BBox’ does not contain a definition for `Messaging’ message, it looked as if I was missing a using statement.  However, this was not the case as Messaging is a class in the MonoTouch.ObjCRuntime namespace and that namespace was already included in the using statements.  The problem actually turned out to be that the interface had the same name as the file and that had caused the issues shown above as the temporary classes generated during the process caused conflicts.  The solution to this issue was as simple as renaming the file to something other than whatever the interfaces you are defining are named.
 
So the moral of the story is:

Do not give the file that the API definition is being saved in the same name as one of the interfaces that you are defining.

Steer clear of that and you’ll be binding Objective-C types with ease.

Posted in Uncategorized. Tagged with , , , , , .

Nexus One – First Impressions

My thoughts on the Nexus One and the Android OS?  I like it.  A lot.

Likes:

  • Speed.  I have the older iPhone 3G hardware and from a user experience perspective it was not that bad.  When compared to the Nexus One, however, it is down right sluggish.  This probably isn’t as big of a factor when comparing a 3GS versus Nexus One, but for someone coming from a 3G iPhone, it is a huge plus.
  • Being able to run apps in the background.  Browsing the web while streaming Pandora and downloading an app in the background works flawlessly and shows no noticeable signs of lag or sluggishness.
  • The OLED screen is really nice.  Higher resolution and OLED screen looks great in low-light situations and is supposed to save precious battery by not drawing less power than normal LCD screens.
  • The Android OS is pretty sweet.  It has a lot of nice features like the status bar, an active “desktop” that you can put interactive widgets on as well as app icons, and an easy way to get music and files on and off the device.  
  • Integration with Google Apps is fantastic as expected.  I love getting mail and talk updates in the status bar and the overall experience with the apps on the Nexus One is better than on the iPhone.

Dislikes:

  • Cut and Paste is clunky.  I can see why Apple needed to spend awhile working out the UX issues before rolling it out.
  • The touch interaction with the device has not been as good as the iPhone in my experience.  I am not sure where the blame lies (hardware or software), but I sometimes find it difficult to select elements in the UI.  This is not something that occurs frequently, but in the short time I’ve owned the device, it has occurred enough to be noticeable.
  • 4GB of storage out of the box is lacking.  It is an easy upgrade but given the amount of money that Google is charging for the device, this seems like they are skimping here.
  • The Android Market place experience is integrated nicely but isn’t as tightly integrated as the iTunes App Store.  This is arguably a good or a bad thing depending on how you look at it.  As a user this is a bad thing since it makes finding and buying apps more difficult than just popping open iTunes.  I’ve found the Android Marketplace, both on the phone and the web, hard to browse.

There are a few negatives that I can’t pin exclusively on the device but are still worth noting.  I have been using my AT&T SIM with the Nexus One and most likely will do so until my contract is up in a few months.  With that caveat out of the way, the talk quality seemed poor and the phone gets really hot when talking for periods greater than 10 minutes.  I hesitate to even mention these issues since I am not using the phone on the network it was intended, but  I know there probably are others considering doing what I did, and this feedback might help if someone is on the fence.

The Nexus One is exactly the kind of phone and competition that was needed to push Apple.  I strongly recommend anyone looking for a smartphone to give it serious consideration before running out and getting an iPhone.

Posted in nexus one. Tagged with , , , , , , , , , , , , , , , , , , , .

iPhone Wireframes

I stumbled across a great collection of iPhone wireframe templates tonight while going through my feeds.  It got me thinking about the process I’ve been using to layout and design the app I am working on.

I’ve been using regular 3 x 5’ notecards to sketch out different screens for the iPhone app I am working on.  On the ruled side I’ll scribble notes and call out must/should/wish components of the screens to help prioritize features.  On the blank side I’ve been sketching out wireframes of the screens to help get a feel for the UI and flow of the app.

cards_laid_out

I’ve played around with Balsamiq and, while the tool is fantastic, I find myself still partial to the notecards.  With the same rough dimensions of the iPhone and the flexibility of being able to quickly rearrange and reorder the screens, the cards suit my preferences as a visual-spatial learner well. 

As with most tools and techniques, personal preference plays a large role in how and when they’re employed.  I always enjoy checking out how other people work and try and steal glean ideas from them.  I’ve found the following blogs pretty useful for design, usability, and UX.  I hope they help inspire you to create something cool.

I ♥ wireframes
information aesthetics
everydayUX
Sender 11

Posted in design, iphone, wireframes. Tagged with , , , , , , , , , , , , , , , .

Monotouch Quickie : UIPasteboard Snippet

Came across the need to plop a string onto the clipboard (aka UIPasteboard) programatically last night and hit up the MonoTouch docs to see what was involved.  It wasn’t readily apparent what would work for the string expected to be passed as the SetValue method pasteboardType argument.  Turns out, after digging into the official Apple docs, the string you need to provide is the Uniform Type Identifier (UTI) that corresponds to the data type being passed (in my case “public.utf8-plain-text”).  For my future reference (always seems to take longer to find things at the iPhone doc site) here is a table of the relevant UTIs that might come in handy in the future.

string public.utf8-plain-text
JPEG public.jpeg
PNG public.png
Url public.url

 

And for good measure here is a snippet that shows putting a string on the general clipboard and reading it off.

string clipboardText = "Copy and Paste Me!";

UIPasteboard.General.SetValue(clipboardText,
"public.utf8-plain-text");
string actualClipboardText = UIPasteboard.General.GetValue("public.utf8-plain-text");

Assert.AreSame( clipboardText, actualClipboardText.ToString());

Enjoy.

[Updated(1/30/2010): Replaced NSStrings out with strings]

Posted in UIPasteboard, monotouch. Tagged with , , , , , , , , , , .

Chatsworth House Keeping and Update

I just moved Chatsworth from Google code over to its new home on github.  I’ve got a couple more features in mind and figured now was as good a time as any to make the switch.  I already host my iPhone samples and some personal projects on github and, given the smoother branching and merging experience of git, I think it will be more conducive to spiking some features and trying some ideas out.

As for the chatbot, I’ve recently added a link logging feature.  Any URL sent to the chatroom now gets logged to the sqlite database.  Users can query the database right from the chat window by entering /links <number of previous links to return> and the links, timestamp and the person who sent it will be sent in an individual IM to the requestor.

Going forward, the two areas that I think need the most improvement are installation and documentation.  The majority of the questions and feedback that I have received are setup and configuration related.  Improving the installation and documentation stories at this point make the most sense and would be worth the effort. 

On the technical side of things, I am considering making a Chatsworth plugin for Windows Home Server.  Currently I am running the service from my home server and, given the always on nature that suits the chatbot and the low/no maintenance needed to running once it is setup, the pairing seems natural and could help provide a little better setup and configuration experience.

I hope to work on this more over the holidays and please feel free to reach out with a question or feedback.  Enjoy.

Posted in chatsworth, development. Tagged with , , , , , , , , , , , , , , , , , .

Monotouch: UIAlertView + UITextField = Crazy Delicious

If you have ever tried to buy or install anything from the App Store or iTunes on your iPhone, then you certainly have been prompted for your password by a screen that looks like this:

itunes_pw_iphone

The control used by Apple to prompt you for your password isn’t available out-of-the-box in Cocoa Touch, but fortunately it is pretty easy to roll your own.  I’ve put together a sample project that shows a couple different techniques that are available for creating and customizing the control, and I’ll go over a few of them here.

The stock UIAlertView control consists of a title label, message label, and typically one or more buttons.  It is important to note that in Monotouch, a default button setup isn’t configured, and buttons have to be added explicitly.  If a UIAlertView is configured without any buttons, then dismissing the control will have to be done programmatically because the user will have no way to dismiss the control.  In both of my examples I’ve configured the control to have two buttons (Cancel and Ok), but I could have gotten by with just one.  If only one button is used, it is important to also note that the button is considered the Cancel button by the control, and the CancelButtonIndex property will refer to that button.

Basic_UIAlertView

The easiest way to go about composing a UIAlertView with a UITextField is to create an instance of a UITextField and add it as a sub-view.  Since you’re adding a layer on top of UIAlertView’s view, the key will be fitting this new control into the UI.  There are two ways of going about this.  The first and maybe most obvious way to solve this problem is to make some room between the message label and buttons for the text field ala the iTunes password prompt.  Since the UIAlertView control has already been laid out, moving those controls around within the frame is not as straight forward a task as it may seem.  Before we tackle that we will explore a simpler method that overlays the text field directly on top of the message label.  You sacrifice being able to display an additional message to the user, but the end result looks professional and is very easy to implement.  This will also be the basis for getting the control to have the same look and feel as the iTunes password prompt, so it is important to understand this prior to attempting to move the controls around.

The key to overlaying the text field on top of the message label is setting the bounding rectangle for the UITextField.  The bounding rectangle is where the text field draws the box in which a user enters text.  For our purposes, the rectangle needs to be drawn in between the title label and the buttons.  It is important to make sure that it covers the area where the message label is drawn.  Thanks to the work of others we know that if we start drawing the text field at the x,y offset of 12,45 that the text field will hide the message label.

The code to overlay the text field is as follows:

void PromptForName(HandlerToUse handlerType)
{
    UITextField tf = new UITextField (new System.Drawing.RectangleF (12f, 45f, 260f, 25f));
    tf.BackgroundColor = UIColor.White;
    tf.UserInteractionEnabled = true;
    tf.AutocorrectionType = UITextAutocorrectionType.No;
    tf.AutocapitalizationType = UITextAutocapitalizationType.None;
    tf.ReturnKeyType = UIReturnKeyType.Done;
    tf.SecureTextEntry = false; 

    UIAlertView myAlertView = new UIAlertView
    {
        Title = "Please enter your name",
        Message = "this line is hidden"
    };

    myAlertView.AddButton("Cancel");
    myAlertView.AddButton("Ok");
    myAlertView.AddSubview(tf);
    // More Setup Goes Here
    myAlertView.Show ();
}

The method starts by instantiating a UITextField control with a bounding rectangle passed via its constructor.  The rectangle itself is constructed with four parameters via its constructor: the first two parameters set the x and y offset from the origin point of the control, and the last two parameters set the size of the drawing area.  After the initial construction of the UITextField, a few additional properties are set to customize the display. 

Among the properties set is the SecureTextEntry.  Setting this property to true will make the text field act like a password field and hide all the characters that you’ve entered.  Once the text field has been created and initialized, we move on to creating a UIAlertView.  Via object initialization, the Title and Message properties are set with some text.  Finally, two buttons are created, and the text field is added as a sub-view to the UIAlertView.  Calling the show on the UIAlertView causes the alert to pop up.  Below you can see the rendered control.

TextField_As_Subview_UIAlertView

So now that we have the basic control setup, we can tweak it so that the text field and the message label can both be displayed.

If you recall our custom UIAlertView control is currently composed of two UILabels, two UIButtons and a UITextField that we added.  The UILabels are derived from UIView and is not a subclass of UIControl; whereas, the UIButton and the UITextField are both derived from UIControls.  Since we want to position the UITextField beneath the labels, we can use this knowledge to selectively shift only the UIControls in the view down leaving the title and message labels in place.

To accomplish this task the following steps need to be performed:

1) The control height needs to be increased to make space for the text field and provide additional space to move the UIControls.  This is done by setting the frame to a larger size.  The frame will be increased by the height of the text field plus a buffer, so the control has space between it and the others.

This is what the frame looks like after being enlarged:

FrameEnlarged_CustomUIAlertView 


2) Once the frame has been enlarged, we’ll loop through the sub-views looking for UIControls and adjust only those types down by the same text field plus buffer offset

Here is what the control looks like after each UIControl is found during the iteration through the sub-views.

FirstUIControlShifted_CancelButton

SecondUIControlShifted_OkButton

FinalUIControlShifted_TextField

Here is the code that does the control adjustment:

public class TextFieldAlertView : UIAlertView
{
    private UITextField _tf;

    // ... 

    private void AdjustControlSize()
    {
        float tfExtH = _tf.Frame.Size.Height + 16.0f;

        var frame = new RectangleF(this.Frame.X,
                                    this.Frame.Y - tfExtH/2,
                                    this.Frame.Size.Width,
                                    this.Frame.Size.Height + tfExtH);

        this.Frame = frame;

        foreach(var view in this.Subviews)
        {
            if(view is UIControl)
            {
                view.Frame = new RectangleF(view.Frame.X,
                                            view.Frame.Y + tfExtH,
                                            view.Frame.Size.Width,
                                            view.Frame.Size.Height);
            }
        }
    }
}

So now that the desired look and feel of the control has been established, it is time to wire up the control.  There are a couple options for handling events generated by the control: one is more in line with how Cocoa handles events, and another that is similar to how .Net works. 

The Cocoa way to wire up delegates involves subclassing a special delegate class associated to the control and selectively overriding the methods for the actions you want to customize.  In the case of the UIAlertView control, that delegate class is a UIAlertViewDelegate.  The delegate class includes overridable methods like Clicked where you can define the actions to take when a button on the control is clicked or where you can extend behaviors by overriding methods like Preseneted which is called after the control has been displayed to the user.

The .Net way to wire up events is to provide specific delegates for specific events.  To make interacting with the Cocoa Touch controls easier, Monotouch provides public events for each one of the methods that can be overridden in the UIAlertViewDelegate class.  Having the individual public events makes wiring up controls more intuitive for the .Net developer, but it is good to know about the Cocoa-style approach especially when looking at Objective-C examples and/or ADC docs.  I have examples of wiring up the control via both methods in the example source.

The last topic I’d like to cover briefly is how I encapsulated the customization of control by subclassing UIAlertView.  The key to getting the control to look right is to override the LayoutSubviews method and build out the text field, add it to the UIAlertView and shift the controls around there.

public override void LayoutSubviews ()
{
    // layout the stock UIAlertView
    base.LayoutSubviews ();

    // build out the text field
    _tf = ComposeTextFieldControl(_secureTextEntry);

    // add the text field to the UIAlertView
    this.AddSubview(_tf);

    // shift the UIControls to fit the text field
    AdjustControlSize();
}

I’ve added some more customizations to my subclassed UIAlertView control that allows you to enable the text field security via a constructor parameter and a tweak to the control’s Transform property to shift the control up so it isn’t hidden by the keyboard.  You can see those changes and the entire working example here on github.

Enjoy.

Links to some of the resources used:

Posted in UIAlertView, UITextField, iphone, monotouch. Tagged with , , , , , , , , , , , , , .

Fun with Monotouch and Multi-Level Table Views without Interface Builder

With the recent release of  Monotouch, which enabled development for the iPhone/iPod Touch platform using C# and .Net, it seemed like the perfect time to take a swing at mobile app development.  The strong appeal of being able to leverage my C# and .Net experience while scratching an itch that I have had for a few apps was more than enough to entice me to order a brand new Mac mini and start learning the Cocoa framework.

My pet app project requires some pretty basic multi-level tabular data visualization, so that was the first thing I attempted to tackle.  I started my learning endeavor by reading the view controller programming guide from Apple’s ADC and working through a few of the tutorials listed on the Monotouch site.  One of the example tutorials listed was for a basic RSS reader.  Armed with his guide, I got up and running with a basic table view allowed me to drill down one level deep and return to the root via navigation button.  This was a great introduction and the easy to follow steps combined with the screenshots certainly hit the mark; however, this was not quite the layout I was looking for.

The data that I wanted to display calls for more than just a list-view-to-detail-view relationship that the RSS reader implemented.  As a beginner trying to figure out how to wire up my custom table controllers to each other and the navigation controller all via Interface Builder resulted in a lot of thrashing and a lot of ugly code.  I eventually was able to roughly approximate the behavior I wanted, but it was pretty obvious to me there had to be a better way.

I set out to see if I could find more Monotouch examples to see if I could pick up some tips and stumbled across Craig Dunn’s blog.  Craig not only put together apps for the Monospace and PDC conferences (and graciously provided the source) but also posted a Roget’s Thesaurus app that was just what I was looking for.  It was a simple app, but it had all the elements in play that I was looking for and an incredible diagram that tied it all together.

One of the key tips and tricks I picked up from Craig’s code was how easy it was to cut out the Interface Builder from the process.  I also generally tend to avoid using the designer whenever possible in Visual Studio but here it was a key factor in my understand.  This isn’t to say that I’d never use the Interface Builder again or that it doesn’t have its uses because it does but there was too much magic going on in how Monotouch links up the XIBs to their backing C# classes.  It wasn’t until I started explicitly creating views and view controllers instead of trying to wire them up after the fact did I start to understand how things were supposed to interact.

To implement a custom UITableViewController you need to set two properties with custom classes and override a method which is invoked by the framework when the view controller is loaded.  You’ll need to set the TableDelegate and DataSource properties on the controller with your own implementations of UITableViewDelegate and  UITableViewDataSource.  The implementation of the table delegate allows you to customize how the table will respond to certain events and the data source implementation provides not only the data the table uses but also how that data is to be displayed within the table.  Typically the ViewDidLoad method is overriden to perform the view setup work needed during initialization of the view controller.  Within the method the TableDelegate and DataSource properties can be set.

Example setting the TableDelegate and DataSource via the ViewDidLoad method:

namespace MultiLevelTableView
{
    [MonoTouch.Foundation.Register("RootViewController")]
    public partial class RootViewController : UITableViewController
    {
        class DataSource : UITableViewDataSource { /* Impl Here */ }

        class TableDelegate : UITableViewDelegate { /* Impl Here */ }

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

            TableView.Delegate = new TableDelegate (this);
            TableView.DataSource = new DataSource (this);
        }
    }
}

Example setting the properties during UITableView construction:

namespace MultiLevelTableView
{
    [MonoTouch.Foundation.Register("RootViewController")]
    public partial class RootViewController : UITableViewController
    {
        UITableView tableView;

        class DataSource : UITableViewDataSource { /* Impl Here */ }

        class TableDelegate : UITableViewDelegate { /* Impl Here */ }

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

            tableView = new UITableView()
            {
                Delegate = new TableViewDelegate(this),
                DataSource = new TableViewDataSource(this),
            };

            //You can set more properties here like size and
            //location in the frame etc.

            this.View.AddSubview(tableView);
        }
    }
}

The meat of the table view controller falls in the implementations of the DataSource and TableDelegate.

A basic DataSource setup involves overriding two methods used by parent controller.  The RowsInSection method tells how many rows need to be displayed in the table and the GetCell method returns a cell view which was customized for display by setting the text and display properties.

class DataSource : UITableViewDataSource
{
    static NSString kCellIdentifier = new NSString ("MyIdentifier");
    RootViewController tvc;

    public DataSource (RootViewController tvc)
    {
        this.tvc = tvc;
    }

    public override int RowsInSection (UITableView tableView, int section)
    {
        return tvc.RootData.Count;
    }

    public override UITableViewCell GetCell (UITableView tableView, NSIndexPath indexPath)
    {
        var cell = tableView.DequeueReusableCell (kCellIdentifier);

        if (cell == null)
        {
            cell = new UITableViewCell (UITableViewCellStyle.Default, kCellIdentifier);
        }

        cell.TextLabel.Text = tvc.RootData.ElementAt(indexPath.Row);
        cell.Accessory = UITableViewCellAccessory.DetailDisclosureButton;
        return cell;
    }
}

The TableDelegate is where the behavior of the table to various events is defined.  It is here in which we load up the next view to display when a user clicks on a cell.   A basic implementation of a table view delegate involves overriding the RowSelected method with instructions on what to do with the row now that it has been selected.  If the node selected happened to be a leaf node for example we might load up the detail’s view to display the nodes properties or if the node was the parent of more child nodes we would load another list view to continue to drill down into the data.  In our case we want to drill down to the next layer of data which is managed by the SubGroupViewController.

class TableDelegate : UITableViewDelegate
{
    RootViewController tvc;
    SubGroupViewController sgvc;

    public TableDelegate (RootViewController tvc)
    {
        this.tvc = tvc;
    }

    public override void RowSelected (UITableView tableView, NSIndexPath indexPath)
    {
        // get info from selected row
        string selectedGroup = tvc.RootData.ElementAt(indexPath.Row);

        // load up new controller to display
        if(sgvc == null)
            sgvc = new SubGroupViewController(selectedGroup);

        // push the controller on the navigation stack
        tvc.NavigationController.PushViewController(sgvc, true);
    }
}

The hang up for me with using Interface Builder to try and get the multi-level table views wired together was mostly due to not being familiar with the objects I was dealing with and not understanding what properties are needed to be initialized so the framework can display them correctly.  Approaching the problem via the Interface Builder created a lot of noise that made seeing what was really needed to wire these table view controllers with the navigation controller difficult.  In this case the the pre-packaged templates and generic layouts provided by Monotouch and Interface Builder were more of a hindrance than help but that is to be expected while learning a new technology.

I’ve packaged up my implementation of a multi-level table view app and put it on github.  If anyone is looking for straight-forward, simple example of nesting table views hopefully this will help.

I also recommend checking out the following links which helped me immensely:

Posted in C#, UITableView, UITableViewController, cocoa touch, development, iphone, monotouch. Tagged with , , , , , , , , , , , , , , , , , , , .

Tree Surgeon: Review and a couple tips

This past week I was playing around with Hudson and Team City and getting some NAnt scripts put together to use.  In a happy coincidence I happened to catch a mention about Tree Surgeon from twitter and it had piqued my curiosity.  Tree Surgeon is a project on CodePlex that has been around for a while and helps automate the process of setting up a source tree and assembling build scripts.  It was just what I was looking for.

The goal of Tree Surgeon was to make setting up and laying out new projects using best practices dead simple.  All the major tools and libraries that typically find their way into your .Net source trees are provided for you.  In addition to laying out the directory structure for your source and libraries, a solution file gets created with three main projects to get you started.  The basic project setup includes a console app, core library and unit test project.  The build scripts come pre-wired to have NCover run your tests and generate reports from the results and also do things like packaging your build artifacts into zip files for deployment.

The whole process, start to project generated, is very easy.  Download and run the installer.  Launch the program, select the version of Visual Studio (2003, 2005, and 2008) and the flavor of testing framework (NUnit or MbUnit) and then hit generate.  The files and directories, built out in your Documents folder, are then created and ready to be used.

There are two slight issues I ran into that I’d like to point out.  Both issues had already been noted in the project forums and were easy to fix.  When generating a source tree with MbUnit selected as the unit test framework, the build script generated has the unit test assembly referenced is named incorrectly.  You will have to change it to match your project’s unit test assembly name.  The second issue has to do with running NCover and NUnit on x64 machines.  I found that in order for NCover and NUnit to work on x64 machines I had to add two calls to the CorFlags utility to make executables work.  This was accomplished by making the modifications to the ‘run-unit-tests’ target below on lines 5-8.

   1: <target name="run-unit-tests">
   2:     <mkdir dir="${build.dir}\test-reports" />
   3:     <exec program="regsvr32" workingdir="tools\NCover" commandline="/s CoverLib.dll" />
   4:     <!-- Need the CorFlags Commands For x64 -->
   5:     <exec program="C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\CorFlags" 
   6:         workingdir="tools\NCover" commandline="NCover.Console.exe /32BIT+" />
   7:     <exec program="c:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\CorFlags" 
   8:         workingdir="tools\NUnit" commandline="NUnit-Console.Exe /32BIT+" />
   9:     <exec program="tools\ncover\NCover.Console.exe" 
  10:         workingdir="${build.dir}\Debug\UnitTests">
  11:         <arg value="//w &quot;.&quot;" />
  12:         <arg value="//x &quot;..\..\test-reports\Coverage.xml&quot;" />
  13:         <arg value="&quot;..\..\..\tools\nunit\nunit-console.exe&quot;" />
  14:         <arg value="&quot;MyProjectName.UnitTests.dll&quot; 
  15:             &quot;/xml:..\..\test-reports\UnitTests.xml&quot; &quot;/nologo&quot;" />
  16:     </exec>
  17: </target>

Even though I am pretty late to the party with Tree Surgeon I am very happy to have stumbled across it.  The whole source tree and build script setup process is the perfect thing to script out and I am really glad the project creator and contributors have taken the time to do this.  It is a big help and I highly recommend you try it out the next time you are spinning up a new source tree for a project.

Posted in CI, build, development, open source. Tagged with , , , , , , , , , , , , , , , , , , , .

Alt.Net Seattle Recap

I spent last weekend at the Alt.Net Seattle conference and had some time to reflect on it.  This was my first experience with an open spaces style conference, and I have to admit that I am a big fan of the format.  While I am not convinced this format would work for every type of gathering, it fit the needs for this type of group very well.

There was a lot made during a couple of sessions about being more accessible, newbie friendly and encouraging more new faces and ideas at these events.  If you watch some of the video from Hanselman’s Why So Mean session, you can get the general gist of some of the problems and solutions offered.  While I think introspection is generally a good thing, I am not convinced that any progress on this front will be made, and question if these issues are as bad as some may think.  As a first-time Alt.Net conference attendee and having only met one other person there in real life prior to last weekend, I never felt unwelcome or shunned and everyone that I talked to was cordial and friendly and definitely open to discussion.

However I didn’t get on a plane to Seattle to talk about feelings.  What drew me to the conference was the opportunity to talk about the software with some of the most passionate and opinionated developers in the world.  By participating in the workshops and sessions, I was able to soak up and participate in some great conversations about agile and lean, LINQ, DDD, context/spec based testing, etc.  These are topics that I don’t always have the opportunity to discuss daily and certainly not with people who have the kind of expertise as those who were in Seattle.  I’ve already been able to apply at work and on my side projects some of the things I’ve picked up, and I don’t think I’m close to truly synthesizing all of the great conversations that I had.

While my overall experience was positive and worth both the time and expense, I did feel like there were some minuses from the trip.  Some of the sessions turned out to be essentially just presentations and spurred very little discussion or participation.  I expected that there might be some of this due to the lack of experience or expertise with the tech.  Sessions like Miguel de Icaza’s on Mono and the iPhone fell into that category since virtually no one there had any experience with developing for the iPhone and even fewer with Mono, but even things like some of the discussions on more common topics like DDD or Agile were somewhat eyes forward discussions and lacked some of the give and take that really made some of the other sessions.

Some of this may have been the result of people deferring to some of the *ahem* stronger personalities or undisputed domain experts in the field.  The presence of some of these personalities in the sessions clearly defined or dramatically shifted the discussions.  It did not take me long to learn and apply the law of two feet when I found myself at the same sessions as some of these people.  I knew that it was a matter of time until the session’s conversation was going to degrade or grind to a halt.  My last complaint about the conference is about some of the new age crap that that was brought in by the facilitator.  I don’t think the butterfly and bumblebee metaphor stuff or the ringing of the bell really added to the experience and was not needed.  I know that the facilitators were trying to make this a very Zen-like experience, but it was not.

In terms of key take-aways, I think I’ve identified a few.  I talked with quite a few people about their experiences with agile and scrum.  In hearing some other companies’ practices and problems, I was comforted by the knowledge that my current company is not as dysfunctional as I thought.  While I still think we can improve, I also realized that I should probably take a moment to appreciate the good things that we do and celebrate the stuff that what works well.  The other take-away was that I feel like I am in a much better position to clearly articulate the goals that I had set for myself earlier this year.  Prior to this weekend I had not done a good job articulating some of these goals and had yet to express them in SMART terms.  Now I am going to incorporate things like contributions to open source projects and community demos and/or presentations into my measurables when tracking my progress on some of my goals.

The future of these conferences I think will be in the local or region open spaces starting to be held.  Already conferences are planned for Vancouver and Houston that seem to fit this bill because they are drawing in people from the region versus nationally based on a quick perusal of their attendee list.  I speculate that if you reduce the concentration of some of the more well known personalities in the community, you might be able to make up for any potential loss of expertise with an increase in the amount of active participation from fresh new faces.  Additionally, I think some might find the benefits of participating in open discussions with developers in their own communities more meaningful as these types of interactions may yield long-term benefits.

Lastly, I’d like to thank the people of the Alt.Net Seattle group for putting this together, and you should be proud of the success the conference achieved.  Job well done.

Posted in alt.net, open spaces, recap. Tagged with , , , , , , , , , , , , , , .