The Connecticut Coalition to End Homelessness (CCEH) partnered with Microsoft and its IT partner Nutmeg Consulting to develop We Count, a mobile cross-platform application for iOS, Android, and Windows devices that volunteers used to conduct the Point-in-Time Count, a major national one-night survey of homeless persons.

The app was built using Xamarin.Forms with an ASP.NET Web API back end written in C# and hosted using Azure App Service.

The core team:

  • Brian Roccapriore – Director of HMIS & Strategic Analysis, Connecticut Coalition to End Homelessness (CCEH)
  • Nick Landry – Senior Technical Evangelist, Microsoft
  • Eric Rozell – Senior Software Development Engineer, Microsoft
  • Adam Yarnott – Software Developer, Nutmeg Consulting
  • Omar Kouatly – Director of Delivery Management, Microsoft
  • Keith Anderson – Senior Consultant, Microsoft
  • Nayan Patel – Senior Consultant, Microsoft
  • James Sturtevant – Senior Technical Evangelist, Microsoft
  • Gavin Bauman – Technical Evangelist, Microsoft

CCEH Banner

Customer profile

The Connecticut Coalition to End Homelessness (see @CCEHtweets on Twitter) works to prevent and end homelessness by transforming policy and programs to eliminate the root causes of homelessness in Connecticut. CCEH activities are executed statewide through five main areas:

  • Research and data analysis
  • Strategic communications
  • Community impact
  • Program and technical assistance
  • Leadership development and training

CCEH is the recognized source for current, comprehensive research and analysis on homelessness in Connecticut. Staff creates materials based on Homeless Management Information Systems (HMIS) data and the annual Connecticut Point-in-Time Count of homeless individuals and families to describe the complex and changing portrait of the homeless in Connecticut. CCEH disseminates research-driven materials describing what’s working and what’s needed to systematically reduce the incidence of homelessness in the state.

The Point-in-Time (PIT) Count is a major national event in which volunteers in every state of the country turn out to conduct a one-night count of sheltered and unsheltered homeless persons. Coordinated in Connecticut by CCEH in partnership with every homeless provider in the state, the Point-in-Time Count fulfills a central need for efforts to end homelessness by fulfilling the requirement of the federal Department of Housing and Urban Development (HUD) that Continuums of Care conduct an annual count of homeless persons sheltered in emergency shelters, transitional housing, and safe havens on a single night.

This provides vital data for guiding CCEH efforts while also playing a key role in helping the state secure federal resources toward ending homelessness. More than 300 volunteers throughout the state participate in the count each year, making this event an opportunity for members of the public to participate together in statewide efforts to end homelessness.

Problem statement

HUD mandates that all states conduct a Point-in-Time Count of their homeless populations each year to track year-over-year changes as a measure of investment effectiveness and to help direct future investments. CCEH was dissatisfied with the current counting and tracking tools and wanted to improve the effectiveness, usability, and insights derived from the count.

Key problems that needed to be solved included:

  • Compiling the completed survey forms can be a tedious process and CCEH has limited resources. Automating the data capture digitally was their highest priority.
  • The survey includes many questions with strict prerequisite instructions, which can lead to human capture errors. Volunteers would have limited new solution training time. Accuracy and ease of use were key.
  • Volunteers rely on their own devices to conduct the survey; this meant multiple mobile platforms and form factors to support (for example, phone, tablet, computer).
  • The collected data can be very sensitive because it aggregates private details about homeless people. Securing the data and respecting the privacy of interviewees was a priority.
  • The Point-in-Time Count had to be conducted on a single night, and the date was unmovable. The new solution had to be tested and ready on time despite a limited timetable and a team of part-time volunteer developers from Microsoft and Nutmeg Consulting.

Solution overview

