Recently, I decided to address a long standing issue with my Xamarin.Forms version of Score Predict: overflow.  As you may know, Xamarin.Forms allows  you to use the TabbedPage control to define a page that shows tabs for children, using the appropriate control on each platform.  On Windows Phone this is the Panorama control, Android shows the horizontal tabs across the top, and iOS goes to the typical TabBarController with the tabs running along the bottom.

Because I will expect the control to show 6 tabs I will be invoking the overflow scenario on both Android and iOS (Windows Phone doesnt have a concept of this).  With Android, I had no problems, and using my default approach things came out perfectly, with the tab bar supporting horizontal scrolling to see additional items.  Where I ran into problems was with iOS and its More Navigation Controller.  This controller is an auto-generated view that renders as a TableViewController within a NavigationController.  Unfortunately, with my default approach I ended up with this:

Pretty ugly.  The problem here is that I had made the choice to use a NavigationPage as the wrapper for all pages.  I was doing this so I could more finely control the navigation, taking pages out as needed.  This will not work with Tab pages.  The solution is to embed the Navigation page wrappers into each child.  This can be done declaratively.

   <pages:ScorePredictNavigationPage Title="This Week">
      <x:Arguments>
        <pages:ThisWeekPage>
          <pages:ThisWeekPage.ToolbarItems>
            <ToolbarItem Name="Logout" Command="{Binding LogoutCommand}">
              <ToolbarItem.Order>
                <OnPlatform x:TypeArguments="ToolbarItemOrder"
                       WinPhone="Secondary"
                       Android="Secondary"
                       iOS="Primary" />
              </ToolbarItem.Order>
            </ToolbarItem>
          </pages:ThisWeekPage.ToolbarItems>
        </pages:ThisWeekPage>
      </x:Arguments>
    </pages:ScorePredictNavigationPage>

ScorePredictNavigationPage is just an empty class that I created which inherits from NavigationPage and specifies the various colors to keep the style consistent.  By doing this for each of your pages you will be able to use Navigation and Toolbar items for that tab; and yes the Toolbars will change as the user changes tabs depending on the items available.

This is where I encountered my first snafu.  It is the Navigation Bar, on Android, which also provides the action bar.  Therefore, if your page is not within a NavigationPage you do not get the Action bar, and thus the options in it.  However, on iOS, the overflow will inherently provide a Navigation page, further if you wrap these options in Navigation pages the sizing and handling by the More is quirky.  The solution that I found was I needed to ensure that I provided pages which had the Navigation chrome on Android, but did not have it on Windows Phone and iOS.

My first attempt, was store each version of the page in the local Resource Dictionary and reference it as a StaticResource.  This did not as <OnPlatform> does not seem to work as a child of TabbedPage; it became clear I was going to have to do this in code.  So, I used the Device.OS enumeration to determine which platform I was on and add the appropriate page to end of Children.  While this worked on Windows Phone and Android, I found that it caused some quirky behavior and overwrote my visual customizations for the More Navigation Controller (future blog post).  I then dialed down my approach and specified the NavigationPageless About and History pages in Children.  In code, I removed these pages and added the NavigationPage wrapped versions when the OS is Android.

        protected override void OnAppearing()
        {
            if (Device.OS == TargetPlatform.Android)
            {
                Children.Remove(Children.Last());       // remove about
                Children.Remove(Children.Last());       // remove history

                Children.Add((Page)Resources["ChromedHistoryPage"]);        // add history
                Children.Add((Page)Resources["ChromedAboutPage"]);  // add about
            }
        }

As you can see, we remove the last two pages from Children and then reference the pages by their Resource Key, I show the About page definition below:

<TabbedPage.Resources>
    <ResourceDictionary>
      <pages:ScorePredictNavigationPage Title="About" x:Key="ChromedAboutPage">
        <x:Arguments>
          <pages:AboutPage Title="About">
            <pages:AboutPage.ToolbarItems>
              <ToolbarItem Name="Logout" Command="{Binding LogoutCommand}">
                <ToolbarItem.Order>
                  <OnPlatform x:TypeArguments="ToolbarItemOrder"
                    WinPhone="Secondary"
                    Android="Secondary"
                    iOS="Primary" />
                </ToolbarItem.Order>
              </ToolbarItem>
            </pages:AboutPage.ToolbarItems>
          </pages:AboutPage>
        </x:Arguments>
      </pages:ScorePredictNavigationPage>
    </ResourceDictionary>
  </TabbedPage.Resources>

You really have to love the flexibility that Xaml gives you, and the fact I can use it for iOS makes me beyond happy.  Now you might be wondering if the user will see a flash before the two final tabs are added.  Not so far in my experiments, however, with the way Android renders tabs, its unlikely the user could get to the end before they loaded; maybe on a wider screen.  Either way, I do not recommend this approach for large amounts of tabs.  Hopefully the Forms team will make this approach irrelevant in the future.

With our chromeless pages iOS works great and Windows Phone remains ambivalent as ever, Android removes these pages and uses its own.

The Login Process

