The Next App Project (Premium)

After creating four different versions of .NETpad, and documenting three of them, it’s time to move on to something different. Something mobile. Something that could easily be ported to the web and other platforms too.

And I think I have a reasonably good idea, though it’s a lot more complex than it may first appear: An app that my wife (or anyone else) can use to keep track of cocktail recipes. She experiments with cocktails a lot, but she’s been documenting her work using handwritten notes on paper. When I asked her why she wasn’t doing this digitally, she said she had started transcribing them into a Word document.

Hm.

Naturally, my mind turned to the possibility of creating an app, which I think of as Cocktail Buddy for some reason. (Final name TBD.) And yes, I know there are plenty of apps like this out in the world already. As with .NETpad, the goal here isn’t so much to create something unique and original as it is to learn more about software development. And if you really think through what would be required for this app to make any sense at all, regardless of how one made it, there is a lot to do. And a lot to learn. Maybe too much.

This app will also be quite different from .NETpad, which is desirable. Where .NETpad was built from the UI out, so to speak, Cocktail Buddy needs infrastructure as well as a UI. In fact, if this is done correctly, the UI can and should evolve over time independently of everything that’s happening on the backend. And that UI could be minimal in the early stages, just enough to ensure that the app is working. (It could even start as a command-line app, though I didn’t go in that direction.)

The app will need a database or some similar way of storing the cocktail recipes. Ideally, it will be either cloud-hosted or cloud syncable so that the user could access their work from any device. The database itself would need to accommodate some number of ingredients and instruction steps for each cocktail. One or more images. Links to alternative versions of each cocktail with subtle changes. It kind of goes on and on and the needs will grow as the app evolves and because of feedback.

If you think about this as a mobile app, and I do, there are mobile app design issues to consider. I think the simplest version of this app would consist of three screens:

• Main screen. A filterable list of all the cocktails.
• Cocktail screen. A screen for detailing a single cocktail with the ingredients and steps.
• Input/edit screen. A screen for adding a new cocktail or editing an existing cocktail.

But there are so many different ways to present this. And there are additional features. Creating a new cocktail. Editing an existing cocktail, and so on. And more will come up as it evolves.

I feel like Xamarin Forms is the likely choice for my first pass at this. But I got started by prototyping some basic layout ideas in Windows Presentation Foundation (WPF) and Universal Windows Platform (UWP) just because I’m more familiar with those and wanted to quickly mock something up.

I did this two different ways. First, as a hard-coded XAML layout just to get an idea of what that might look like. And then a more dynamic version in which the layout was built dynamically in C# using a back-end data source.

There’s not much reason to document those approaches here, since neither reflects how the mobile version of the app would be made (or was made, since I did get started on that next.) But it may be worth showing the work just you can see how I progressed from the first XAML-based mockup in WPF to an actual mobile app in Xamarin.Forms.

I worked up the hard-coded XAML-based UI just to see what this might look like and formatted it in the rough aspect ratio of a phone. This is the WPF version.

When that was complete, I set out to recreate the app using C# code. This required two things: A C# list as a temporary local substitute for a database and a way to dynamically create XAML in C# code. Both came with their own challenges.

As you may recall, we had made lists of strings for the font properties in .NETpad, but for this app, I would need to first create a Cocktail object—using a C# class, which is a lot like a C struct—that contained multiple properties for things like name, descriptions, ingredients, and steps. And then I needed to make a list of these objects as a basic and testable substitute for whatever database the app will eventually use.

So I created a new WPF project in Visual Studio and added a Cocktail class file with the three most basic properties first: Photo, Name, and Description. Each is a string, and the Photo property will contain the name/path of the photo used for that cocktail. It looks like so in this first version:

class Cocktail
{
    public string Photo { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }
}

The XAML is minimal in this version since I created most of the layout with C# code. This is kind of dumb, frankly, and it’s not how you would ever do this in a mobile app. But it does work. Rather than go to the effort of formatting all the code here, I’ll present this screenshot instead. Here, you can see the creation of the list of cocktails and the start of the for-each loop that dynamically generates the layout needed for each cocktail in the list.

The result is a version of the app that looks just like the static first version, but where the data is semi-dynamic and the layout is almost fully dynamic.

It’s just a single page app and it’s pretty basic, and because writing all that code was sort of a waste of time anyway, I decided to move over to Xamarin.Forms and make something a little more sophisticated that can target Android (and, technically, iOS, though that requires a Mac). Xamarin.Forms works like UWP, in that it also uses XAML with code-behind C#, but the XAML capabilities and available controls are different. And there are complexities related to supporting both Android and iOS, some of which seem unnecessary to me (and are hopefully fixed in .NET MAUI).

For the first mobile version of the app, I recreated the Cocktail class file, but this time I created the Cocktails list in App.xaml.cs, at the app level, so that I could access its contents more easily from any screen I later created.

And this time, most of the code for the main screen happens in XAML, which is to say MainPage.xaml, and not in C#, because I’m using data binding. So the XAML to display the cocktail list looks like so:

<ListView Grid.Row="1" ItemsSource="{Binding Cocktails}" HasUnevenRows="True">
    <ListView.ItemTemplate>
        <DataTemplate>
            <ViewCell>
                <Grid>
                    <Grid.RowDefinitions>
                        <RowDefinition Height="Auto" />
                        <RowDefinition Height="Auto" />
                        <RowDefinition Height="Auto" />
                    </Grid.RowDefinitions> 
                    <Image Grid.Row="0" Source="{Binding Photo}" Margin="0,0,0,5" Aspect="AspectFill"  />
                    <Label Grid.Row="1" Text="{Binding Name}" Margin="0,0,0,5" FontAttributes="Bold" />
                    <Label Grid.Row="2" Text="{Binding Description}" Margin="0,0,0,30" />
                </Grid>
            </ViewCell>
        </DataTemplate>
    </ListView.ItemTemplate>
</ListView>

I also customized the navigation bar to display the app’s name, ensuring that it will remain on-screen if the user scrolls through the list of available cocktails. And when you run the app in an emulator, it looks a lot like my WPF mockup, basic but functional.

Data binding makes sense here because the number of items we’re displaying is unknown and we need a dynamic and “live” layout: It will simply iterate through the source—the Cocktails list we defined in App.xaml.cs, though a later version will pull data from a database—and display the contents of the Photo, Name, and Description properties of each.

From there, I started working on the other screens.

The second screen is where we will display all of the contents of each property for a single cocktail; not just the photo, name, and description, but also each ingredient and step. This required some additions. First, I had to build out the cocktails list with ingredients and steps. And then I needed to make sure we’re displaying the right (selected) item. In my initial try at this, I’m passed a Cocktail object from MainPage.xaml.cs to this new screen, but there are other ways to do this, I know.

Anyway, displaying a cocktail works.

After that, I started working on editing existing cocktails and adding a new cocktail. I figured this could be the same screen, since it would use the same UI. So I just created two different constructors: if EditCocktail() is called with no arguments, it’s a new cocktail. But if you pass it a cocktail (or, really, a cocktail’s ID)—it will present the edit interface.

I’m still working on this part of the app as I write this, but it seems like it will work fine. The bigger issue is that Xamarin.Forms doesn’t provide a visual XAML designer, so testing the app requires tediously launching the app in an emulator or an attached phone.

Anyway, that’s where I’m at so far.