To get a better understanding of the state of homelessness in Connecticut and address the underlying issues, we developed a mobile application that allows volunteers to conduct a survey on their mobile device. The app—We Count (internally referred to as PITCSurveyApp or CcehYouthPitCount)—presents a dynamic questionnaire to the volunteer, walking them through the questions they need to ask their interviewee. As answers are entered in the app, the user is branched into the next valid question, skipping questions that don’t apply to this person, or digging deeper to get more details based on a previous answer.

The app uses the device’s location services (GPS and cell triangulation) to locate where the survey took place. Additional metadata is captured in the app, including who was conducting the survey, and when the survey was started and completed. Once a survey is complete, it is automatically uploaded to a secure CCEH data service in the cloud. The questions themselves are pulled from the cloud service every time the app is run to ensure volunteers always have the latest set of questions. This also lets volunteers run the app even when offline because the questions are stored locally on their device. The survey answers are also stored locally, to be uploaded by the user once connectivity is restored. All survey answers are eventually removed from the local device for privacy purposes.

The We Count app is a cross-platform Xamarin.Forms solution built in C#, which runs natively on iOS, Android, and Windows 10 computers and devices, including Windows 10 Mobile phones. Xamarin.Forms allowed the team to share over 90 percent of the code while still providing a clean and intuitive survey interface for the volunteers as they navigated through the questions.

The back-end services run in Microsoft Azure, with Azure App Service hosting the custom API built with ASP.NET Web API and the Microsoft Entity Framework.

The application data—including the survey questions, collected answers, volunteer profiles and other metadata—is all stored in Azure SQL Database. Azure SQL Database was selected to allow CCEH to easily build reports based on the collected data thanks to the relational format.

Given the short development timeframe and the large number of testers, volunteers, and devices involved, the team leveraged HockeyApp to gather usage and crash analytics in the mobile app to quickly identify potential issues and resolve them with haste. We set up a Mobile DevOps infrastructure for automated deployment via Visual Studio Team Services; the team could easily deploy the app to testers and users thanks to the HockeyApp integration.

“With Microsoft using Xamarin to develop the application, and HockeyApp to distribute the app to volunteers, we were able to quickly and efficiently produce the app across multiple mobile platforms. Volunteers were able to easily load the app onto their devices. Without this contribution, we would have had to add months to the development time—and we didn’t have that luxury for this project. The app allowed us to quickly and efficiently collect the needed data, and tabulate it automatically, limiting error and expediting data collection.”

— Brian Roccapriore, Director of HMIS & Strategic Analysis, CCEH

Solution, steps, and delivery

To better understand how the We Count application was designed and built, let’s dive into the multiple steps of the solution:

  1. Create a cross-platform Xamarin.Forms application for dynamic survey
  2. Create a SQL Server database back end for survey data management
  3. Create a custom Web API in the cloud with ASP.NET and Azure App Service
  4. Integrate App Service Authentication to log in volunteers
  5. Capture mobile app usage metrics via HockeyApp integration
  6. Mobile DevOps: Set up automated deployment via Visual Studio Team Services and HockeyApp

Here is a high-level view of the solution architecture:

We Count Solution Architecture

Create a cross-platform Xamarin.Forms application for dynamic survey

The We Count app is a cross-platform Xamarin.Forms solution built in C#, that runs natively on iOS, Android, and Windows 10. The Windows 10 support is provided by a Universal Windows Platform (UWP) project that provides a unified experience across computers and devices running Windows 10, including Surface tablets and Windows 10 Mobile phones. Xamarin.Forms allowed the team to share over 90 percent of the code while still providing a clean and intuitive survey interface for the volunteers as they navigated through the questions.

All common code was structured in a Shared Project to facilitate calls to platform-specific APIs. This includes Views, ViewModels, Models, Services, Helpers, Extensions and Behaviors. Additional models are contained in a Portable Class Library (PCL) that is also used by the ASP.NET Web API cloud app to ensure consistency across custom class structures used to exchange data between the server and mobile clients.

We Count Home Screen