I mentioned previously that I was forced to alter my logon process because I could not contain the TabbedPage in the same Navigation Page as the Logon flow pages, something I did previously which allowed me to alter the navigation stack; this was a subject of past blog posts.  The rule in Forms is you cannot have two Navigation Pages in the same navigation context.  Since there was no question the Logon process was going to need a NavigationPage and I needed Navigation Pages within each tab to provide the toolbar it was clear I needed to show a modal.

Originally, I did not show a modal because I am still at a loss on how to properly use the hardware back button on Android and Windows Phone with Forms.  Figuring out how to get the app to exit from the Logon modal would be essential; its an integral part of the UI experience for Windows Phone and   According to this forum thread (http://forums.xamarin.com/discussion/29934/xamarin-forms-1-3-0-released/p1) Jason Smith (PM for the Forms team) implies that if you return “false” from OnBackButtonPressed it will exit the app.  I was not able to confirm this.

In lieu of getting this supposed functionality to work, I decided that I would simply have the app just straight terminate.  This is not allowed on iOS, however, since it will only ever be triggered by a hardware back button, it is irrelevant for Apple users.  To accomplish on Android and Windows Phone requires diving into the platform itself, so we use the “bridge pattern”.  I created interface called IKillApplication with a single method KillApp.  I then had MainPage (Windows Phone) and MainActivity (Android) implement this interface and pass a reference to themselves to the constructor for Score Predict.

// Android
public class MainActivity : FormsApplicationActivity, IKillApplication
{
   protected override void OnCreate(Bundle bundle)
   {
      base.OnCreate(bundle);
      Forms.Init(this, bundle);

      LoadApplication(new ScorePredictApplication(new DroidNavigator(), this,
         new ServiceInjectionModule(), new DroidInjectionModule()));
   }

   public void KillApp()
   {
      Process.KillProcess(Android.OS.Process.MyPid());
   }
}

// Windows Phone
public partial class MainPage : IKillApplication
{
   public MainPage()
   {
      InitializeComponent();
      Forms.Init();

      var app = new ScorePredictApplication(new PhoneNavigator(), this,
         new ServiceInjectionModule(), new PhoneInjectionModule());
      LoadApplication(app);
   }

   public void KillApp()
   {
      App.Current.Terminate();
   }
}

In my final version, I will likely isolate this to its own class and pass an instance of that class rather than using the Page or Activity, this this suffices for explanation.  I wire this up so that each ViewModel can override the BackButtonPressed method.  They can then call the KillApp to terminate the application.  By supporting this, I am able to terminate the application from the Login modal and thus prevent the user from returning to the application without authentication.

Unfortunately this introduced a new problem.  Before, since Main page would never be visible until the user logged in, I could safely assume my custom lifecycle events would not fire when the user was not authorized; this is now no longer the case.  In fact, for both Android and iOS the This Week page (the first page in the tab set) will “appear” despite being covered immediately by the modal; on Windows Phone the first two pages in the tab set “appear” this so the Panorama can show a bit of the second page (this is the common effect in Windows Phone to indicate where more content exists so the user goes there).

Since the “appear” event would only get fired once, I needed a way to communicate to these view models that they should attempt to load their data.  Solution: a quick and dirty message bus, based on Caliburn.Micro.  Here is a sample of its usage:

        public ThisWeekPageViewModel(IThisWeekService thisWeekService, IBus messageBus,
            IReadUserSecurityService readUserSecurityService)
        {
            ThisWeekService = thisWeekService;
            MessageBus = messageBus;
            ReadUserSecurityService = readUserSecurityService;
        }

        protected override async void Refresh()
        {
            await LoadWeekDataAsync();
        }

        public override async void OnShow()
        {
            MessageBus.ListenFor<LoginCompleteMessage>(LoadWeekData);
            if (ReadUserSecurityService.ReadUser() != null)
            {
                await LoadWeekDataAsync();
            }
        }

        private async void LoadWeekData()
        {
            await LoadWeekDataAsync();
        }

And now, the publish:

        private async void Login()
        {
            try
            {
                MessageBus.Publish<LoginCompleteMessage>();
                await Navigation.PopModalAsync(true);
            }
            catch (Exception ex)
            {
                DialogService.Alert("Login did not succeed. Please try again");
            }
        }

I kept it dirt simple.  The basic mechanism is the Bus stores a Dictionary with a List of Actions keyed by a Type.  When that type is published each Action is invoked.  This enables me to send these events from anywhere in the application; although I do not intend to do that very often, and kept it simple for this simple case.

Its important to remember that only the first tab in Android and iOS will need to be reloaded following a login, and the first two in Windows Phone.

I definitely learned some very important lessons from this experimentation and I think Score Predict is better for it.  I think the team has some ends to shore up to make this more pleasant to program against.  I find myself really diving into custom renderers for quite a few things, especially on iOS where it seems things are just not as far along as the other two platforms.

If you are curious to see the full source, you can always check out the full Score Predict source here (https://github.com/xximjasonxx/ScorePredictForms) – @jfarrell if you have any questions.

Cheers