One of the first challenges tackled by the team was how to properly present a lengthy questionnaire in an intuitive app format. The traditional survey form filled out by volunteers has more than 30 questions, and many of them offer more than a dozen answers. Some questions are conditional on previous answers; the volunteer is told to skip ahead or dig deeper for more information. Volunteers preferred a guided experience instead of a long-form app.

The app is a “wizard”; volunteers navigate from one question to the next and can go back to revisit a previous answer. The questions are pulled from the server API and stored locally in JSON format, making it easy to conduct a survey even in an area with spotty or no connectivity.

{
  "SurveyID": 1,
  "Description": "2017 PIT Youth Survey",
  "Questions": [
    {
      "QuestionID": 1,
      "QuestionNum": "1",
      "QuestionText": "Have you already completed a survey?",
      "QuestionHelpText": "",
      "AllowMultipleAnswers": false,
      "AnswerChoices": [
        {
          "AnswerChoiceID": 1,
          "AnswerChoiceNum": "a",
          "AnswerChoiceText": "Yes",
          "AdditionalAnswerDataFormat": 0,
          "NextQuestionID": "",
          "EndSurvey": true
        },
        {
          "AnswerChoiceID": 2,
          "AnswerChoiceNum": "b",
          "AnswerChoiceText": "No",
          "AdditionalAnswerDataFormat": 0,
          "NextQuestionID": 2
        }
      ]
    },

Once the application parses the survey questions and loads them into an object structure, the dynamic survey page can guide the volunteer through each question.

Dynamic Survey Screen and XAML Markup

To achieve this, the team leveraged a XAML page in Xamarin.Forms. Each question featured a part of the interview script, potential answers, and “helper text” to assist the volunteer in filling out the answer. Because not all the answers might fit on one screen, the XAML design uses a ScrollView; it was left empty in the XAML markup because questions are dynamically loaded at runtime. At the bottom of the ScrollView was a horizontal StackLayout featuring the Previous and Next navigation buttons. We decided to include the StackLayout inside the ScrollView to force the volunteer to scroll through all the potential answers before moving on to the next questions.

    var q = _viewModel.CurrentQuestion;
    try
    {
        // Update the title and question text
#if !WINDOWS_UWP
        Title = $"Survey Question {q.QuestionNum} of {_viewModel.MaximumQuestionNumber}";
        QuestionLabel.Text = q.QuestionText;
#else
        QuestionLabel.Text = $"{q.QuestionNum}. {q.QuestionText}";
#endif
        HelpTextLabel.Text = q.QuestionHelpText;

        // Create a view for each of the answers
        var answerOptionsStackLayout = new StackLayout();
        var choices = CreateChoices(q, _viewModel.CurrentAnswers);
        foreach (var choice in choices)
        {
#if __ANDROID__
            // Android buttons support text wrapping,
            // so we don't need to use the custom ContentButton 
            var view = new SurveyAnswerItemAndroidView(choice);
#else
            var view = new SurveyAnswerItemView(choice);
#endif
            var stackLayout = new StackLayout();
            stackLayout.Children.Add(view);
            answerOptionsStackLayout.Children.Add(stackLayout);
        }

        // Add the navigation button stack back to the answers stack layout
        // The navigation buttons should always come at the end of all the answers
        // to ensure the volunteer sees all the questions
        answerOptionsStackLayout.Children.Add(NavigationButtonStackLayout);

        AnswerOptionsScrollView.Content = answerOptionsStackLayout;

Other challenges presented themselves in the shared UI because the rendering behaviors varied from platform to platform. For example, some answers had too much text and required text wrapping, but only Android could wrap the text by default on standard Button controls. For iOS and Windows 10, we used a custom ContentView, which contained a Label that allowed text wrapping. The team used conditional compilation directives (such as, #if) in code to separate the behavior between Android and the other platforms. The ContentView also included an Entry control (such as, Xamarin.Form’s text box) because some answers required additional details from the interviewee. For example, when asking their age, we presented three age brackets, but the volunteer then had to enter the specific age in the text box.

<ContentView xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" 
             x:Class="PITCSurveyApp.Views.SurveyAnswerItemAndroidView">
  <StackLayout>
    <Button Text="{Binding Name}"
            BackgroundColor="{Binding BackgroundColor}"
            Command="{Binding AnswerSelectedCommand}" />
    <Entry IsVisible="{Binding IsSpecifiable}"
           Text="{Binding SpecifiedText}"
           Placeholder="{Binding Placeholder}"
           Keyboard="{Binding Keyboard}"/>
  </StackLayout>
</ContentView>

<ContentView xmlns="http://xamarin.com/schemas/2014/forms" 
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:views="clr-namespace:PITCSurveyApp.Views"
             x:Class="PITCSurveyApp.Views.SurveyAnswerItemView">
  <ContentView.Content>
    <StackLayout>
      <views:ContentButton BackgroundColor="{Binding BackgroundColor}"
                           Command="{Binding AnswerSelectedCommand}">
        <Label Text="{Binding Name}"
               HorizontalTextAlignment="Center" 
               Margin="5" />
      </views:ContentButton>
      <Entry IsVisible="{Binding IsSpecifiable}" 
             Text="{Binding SpecifiedText}" 
             Placeholder="{Binding Placeholder}"
             Keyboard="{Binding Keyboard}"/>
    </StackLayout>
  </ContentView.Content>
</ContentView>

The rest of the main application user interface is based on a navigation model with a hamburger menu—a button with three parallel horizontal lines (displayed as ☰). Selecting this button displays a menu (sliding out or popping up), which distinguishes it from a menu bar, which is always on display.

The Android project uses the FormsAppCompatActivity class and features additional NuGet packages to provide support for Material Design in KitKat (Android 4.4) devices.

Xamarin plug-ins were used to simplify cross-platform API calls, such as file storage and location services. Location services were supplemented with manual entry to allow a user to override or append the location info in case it appears inaccurate due to tall buildings in an urban area. The Bing Maps API was used to reverse-geocode the location data, which converts latitude and longitude coordinates to the nearest known civic address.

When plug-ins were not available to easily access platform-specific APIs and SDKs from shared code, the team made use of the Xamarin.Forms Dependency Service with a common interface. This technique was used to facilitate access to the HockeyApp SDKs because no common NuGet package existed when this app was built.

public interface IMetricsManagerService
{
    /// <summary>
    /// Track an event.
    /// </summary>
    /// <param name="eventName">The event name.</param>
    void TrackEvent(string eventName);

    /// <summary>
    /// Track an event.
    /// </summary>
    /// <param name="eventName">The event name.</param>
    /// <param name="properties">The related properties.</param>
    /// <param name="measurements">The related measurements.</param>
    void TrackEvent(string eventName, Dictionary<string, string> properties, 
                                      Dictionary<string, double> measurements);
    /// <summary>
    /// Track an exception.
    /// </summary>
    /// <param name="eventName">The event name.</param>
    /// <param name="exception">The exception.</param>
    void TrackException(string eventName, Exception exception);

    /// <summary>
    /// Track a latency metric.
    /// </summary>
    /// <param name="eventName">The event name.</param>
    /// <param name="latency">The latency associated with the event.</param>
    void TrackLatency(string eventName, TimeSpan latency);
}

Create a SQL Server database back end for survey data management

We Count is a survey management app. The app manages survey data including the volunteer-collected survey questions and responses. The app also captures volunteer profiles so CCEH knows who conducted which survey. All the data is stored in a relational schema in the cloud using Azure SQL Database.

The data model allows for the creation of several surveys. CCEH can update the survey over time by adding, editing, or removing questions without breaking the integrity of completed surveys. Each completed survey includes additional metadata such as the survey version, volunteer ID, location data, and time stamps. Time stamps track the beginning and completion time to allow CCEH to track how long each survey took to complete.

We included the NextSurveyQuestion_ID in each SurveyAnswerChoices record to facilitate dynamic client navigation. The client app can automatically navigate to the appropriate next question based on a previous interviewee answer.

All data exchanged between the Web API and the database make use of the Microsoft Entity Framework (EF), an object-relational mapper that enables .NET developers to work with relational data using domain-specific objects. The REST-based Web API works more naturally with JSON data, and the team considered storing all data in the cloud in JSON format, using either Azure SQL Database or DocumentDB. Azure SQL Database (and its on-premises counterpart SQL Server) provides built-in functions and operators that let developers do many things with JSON text, such as parsing JSON text, reading or modifying values, transforming arrays of JSON objects into table format, running any Transact-SQL query on converted JSON objects, and formatting the results of Transact-SQL queries in JSON format. Azure DocumentDB is a truly schema-agnostic database capable of automatically indexing JSON documents. We decided to store the data using a relational data model to make it easy for CCEH to produce reports with familiar conventional relational tools.

We Count Database Schema Diagram

Create a custom Web API in the cloud with ASP.NET and Azure App Service

The We Count app requires a custom API to provide REST hooks. The Xamarin app uses HTTP and JSON data to:

  • Download survey questionnaires.
  • Get survey questionnaire metadata.
  • Authenticate users.
  • Manage volunteer profiles.
  • Upload completed survey responses.

We Count is an Azure App Service API app. Azure App Service lets developers build powerful applications for any platform or device, while still meeting rigorous performance, scalability, security, and compliance requirements using a single back end. The API Apps feature of App Service is used to quickly build and consume APIs in the cloud using the language of the developer’s choice. Given the .NET heavy background of the development team, we chose to build the We Count API as an ASP.NET Web API application written in C#.

One of the many benefits of API Apps includes support for Swagger 2.0 API metadata to make discovery and consumption of the API easier.

Web API Controller Code in VSTS

We Count communicates with the App Service via the Azure Mobile Client SDK. This automatically packages REST calls with JSON data, and then deserializes responses into the proper class structure. All data exchange classes were stored in a Portable Class Library (PCL). Both the Xamarin client apps and the ASP.NET Web API app reference the PCL to ensure data model consistency between clients and server.

public static class SurveyCloudService
{
    private const string AzureMobileAppUrl = "https://pitcsurveyapi.azurewebsites.net";

    /// <summary>
    /// The API client.
    /// </summary>
    public static readonly MobileServiceClient ApiClient = 
                                               new MobileServiceClient(AzureMobileAppUrl);

    /// <summary>
    /// Gets the survey with the given identifier.
    /// </summary>
    /// <param name="id">The survey identifier.</param>
    /// <returns>
    /// A task to await the survey surveyResponse, returning the survey surveyResponse
    /// or <code>null</code> if any exception occurs.
    /// </returns>
    public static async Task<SurveyModel> GetSurveyAsync(int id)
    {
        var parameters = new Dictionary<string, string>
        {
            {"id", id.ToString()},
        };

        try
        {
            using (new LatencyMetric("GetSurvey"))
            {
                return await 
                       ApiClient.InvokeApiAsync<SurveyModel>("Surveys", HttpMethod.Get, parameters);
            }
        }
        catch (Exception ex)
        {
            DependencyService.Get<IMetricsManagerService>().TrackException("GetSurveyFailed", ex);
            return null;
        }
    }

This app collects very sensitive data; it aggregates homeless people’s private situation details. Securing the data and respecting interviewees’ privacy was a priority. The mobile app included a cleanup routine that ensured that no data was kept on the device side once a survey was successfully completed and uploaded to Azure, or (if necessary) after a couple days had passed. If a connection is available when a survey is completed, it gets uploaded to the CCEH database in Azure and the data is removed from the local device afterwards. If no connection is available at the time of capture, volunteers have the option of uploading it later once a connection is available. All remaining data is automatically removed from the volunteer devices after a few days to guarantee that no interviewee data is left in the wild.

All data was exchanged securely using SSL over HTTP (HTTPS) and stored privately in the cloud, to be accessed only by CCEH employees.

Integrate App Service authentication to log in volunteers

The We Count app requires authentication so CCEH can trace all completed surveys to the volunteers who conducted them. Originally the app design required users to log in at startup, but the team approach shifted as development went on. The initial plan was to make the login mandatory and authenticate all volunteers as follows:

  • Android users authenticate with a Google ID.
  • iOS users authenticate with a Google ID or Microsoft Account (MSA).
  • Windows users authenticate with a Microsoft Account (MSA).

Because the app is designed to share as much code as possible—even UI code via Xamarin.Forms—we knew that the login page would have to include UI elements for both the MSA and Google ID authentication. Instead of hiding one method on Android and Windows, we decided to offer both methods to all users on all three platforms.

The other change involved a few key scenarios we needed to deal with:

  • How would CCEH maintain a list of authorized volunteers? Given that hundreds of volunteers would be involved, this could prove to be a tedious process for CCEH.
  • If a volunteer came on board at the last minute and was not authorized to capture surveys, would the app block them? The Point-in-Time Count is for one night only, and if a user is not authorized in time, CCEH would lose the chance to benefit from that volunteer’s time.
  • If a user was offline due to poor cell coverage or running the app on a Wi-Fi-only device (such as a tablet), would we still let them in the app?

We decided to change the authentication and authorization approach to make the app both easy to use and secure. The login screen would have a “not now” option to skip the login process and the app would still let them create, complete, and upload surveys so a volunteer wouldn’t be blocked on the count night if they could not reach technical support. One the cloud side, all completed surveys coming from unauthenticated users would be “flagged” for separate processing to maximize the number of surveys to be collected without affecting the authenticated volunteers’ survey integrity.

Login Process on Android

Azure App Service provides built-in authentication support for providers such as Google ID and Microsoft Account. The Authenticator in the code below is an object that implements the IAuthenticate interface that includes a MobileServiceUser (from the App Service Mobile Client SDK) and three methods: LoginAsync, RefreshLoginAsync, and LogoutAsync. The first two methods require the provider type (Microsoft or Google, in this instance) and return a MobileServiceUser which is then associated with a volunteer profile via the authentication provider ID.

public static async Task LoginAsync(MobileServiceAuthenticationProvider provider)
{
    try
    {
        DependencyService.Get<IMetricsManagerService>().TrackEvent("UserLogin");
        var properties = provider == MobileServiceAuthenticationProvider.Google
            ? new Dictionary<string, string>
            {
                { "access_type", "offline" },
            }
            : new Dictionary<string, string>(0);

        var user = await Authenticator.LoginAsync(provider, properties);
        UserSettings.Volunteer = await SurveyCloudService.GetVolunteerAsync();
        UserSettings.AuthToken = user?.MobileServiceAuthenticationToken;
        UserSettings.UserId = user?.UserId;
    }
    catch (Exception ex)
    {
        DependencyService.Get<IMetricsManagerService>().TrackException("UserLoginFailed", ex);
    }
}

Capture mobile app usage metrics via HockeyApp integration

HockeyApp is a Mobile DevOps solution for iOS, Android, OS X, and Windows apps that provides beta distribution, crash reporting, user metrics, feedback, and powerful workflow integrations. The We Count team used HockeyApp to capture all three mobile clients’ app usage metrics. We identified patterns and narrowed down potential issues at critical code paths during development.

Initially we integrated HockeyApp in the We Count app clients to review the collection of crash reports in the portal. To get better insights into how testers and volunteers used the app, we accessed the Xamarin.Forms Dependency Service metrics collection in the client code. Each client implemented the IMetricsManagerService interface shown earlier to wrap the Metrics Manager platform-specific implementation in HockeyApp. We easily inserted calls to track Events, Exception, and Latency events from the shared cross-platform code.

The HockeyApp portal lets team members and administrators review events and crash reports, providing critical insights in the late stages of development and in the short beta testing period before going to Point-in-Time Count night production. These metrics were also collected during the official count to help guide future We Count app releases.

iOS Events Logged in HockeyApp

Mobile DevOps: Set up automated deployment via VSTS and HockeyApp

We Count was built by a volunteer team of developers physically distributed across several US East Coast locations. Because CCEH is not a software development organization, the team hosted the project assets in Azure thanks to Visual Studio Team Services, including the source code repository for the client Xamarin apps, work items, bug tracking, project tasks, and builds.

To test the application across multiple platforms, we used a combination of emulators and physical devices for manual UI testing. The emulators include a variety of available configurations of the iOS Simulator, Visual Studio Emulator for Android, Android Virtual Devices (AVD) by Google, Windows 10 Mobile emulator, and native Windows 10 execution, such as Microsoft Surface Pro 3 and 4, and Surface Book.

For testing on physical devices, we catalogued all the iOS, Android, and Windows 10 devices available to the team and customer testers, and captured the device brand, model/name, screen resolution, RAM, and operating system version. We also asked CCEH to identify any known devices within their user base and did our best to match our device and emulator testing plan based on any known devices. This strategy allowed us to identify the configurations that were well tested, and in turn helped us run additional tests on different emulator configurations to fill in the gaps.

For operating system versions, the goal was to limit support to Windows 10 1511 (10586), iOS 7, and Android 4.4 (Kit Kat) or higher version, but not including any beta OS versions. Although Xamarin.Forms supports iOS 6, we chose to cut off support at iOS 7, given the drastic user interface changes made by Apple with iOS 7 when skeuomorphism was dropped in favor of a flatter design language. Android was cut off at 4.4 to limit compatibility issues on older Jelly Bean (that is, Android 4.1 to 4.3) devices. This still provided potential compatibility with more than 80 percent of all Android devices in use today.

HockeyApp was used to gather analytics from the mobile clients during development, unit tests, and customer testing, as well as the initial beta rollout before the count. This helped identify potential crashes and usability issues as well as untested areas to maximize stability for a successful count night. But HockeyApp was also a critical deployment component. Because We Count is an “enterprise app,” (it’s not meant to be deployed to any of the public mobile app stores like Apple App Store, Google Play Store, Windows Store), we needed an easy way to provision CCEH employee and volunteer devices with the various We Count iOS, Android, and Windows app packages for their respective devices.

HockeyApp allowed the team to upload beta versions of We Count to HockeyApp so testers could install them using a self-service approach. HockeyApp served as an “in-house” CCEH app store for testing where CCEH administrators could invite or recruit testers through the easy-to-use dashboard. Every time a new build was uploaded to HockeyApp for iOS, Android, or Window, HockeyApp gave us the ability to notify current users and testers so they could immediately install the new version and start testing. The notifications pop up on their phones automatically; the users were also notified to download the new update whenever they tried to launch the app from the HockeyApp interface on their devices.

iOS Dashboard in HockeyApp

Windows and Android deployment was simpler given that Google and Microsoft do not impose caps on “ad hoc” application deployment (like side-loading) in enterprise deployments. iOS was trickier due to Apple restrictions. All builds had to be deployed using CCEH’s Apple Enterprise Developer account to enroll volunteers as “internal users.” Ad-hoc deployment was not an option given the Apple-imposed 100 iPhones and 100 iPads cap.

Once testing was in full swing during the few days before the Point-in-Time Count night, volunteer testers could also use the HockeyApp mobile app on their devices to ask questions and provide app feedback. This made it easier for CCEH and the development team to assess the app user response from a central place in the HockeyApp portal and answer testers directly without having to compile responses from various email accounts. The short beta period would not have allowed us to address all questions and concerns in time.

HockeyApp also allowed us to create a full Mobile DevOps pipeline via automated continuous deployment. Thanks to the integration between Visual Studio Team Services and HockeyApp, it was possible to set up a build chain where the source code was automatically pulled from the Team Services repository when new code was checked in to trigger a new build of the Xamarin.Android app. This was only done for Android given the more diverse set of devices to test on that platform. There were very few Windows 10 users for the app, and no Mac Build Agent was available on the server-side to automate the iOS builds. iOS packages were compiled and built manually on a client Mac workstation and then uploaded to HockeyApp by the development team.

Android Build Steps in VSTS

Conclusion

Thanks to the We Count app, CCEH could move away from paper forms and the January 2017 Youth Point-in-Time Count in Connecticut was a huge success. Surveys were captured digitally in the app and all the volunteers could navigate all the questions with minimal training. The productivity improvements introduced by the app were so significant that CCEH volunteers could capture more than 2,200 surveys, compared to the initial CCEH target of 1,600 surveys.

The app ran successfully on a wide range of volunteer “bring your own” (BYO) devices thanks to the cross-platform nature of Xamarin apps built in C#. With more than 90 percent code sharing, the team could build the app from scratch in less than 3 months despite all developers being part-time volunteers, thus meeting the January 2017 count night date.

By the time the night of the Point-in-Time Count was over, all the data was securely stored in Azure, and all volunteer devices were automatically cleaned of survey data, preserving the interviewees’ privacy. CCEH could use Tableau and Microsoft Power BI to immediately start analyzing the survey results and produce reports and visualizations.

App feedback is being compiled to drive new app features in upcoming versions. Connecticut is poised to become the first state to end chronic homelessness, and the We Count app is a leadership initiative by CCEH toward that goal.

“The 2017 Youth Count wouldn’t have been possible without the work of Microsoft and Nutmeg Consulting. The volunteer team’s work to develop the youth count app was critical to the success of this effort. Thanks to their work, we will have a much better understanding of the scope of youth and young adult homelessness in Connecticut.”

— Brian Roccapriore, Director of HMIS & Strategic Analysis, CCEH

General lessons

This project shows how any organization in need of a cross-platform enterprise app can quickly build a first version using Xamarin and Azure App Service while sharing a majority of their code. The We Count app did not require any advanced device integration features beyond local storage and location services, and the team could share more than 90 percent of the code thanks to Xamarin.Forms. Even in scenarios requiring deeper API calls, development teams can still expect to share 70-80 percent or more of their code with Xamarin.

Xamarin.Forms allowed the team to share user interface code beyond the shared business logic and service calls because the user interface design needs were modest and the app was not destined for the app store. While it is possible to create more advanced designs with Xamarin.Forms, development teams should carefully investigate the shared controls’ visual and functionality restrictions compared to their native counterparts’ design freedom. It is possible to mix and match Xamarin.Forms and native screens within the same app; it’s also possible to tap into native controls thanks to custom renderers, effects, and native wrappers.

Along with the client side, building a scalable and secure back end for centralized data storage was also critical. Azure App Service allowed the team to build this back end quickly using the same C# language used in the client, simplifying any future maintenance needs.

This solution can be applied to any project that requires a dynamic questionnaire or any similar “wizard-style” navigation interface. While this application design can easily be repurposed for other apps that need to present lengthy questionnaires, this could also be leveraged for other scenarios where a guided walkthrough is needed with dynamic branches and decision options.

Connecticut is not the only state conducting such homelessness surveys; the Point-in-Time Count is a national mandate. CCEH recognizes this needs in other states and has offered to make the entire We Count solution open source, to be posted on GitHub soon. CCEH is taking a leadership role in the United States in the fight against homelessness, and this contribution is made in the spirit of helping other state organizations when conducting similar surveys in the future.

Additional resources