DEV Community: Angelo Stavrow

Stupid SwiftUI Tricks: Debugging Sheet Dismissal

Angelo Stavrow — Mon, 14 Sep 2020 18:49:01 +0000

Last week, I spent some time solving an odd bug with the WriteFreely client's iOS app.

When you're looking at the list of posts, you can tap the gear button to get to the settings screen, which presents you with a form for logging into your WriteFreely instance:

As you might expect, you can tap the close button in the upper-right (ⓧ) to dismiss the sheet.

Except… well, if you tapped into one of the login form's fields, you end up in a state where tapping on the close button didn't seem to have any effect.

Okay, so that's not entirely true — if you added a print statement to the button's action, you'd find that the first tap does register, toggling presenting view's the isPresentingSettingsView flag correctly; it just doesn't have any effect.

The workaround, while I'd been testing the app, was to dismiss the sheet is by swiping down on it — a standard (if somewhat undiscoverable) system gesture.

Interestingly, when you'd tap in any form field, you'd also receive the following warning in Xcode's console:

2020-09-11 09:56:01.927435-0400 WriteFreely-MultiPlatform[37593:6860302] [Presentation] Attempt to present <_TtGC7SwiftUI22SheetHostingControllerVS_7AnyView_: 0x7fb24a7297f0> on <_TtGC7SwiftUI19UIHostingControllerGVS_15ModifiedContentVS_7AnyViewVS_12RootModifier__: 0x7fb24c905ac0> (from <_TtGC7SwiftUI19UIHostingControllerGVS_15ModifiedContentVVS_22_VariadicView_Children7ElementGVS_18StyleContextWriterVS_23ContentListStyleContext___: 0x7fb24a711ec0>) which is already presenting <_TtGC7SwiftUI22SheetHostingControllerVS_7AnyView_: 0x7fb24c80eaf0>.

There's a lot of cruft there, but it hints that SwiftUI is trying to present a view that's already being presented. This suggested to me that the hosting view is getting re-rendered when a login form field becomes the first responder, finds that the isPresentingSettingsView flag is set, and tries to present the sheet again.

Okay! This is something we can test! Here's what the settings view looked like:

import SwiftUI

struct SettingsView: View {
    @EnvironmentObject var model: WriteFreelyModel

    @Binding var isPresented: Bool

    var body: some View {
        VStack {
            HStack {
                Text("Settings")
                    .font(.largeTitle)
                    .fontWeight(.bold)
                Spacer()
                Button(action: {
                    self.isPresented = false
                }, label: {
                    Image(systemName: "xmark.circle")
                })
            }
            .padding()
            Form {
                Section(header: Text("Login Details")) {
                    AccountView()
                }
                Section(header: Text("Appearance")) {
                    PreferencesView(preferences: model.preferences)
                }
            }
        }
    }
}

(For debugging purposes, I've simplified this a tiny bit: originally that HStack was in a separate SettingsHeaderView struct.)

To test the hypothesis, I started by commenting out the entire Form. Everything then worked fine in presenting and dismissing the sheet, but of course, it's not a very useful sheet without that form. 😅

If I just included the appearance form, that works fine too. That narrows things down here — or so I thought.

There are two ways to dismiss a sheet. The first is to pass the hosting view's presentation state as a binding to the presented sheet, which is what you see in the above listing. Simplified, the SettingsView is presented from the PostListView like this:

Button(action: {
    self.isPresentingSettingsView = true
}, label: {
    Image(systemName: "gear")
})
.sheet(
    isPresented: $isPresentingSettingsView,
    content: {
        SettingsView(isPresented: self.$isPresentingSettingsView)
    }
)

You can also use @Environment(.presentationMode) in the SettingsView to dismiss itself. You declare the property wrapper at the top of the struct like so:

@Environment(\.presentationMode) var presentationMode

…and call its dismiss() method in a button action, like so:

Button(action: {
    presentationMode.wrappedValue.dismiss()
}, label: {
    Image(systemName: "xmark.circle")
})

Interestingly enough, using this method to dismiss the sheet no longer triggered the console warning when I tapped into any login form field. Could it be? Was the problem solved? 😃

Nope. 😬

If you filled out the form and logged in, then that same warning was logged three times in the console. If you logged out, the warning was logged again. But this looked like progress! It seemed likely that something in the account views was triggering this, so I explored that a little deeper.

The AccountView swaps between an AccountLoginView and an AccountLogoutView based on the state of an isLoggedIn flag in the AccountModel. My prime suspect was the AccountLoginView, which has an .alert(isPresented:) modifier attached to it. If there's an error logging in, this is triggered and an alert is presented depending on which of the three AccountError cases are present. Because the .alert(isPresented:) and .sheet(isPresented:) modifiers work similarly, maybe some wires were getting crossed there? This is, of course, a beta framework running on a beta operating system in a beta IDE!

So, I started with an easy test: commenting out the .alert(isPresented:) modifier, and see what happens on login.

You guessed it: this doesn't change the behaviour — the warnings are still logged, and the sheet can't be dismissed.

Digging further and further, setting breakpoints and stepping through code, commenting out blocks to see if they were the culprit, got me nowhere. I finally started searching DuckDuckGo for SwiftUI "Attempt to present" "which is already presenting" and eventually found this year-old forum comment on Swift.org:

Is it the current recommendation, to put modal views & the triggers outside NavigationView, or is it only to circumvent an existing bug?

🤦

Yep. Taking the .sheet(isPresented:) modifier out of the PostListView and attaching it to an EmptyView outside of the NavigationView solved the issue. Nothing in the docs on NavigationView, View Modifiers, or sheet suggests this could be a thing.

So, yeah, the title of this post is a bit misleading — it turns out that I spent a couple of hours trying to figure out what was happening, when an undocumented bug in the framework was the cause.

Again: this is a beta framework, on a beta operating system, and frankly the amount of SwiftUI documentation that's already out there is surprisingly good. But it's a little frustrating to have spent a couple of hours debugging a warning that could have been avoided with a one-line disclaimer in the documentation. Hopefully, this will be helpful to anyone that searches for a similar issue!

For those of you that want to see the code, here's the fix in the app.

WriteFreely Mac/iOS App: A Progress Update

Angelo Stavrow — Fri, 28 Aug 2020 20:21:58 +0000

It feels like it was just yesterday when I shared some initial screenshots of the WriteFreely app prototype running on iOS and Mac.

(In fact, it was almost four weeks ago.)

I've been making a lot of progress on this, and I'd love to show you where the app is today.

Pictures, Worthy of A Thousand Words

How about starting with a few screenshots? This is subject to change, but it's likely not going to change much.

Above, you'll see the current version of the app, running on iPhone and iPad.

The first iPhone screenshot shows the list of posts in my Testing collection, a private blog which I'm using for —you guessed it— testing. Tapping on the < Collections navigation link at the top-left will let you choose another collection; other buttons above and below the list let you create a new local post, refresh from the server, and access settings and preferences.

Tap on any post in the list, and you'll be taken to the app's editor, as shown in the second iPhone screenshot. Any edits you make here are saved locally, and if you like, you can publish it to your WriteFreely instance.

The iPad screenshot shows the same navigation hierarchy, and like the iPhone version, it works just as you'd expect on iPadOS — a sidebar to choose the collection, a table to choose a post in the collection, and the selected post in the editor.

Here's the app running on the Mac — the same kind of navigation, as suited to the Mac. You can more clearly see how the app's editor departs a bit from the web editor, too, with a defined area for the post's title (if you choose to add one), and another text area below for your post's content.

Oh, and of course, "dark mode" looks great. You can choose to have the app display a light scheme, a dark scheme, or to simply follow your system's setting.

Will It Post?

The basic flow of the app right now is straightforward. On launch, you're not logged in to your account, but you can create new posts that only live on your device. These posts currently show a "draft" badge, though that's going to get a less-confusing name.

As of the time of writing, the app doesn't yet store anything on disk except for your colour-scheme preference and your logged-in state, so if you quit the app —or if it crashes, which at this stage, it does every so often— you lose whatever you had. So, naturally, adding local storage is a priority.

To guard against that, you can log in to your WriteFreely account to pull in your collections and posts from the server. Those posts show up as "published", and you can edit them, at which point the "published" badge changes to "edited"; when you're done, you can push those changes to the server, which has the "edited" badge go back to "published".

Similarly, your local posts (the ones with the "draft" badge) can be published to your WriteFreely Drafts —see why it needs to be renamed?— at which point the badge changes to "published".

Tapping the reload button in the post list will fetch new content from the server. Because data loss is unacceptable, the app checks to see what the last-updated timestamps are between the local and remote copies of a post, and then applies the following rules:

If the local copy is unchanged and the remote copy is newer, replace the local copy with the remote copy;
If the local copy has unpublished changes and the remote copy is older, discard the remote copy; and finally,
If the local copy has unpublished changes and the remote copy is newer, notify the user and prompt them to make a decision:

This last bit is still under construction. Once the work is complete, you'll be able to choose which copy to keep — and of course, you'll be prompted to confirm your choice, since this will replace the local copy with the remote copy, or vice-versa.

If you log out of your account, everything is purged from the device — your collection list, your local and published posts, your logged in state, everything.

Still To Do

The easiest thing would be just link to the list of GitHub issues for the 1.0 beta — but I'm going to discuss some of the more pertinent things here, to save you a click.

Of course, saving content to your device is going to be important. There are also a couple of bugs that need fixing because they hang the app or make buttons unresponsive, so that's no good. But mostly, these to-do items fix get the user experience close to that of the WriteFreely web app.

For example — right now the app launches and drops you in the post list. It should instead drop you in the editor with a new (or recent) local post. Those local posts default to Drafts (i.e., not part of a collection), but you should be able to choose a collection for them.

Departing from other WriteFreely clients, there's an "All Posts" list which, as the name implies, shows all posts across your Drafts and your collections, all together. It doesn't, however, tell you which post belongs to which collection (neither does the editor), so that needs fixing.

And there are a few things that haven't been added as issues just yet —and maybe they won't make it into the first release— that include, off the top of my head:

Sorting the list (by created date or last-updated date, ascending or descending)
Changing the logout behaviour to keep only your local posts, and adding another setting to delete everything (the current logout behaviour)
Full-text search
Keyboard shortcuts

We're getting closer and closer to a public beta, so that's exciting! And if you want to contribute, please don't hesitate to reach out in this forum topic!

The Promise vs Reality of SwiftUI Multiplatform

Angelo Stavrow — Mon, 03 Aug 2020 20:16:37 +0000

Happy August, friends! How about an update to last week's post on the SwiftUI app for WriteFreely?

Work progressed pretty well on the shared code last week, to the point that we've got a preliminary UI that displays a list of posts, which you can filter by collection. Tapping on any post loads it into an editor, where you can make changes to the title and content.

On iPhone and iPad, there's also a new post button that will create a new draft. Why only on iPhone and iPad? Well, pull up a chair, and let's chat a little bit about the gap between the promise and the reality of multi-platform SwiftUI apps.

While I was working on the post, I tweeted that I managed to flesh out some of the key UI features for the app across iPhone, iPad, and Mac in a day, thanks to SwiftUI and live previews in Xcode 12, which show you what your views will look like next to your code, and update in realtime as you code.

I further stated:

This is building a native app with the speed of iteration that I've only ever encountered when building for the web.

(I'm looking at you, HTML and CSS. I am not looking at you, React.)

So here's what that latest iteration looks like so far, on iPhone and iPad:

And, after I installed the macOS 11 (a.k.a. "Big Sur") beta, I was able to build the Mac app to compare:

This is in no way a final UI! There's plenty of work still to be done, including replacing the unusual "picker" view for selecting the Collection with a proper sidebar, and adapting the spacing a little better on the Mac app (you can't preview anything for a Mac target, even in Xcode, until you upgrade your own machine to the macOS 11 beta).

The DX of SwiftUI, as illustrated by `ToolbarItemPlacement`

One thing that's very helpful in moving quickly with SwiftUI is how its declarative nature lets you specify the semantics of an element's placement in your view, and letting the framework figure out what that should mean on iPhone vs iPad vs Mac. A great example of this focus on developer experience (DX) is the ToolbarItemPlacement API, which lets you semantically state that a particular item that you add to a toolbar is a .primaryAction, or a .status element, and so on.

This is used in the TextEditor view to place a post status badge in the .status area and a publish button in the .primaryAction area. You can see in the screenshots I shared above how these elements are placed differently depending on whether it's being shown on an iPhone, an iPad, or a Mac — and I didn't have to write a single line of code to customize the difference.

The Letdown of SwiftUI, as illustrated by broken buttons

But life in SwiftUI is not all roses. And that's where the new-draft feature isn't quite working fully, yet. Building the iPhone and iPad versions of the app, tapping the new-draft button above the list of posts works beautifully — it slides a new draft into the list, and then opens it in the text editor for your next great essay. I was thrilled to have this working by the end of my workday on Friday.

I finished installing the Big Sur beta on my Mac this morning, excited to see how everything looked and worked in the Mac app. I expected to have some little UI refinements (that list of posts, for example, needs a healthy dose of padding), but otherwise figured that it'd be a similar experience to, at the very least, the iPad app.

And mostly, it is. The picker is replaced by a popup menu, and you can choose a collection to narrow down the list of posts. You can tap a post in the list, and it'll load it in the text editor, ready for changes. If the post's status changes, it'll instantly update the badge both in the toolbar and in the post list.

And then I tried to create a new draft. On the Mac, clicking on that new-draft button (which appears, interestingly enough, next to the post-status badge in the screenshot) does… nothing. Not a thing. No errors are thrown, no views are drawn, nothing.

The Reality of Multiplatform

I suppose I shouldn't use the word letdown, because "multiplatform" is not a panacea: the reality is that an app expects different things between an iPhone, an iPad, and a Mac. The issue I'm facing with that new-draft button isn't some failing of SwiftUI; it's that the paradigm for how a Mac app treats navigation vs buttons vs instantiating new windows is very different from that of an iPhone, and I haven't structured things the way the framework expects.

So, fine. I'll need to spend a little more time on adapting the Mac client. I would have liked it if it all Just Worked™, but I've got to say: despite a couple of little issues that I need to fix, I'm really impressed with just how much of it worked right out of the box, with no extra work on my part.

Native-app development may not yet happen at the pace of web development, but it's closer than ever.

SwiftUI Previews: Fix 'Cannot convert value of type SomeType to expected argument type EnvironmentObject' errors

Angelo Stavrow — Fri, 31 Jul 2020 18:36:19 +0000

Using @EnvironmentObject is a great way to share data between your views. Previously, I'd been using @ObservedObjects all over my views, and it felt clumsy.

Hot tip: by setting an environmentObject for a NavigationView, any children of this NavigationView can then add a property like @EnvironmentObject var someType: SomeType. SwiftUI then gives them access to the observed object, without you having to pass the object down the navigation tree and through views that don't need access to it:

/* ContentView.swift */

import SwiftUI

struct ContentView: View {
    @ObservedObject var someType: SomeType

    var body: some View {
        NavigationView {
            MyView()
        }
        .environmentObject(someType)
    }
}

/* MyView.swift */

import SwiftUI

struct MyView: View {
    var body: some View {
        SomeTypeList()
    }
}


/* SomeTypeList.swift */

import SwiftUI

struct SomeTypeList: View {
    @EnvironmentObject var someType: SomeType

    var body: some View {
        // Do something with someType
    }
}

But! If you were passing it in to a child view as an ObservedObject and had set up some test object for use in your SwiftUI preview? If you try to pass in your test object, you'll get an error:

Cannot convert value of type 'SomeType' to expected argument type 'EnvironmentObject<SomeType>'

To fix this, use the environmentObject modifier on your child view's preview provider:

struct SomeTypeList_Previews: PreviewProvider {
    static var previews: some View {
        SomeTypeList()
            .environmentObject(testSomeType)
    }
}

Yay, your preview works again!

WriteFreely SwiftUI Client

Angelo Stavrow — Mon, 27 Jul 2020 17:00:29 +0000

Hot on the heels of the developer-preview release of the WriteFreely Swift package, I'm happy to announce that work has started on a new (but related) project: a WriteFreely multiplatform SwiftUI client app.

A multiwhatsit who now?

Right. Let's clear up the jargon, first.

Apple announced SwiftUI at their World Wide Developer Conference (WWDC) last year. Initially, SwiftUI let you build user interfaces across all Apple platforms —iPhone, iPad, Mac, Watch, and Apple TV— with a single, declarative framework, ostensibly replacing the need for using AppKit (on the Mac) and UIKit (on iOS) in building your apps.

This year, Apple took SwiftUI further: you can now build entire apps in SwiftUI. And while you can still build a platform-specific app (e.g., just for the Mac, or just for Apple TV), a new template named multiplatform further coalesces developing for the Apple ecosystem.

A multiplatform app project in Xcode contains a Shared folder, in which the bulk of your app's code lives. There are also iOS and macOS folders for platform-specific customizations, but the idea is that you can use SwiftUI components to build an app that will run natively on iPhone, iPad, and Mac with almost no such customization necessary.

That's pretty cool.

So, what exactly is being built?

This is a WriteFreely client app. You'll be able to log in to your WriteFreely instance, write new drafts, publish them to a collection, and edit them, thanks to the WriteFreely Swift package. And it'll be available for iPhone, iPad, and Mac, thanks to SwiftUI.

Just like the Swift package, it'll be built in the open — the repository is on GitHub, and if you're interested in helping, check out the CONTRIBUTING doc. Developers of all experience levels are welcome to join — just let me know in this forum topic!

The goal is to go from a new SwiftUI project to a complete working app in time for the release of iOS 14 and macOS 11. The launch usually happens in September, so we want to have the app done by the end of August. That's a tight deadline, so we're limiting the scope initially to handle the key actions WriteFreely users would want: creating drafts, publishing them to their WriteFreely instance (either as a draft, or to a collection), and updating those posts.

As we build the client app, we'll be updating the Swift package as necessary. As far as I know, this will be the first WriteFreely client to consume the package, so I expect that we'll find a few surprises that trip us up as we go along. While I tried to build it as robustly as possible, that's the nature of packages that wrap an API — you only find out about their shortcomings when you start building projects with them! 😅

I'll be posting here on both the progress of the work, and the learnings that inevitably come from building a new app in a beta IDE, against a beta framework, while running beta operating systems. I've already found one UX deficiency in adding packages to multiplatform apps, and I'm sure there will be more surprises to share.

More TK!

WriteFreely Swift Package

Angelo Stavrow — Mon, 29 Jun 2020 17:56:15 +0000

It's been a while since I posted an update here, and I wanted to announce a new project: a WriteFreely Swift package that you can drop into your Mac and iOS apps.

You can find it here: https://github.com/writeas/writefreely-swift

What's WriteFreely?

WriteFreely is an open-source platform for writing on the web. It powers the Write.as service (find me here!), and lets you build writing communities on the web.

I was introduced to Write.as and WriteFreely while working with Glitch, where I got to chat about the service and its principles with Matt and CJ. Matt wrote a thoughtful post on Glimmer about the importance of privacy for creating on the web, and CJ built a tonne of cool sample apps that connected to the Write.as service for their Glitch team.

Cool, Tell Me More About The Project

This project represents a couple of firsts for me:

This is the first time I've worked on a Swift package
This is the first time I've wrapped a RESTful API in Swift
This is the first time I've worked with URLSession and Result in Swift

Right now, it's an alpha/developer-preview release. There's a lot of room for improvement here, and I'm looking forward to working towards a 1.0 with the WF community.

As I mention in this forum topic and my Write.as post, the design for the WriteFreelyClient is to leverage completion blocks that return a Result tuple with either a User, Post, or Collection (or an array of these types where that makes sense), or an Error on failure. That makes it pretty easy to build completion handlers:

func loginHandler(result: (Result<User, Error>)) {
    do {
        let user = try result.get()
        print("Hello, \(user.username)!")
    } catch {
        print(error)
    }
}

guard let url = URL(string: "https://your.writefreely.host/") else { fatalError() }
let client = WriteFreelyClient(for: url)
client.login(username: "username", password: "password", completion: loginHandler)

What's Next For The Project?

Good question! There are definitely some major to-do items that are obvious to me:

Add a test suite (there will be some refactoring required to facilitate this)
Create generic-ish request templates to DRY out the WriteFreelyClient public methods
Extend for use with the Write.as platform

Mostly, though, I'm excited for people to try it out and let me know how it works for them!

Dev Diary Week 4 - Saving to SQLite

Angelo Stavrow — Fri, 15 May 2020 16:02:05 +0000

This post is an entry in a weekly development diary on building a feed-aggregator-based blog on Glitch. Only a small part of building an app is code; the bulk of your time is spent planning, experimenting, making mistakes, getting frustrated, and making progress in baby steps.

The plan

Last time, I set up an OPML file with some default feeds that get passed to the feedparsing API. This is a good start, but we don't want the site to want to have to request feeds every time it's loaded — that takes time, and slow sites are a terrible user experience. It's time to add a database!

As I mentioned, storing the feed content in a database saves us from having to send packets back and forth across the internet to get content every time the site loads. There are a couple of practical considerations here:

How often should we check for new content?
How do we deal with updates to content that's already in the database?

The first question is fairly straightforward. We'll want to track the last time we checked for new content on each feed and, if it's been more than a certain amount of time, we can check again for new content. The actual time interval here doesn't matter; what does matter is knowing that we'll be tracking this.

The second question is the kind of thing that sounds like it could become very complex, but should be straightforward because of the project scope I defined in week 2. Specifically, we'll be generating a linklog-style blog that only shares a title, a link back to the source content, and maybe a summary if we can get one from the feed. As such, we don't have to worry too much about how to handle the content of the post changing, though this doesn't help in the case of "reruns" — something all feed-reading apps have to deal with.

So, this week, I'm planning on doing the following:

Determining what the database structure should look like
Creating a way to check when the feed's database entry was last updated
Creating a way to add feed items to the database

This feels a bit ambitious, as I haven't really worked with SQLite before, but we'll see how it goes!

I think we can start with two tables here: a feeds table, which will store metadata about each feed, and an entries table, which will store entries from the various feeds. The theoretical limit for the number of rows in any SQLite table is 2⁶⁴, though that will realistically be constrained by the 140TB maximum database size — still plenty of room for storing the data we're interested in.

The feed table will start off with the following rows:

id (INTEGER): the unique ID for the row, autoincrementing
title (TEXT): the feed title
feedUrl (TEXT): the url of the feed
lastFetched (INTEGER): the timestamp when we last checked the feed (as Unix Time)

The entry table will start off with the following rows:

id (INTEGER): the unique ID for the row, autoincrementing
guid (TEXT): the feed GUID for the entry
title (TEXT): the entry title
entryUrl (TEXT): the url of the entry
publishDate (INTEGER): the date and time when the entry was published (as Unix Time)
feedId: a foreign key matching this entry to the correct feed in the feeds table

How did it go?

All the planning and research work took a lot more time than I expected! Implementing persistent storage is more complex than the work I've been doing so far, and while I'm fairly comfortable working in MySQL or T-SQL, I've never worked with SQLite before, so I needed to do more digging to understand its limitations and built-in types, for example.

I added a storageController.js file that has some methods for initializing and updating the database. These still need some work, but basically here's how storageController works:

When the app loads, it calls initialize(), which checks to see if the database file already exists. If it does, great! It will just output the number of feeds and entries to the server's console. If it doesn't, it'll create it based on a given schema.
When the database needs to be updated, it calls insertNewestEntries() and passes in a feedObject from feedparser.js. It then follows a couple of paths:
- If the feed already exists in the database, it adds any new entries (according to what the latest publishDate is in the feed's stored articles).
- If it doesn't, it creates the record for the feed's metadata in the feed table, and then inserts as many articles as it has in the entry table.

There are a few helper functions in the module as well, for things like getting the ID of a feed, and getting the last published date for a given feed.

What went well?

We're using the sqlite3 npm module and it's really quite a pleasure to work with. I had some example code to look at from the original starter app, which was very helpful.

What did I have trouble with?

Learning the ins and outs of a new database engine can take a while! There were a lot of new concepts to wrap my head around and it took me a lot longer than I thought to get this work done — I didn't post an update last week because of it! This is why it's important to build some flexibility into your estimates.

What did I learn?

I learned a whole lot about using SQLite! While I'm pretty comfortable writing SQL, I'd never used this particular database engine. Luckily, once things are set up, writing queries is pretty similar to MySQL or T-SQL.

What will I work on next week?

I still have some work to do here! For example, when insert the newest entries in the database, the code doesn't update the feed's lastFetched property. We'll need that later.

We also need some way to retrieve everything as a single combined feed, where the entries are ordered by published date. This will be the basis for the content we show on the blog!

And finally, we need to remove some of the endpoints I created in the first couple of weeks — they should be replaced by one to refresh all feeds that are found in the OPML file. Right now I'm adding a DISALLOW_WRITE flag to be sure that no one can add stuff to the database via the /api/parse/:feed endpoint.

Do you have a rule of thumb for estimates?

You never know what kind of interesting problems you'll stumble up when you're working on an app, but it's almost a guarantee that it'll take longer than you expect. How much of a "safety margin" do you generally add to your estimates for unexpected surprises? Has that margin gotten smaller as you get more experienced? What kind of factors, if any, influence your safety margins?

Give your Glitch apps superpowers - keep them awake, lift rate limits, and get more memory and disk space.

Dev Diary Week 3 - Parsing OPML Files

Angelo Stavrow — Thu, 30 Apr 2020 15:48:04 +0000

This post is an entry in a weekly development diary on building a feed-aggregator-based blog on Glitch. Only a small part of building an app is code; the bulk of your time is spent planning, experimenting, making mistakes, getting frustrated, and making progress in baby steps.

The plan

Last time, I worked on an API endpoint for parsing RSS feeds. It lets you pass in an RSS feed URL, and returns some JSON feed metadata and an array of feed entries. That's a good start! However, I want to combine entries from multiple feeds into one "content firehose" feed, so this week we'll look at how to do this.

Parsing an OPML file

Now, I could hard-code an array for feed URLs (maybe as a JSON file), but there's an open standard called OPML that I can use instead. This is an "outline" file, and essentially each entry for a feed URL looks something like this:

<outline
  text="What's displayed (usually title)"
  title="Title of feed"
  description=""
  type="rss"
  version="RSS"
  htmlUrl="https://link/to/site/"
  xmlUrl="https://link/to/feed/"
/>

The advantage to using an OPML file is that they're portable. You can export your susbcriptions to an OPML file to use with this app, and anyone can get your OPML file and import it into their feed reader of choice. Here's mine!

So, this week, I'm planning on doing the following:

Create a default OPML file for this app.
Parse the OPML file to get each individual feed URL.
Pass each feed to the feed parsing endpoint.
Collect all feed entries as JSON.

And, just as we used the feedparser npm package last week, we'll use the opmlparser package (by the same author) to handle the parsing work this week.

How did it go?

I managed to complete all of this work in about two hours between meetings, thanks (again) to great example code in the opmlparser GitHub repository. This serves as a great reminder that writing great docs is just as important as writing solid code for your library/framework/app!

I worked off a remix of my existing work and added the opmlparser package to package.json, and then added the opmlparser.js file to build out the functionality I needed. I also added a subscriptions.opml file to the public directory that included two feeds: the Glitch team's posts on Dev.to, and my own posts on Dev.to. This will give us an interesting de-duplication problem to solve for next week, since both feeds contain my posts.

I then added a /opml route to server.js which does the following:

Gets the feeds in the subscriptions.opml file;
Sends them to the /api/parse/:feed endpoint;
Returns the feed content from each feed in the OPML file to the caller.

This will probably change over time — for now, I wanted a way to see that the OPML file was being parsed correctly.

What went well?

Integrating the opmlparser library was really straightforward. Since it was built by the same author, the code in opmlparser.js is pretty much the same as in feedparser.js.

What did I have trouble with?

I got a bit lost in async spaghetti while trying to send each feed in the OPML file to the /api/parse/:feed endpoint. 😂 There's lots of room for improvement here, but because I expect to rewrite this elsewhere, I didn't want to spend too much time on it.

What did I learn?

I learned a lot about OPML files! I'm used to working with JSON data, and looking at XML sometimes takes a while to figure out. At the end of the day, though, OPML is a variation on an outline document. Thinking about it this way helped me reason through things.

What will I work on next week?

Next week, I'm going to start working on getting feeds into a database!

What's in your OPML file?

OPML files were created to be shared! They're an open standard that most any feed reader will import or export. Here's what's in mine — share yours in the comments!

Dev Diary Week 2 - Reading a Feed

Angelo Stavrow — Thu, 23 Apr 2020 15:09:50 +0000

This post is an entry in a weekly development diary on building a feed-aggregator-based blog on Glitch. Only a small part of building an app is code; the bulk of your time is spent planning, experimenting, making mistakes, getting frustrated, and making progress in baby steps.

The plan

As I discussed in last week's entry, I'm building a web app that will do three things:

pull in RSS feeds of my content from various platforms;
combine them into a single superfeed; and
automatically generate a blog from that firehose feed.

If we look at this project as a black box, here's how it should work:

INPUT          +---------------+          OUTPUTS
               |               |
               |               +----> Aggregated RSS feed
OPML file ---->+ ~rss-firehose |
               |               +----> "Content firehose" blog
               |               |
               +---------------+

In other words, to get your own "content firehose" blog, you would:

Remix the ~rss-firehose Glitch app.
Drop in an OPML file of your own content feeds.
There is no step three!

We're not even close to this yet — right now, ~rss-firehose is just a simple remix of the ~hello-sqlite starter app on Glitch. Let's think about the steps to get us from where we are, to where we want to be! As a side benefit, this will give me a rough outline for the work I want to do each week. I only have a few hours per week to dedicate to this project, so I want to be thoughtful about how I approach that time.

Roughly speaking, here's how I expect things to go. This might change! I'm estimating based on a few things, like how comfortable I am working in Node, SQLite, and how deeply I understand the overall scope of the project. I've built blog templates before, but I've never built a feed reader!

Week 1: Define the scope of the project ✅
Week 2: Pull in a single RSS feed
Week 3: Parse an OPML file into multiple RSS feeds
Week 4: Save feed entries to a SQLite database
Week 5: Generate an aggregated "firehose" RSS feed
Week 6: Create a basic linklog front-end
Week 7: Improve the front-end design

With our pre-requisite week 1 done, let's move on to week 2.

Reading an RSS Feed

Here's what I plan on doing this week; the next section will discuss how it went, and what I learned.

We want to implement a way to read a single RSS feed in our app. Now, we could figure out how to implement a basic RSS feed reader, but there are a few different formats — I can think of at least three different versions of the RSS spec itself, plus Atom, plus... well, you get the point.

Instead, we can build upon the work of those that came before us. RSS has been around for a very long time, so there are great packages we can use in our project to parse feeds in our app.

The package I see being used most in similar projects is feedparser, so we're going to add that to our app. I've never used feedparser before, so I'm going use my time budget for the week experimenting with reading a single RSS feed and outputting it to the server console.

Just to make it a bit more fun, I'll work with my own Dev.to feed!

How did it go?

I worked on the app over a few days, for a total of about four hours.

I started by remixing the actual app so that it's not affected by this week's work. In my remix, I added the feedparser package to package.json and got down to work.

When I'm working off a remix of a Glitch starter app, I usually start by deleting all the files and code I don't need. I'm skipped that this time, because it's nice to have some boilerplate code that I can examine for the SQLite stuff that will come later.

I then added feedparser.js, which takes a feed, tries to parse it, and returns a feedResponse object. The parsing-related work was mostly taken straight from the feedparser package README. The feedResponse object has two properties that get initialized as the parser does its thing: a meta object containing feed metadata, and an items array for feed entries.

Finally, I added an /api/parse/:feed endpoint to server.js — you can add a feed address to this endpoint in the browser, and it'll return the JSON of the feedResponse object. Try it by opening this link in a new tab, or add an RSS/Atom feed of your choice at the end of this link (but make sure it's url-encoded): https://rss-firehose-readfeed.glitch.me/api/parse/

I usually like to ask myself a few questions at the end of my workweek, and I think they're a good fit here too.

What went well?

Generally, adding the feedparser library went well. The README and sample code is thorough enough that I could follow along and make it do what I needed it to do.

What did I have trouble with?

I'm not very experienced with using the (deprecated) request library, and spent a while trying to get port the feedparser sample code to newer libraries in vain. Not wanting to blow my time budget for the week porting code that otherwise worked fine, I decided instead to just stick with request. I can always change that later.

What did I learn?

I learned how to use the feedparser library! I didn't dive into any of the more complex example code with additional dependencies, because the feeds I tested with worked fine as-is.

What will I work on next week?

Next week, I'm going to work on adding some feeds to an OPML file, parsing that file, and handing them off to the /api/parse/:feed endpoint I created this week!

So, that's week 2 wrapped up! Here's where the app is at now:

Do you use a feed reader?

Personally, I like NetNewsWire, and I sync feeds between my devices using Feedbin.

Which on is your favourite? Let me know in the comments!

Dev Diary Week 1 - The Kickoff

Angelo Stavrow — Thu, 09 Apr 2020 15:06:49 +0000

This post is an entry in a weekly development diary on building a feed-aggregator-based blog on Glitch. Only a small part of building an app is code; the bulk of your time is spent planning, experimenting, making mistakes, getting frustrated, and making progress in baby steps.

The build

Like many of you, my online life is lived across several platforms: I've got a personal blog, a microblog, a podcast, open-source projects on GitHub, and photography on Flickr, and my posts here, to name a few. Some of these are more active than others, so I'd like to create a way to pull all of that content together, and turn them into a firehose of my stuff that can be shared in a single place.

I plan on building this on Glitch. What's Glitch, you say? Glitch lets you build full-stack web applications right in the browser, for free, and deploys your changes live to the web as you type. It also lets me remix any public app, giving me a perfect copy of it to kick off my own work. You can learn more about Glitch here.

For my app, remixing the ~hello-sqlite starter app gives me a nice jumping-off point. It's a full-stack app powered by Node.js and Express, backed by a SQLite database. It's embedded below:

I'm also taking some inspiration from ~lmo-feeder, too! Just like that project, I'll add a pretty front-end on it and have an auto-generated blog. For the first iteration, I'll create that with the Pug templating engine.

How it all works

The magic that lets me do all of this is RSS. Essentially, RSS feeds are an XML-based document that can be subscribed to in a feed reader. You can see the feed of my posts here on dev.to, which looks something like this:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>Angelo Stavrow</title>
    <author>Angelo Stavrow</author>
    <description>Web and iOS/Mac developer. Podcaster. Your biggest fan.</description>
    <link>https://dev.to/angelostavrow</link>
    <language>en</language>
    <item>
      <title>create-react-app and Express, together on Glitch</title>
      <author>Angelo Stavrow</author>
      <pubDate>Fri, 14 Feb 2020 15:52:54 +0000</pubDate>
      <link>https://dev.to/glitch/create-react-app-and-express-together-on-glitch-28gi</link>
      <guid>https://dev.to/glitch/create-react-app-and-express-together-on-glitch-28gi</guid>
      <description>&lt;p&gt;&lt;a href="http://glitch.com?utm_medium=weblink&amp;amp;utm_source=dev.to&amp;amp;utm_campaign=blog&amp;amp;utm_content=dev"&gt;Glitch&lt;/a&gt; is the fastest way to get an app or site up and running live on the web, but it runs apps on only one port. Sometimes you need more, like when you're building a &lt;a href="https://glitch.com/culture/react-starter-kit/?utm_medium=weblink&amp;amp;utm_source=dev.to&amp;amp;utm_campaign=blog&amp;amp;utm_content=dev"&gt;React front end&lt;/a&gt; with create-react-app and the back-end with &lt;a href="https://glitch.com/~hello-express?utm_medium=weblink&amp;amp;utm_source=dev.to&amp;amp;utm_campaign=blog&amp;amp;utm_content=dev"&gt;Express&lt;/a&gt;. Here's how to work around this constraint, with a proxy middleware and some port-switching logic!&lt;/p&gt;

      [...]

      </description>
    </item>
  </channel>
</rss>

There are a couple of different variations on this format, but they're all nicely defined. To define the feeds I'm interested in, my plan is to use an OPML file. OPML is another XML-based format in which you can list a set of RSS feeds. Many RSS readers use OPML files for importing and exporting your list of feed subscriptions.

Thinking out loud

While I do keep a "normal" journal, I'm very new to the idea of a development journal. I first tried this in February while working on another app, and found it to be very helpful! Writing out my thought process, my learnings, and my frustrations keeps me moving forward and provides a historical record that's far richer than any collection of code comments and commit messages, in my experience.

(You should still write useful comments and commits, though!)

Do you keep a development journal?

If so, have you found it to be helpful? If not, is there a reason you don't? Let me know in the comments!

create-react-app and Express, together on Glitch

Angelo Stavrow — Fri, 14 Feb 2020 15:52:54 +0000

Glitch is the fastest way to get an app or site up and running live on the web, but it runs apps on only one port. Sometimes you need more, like when you're building a React front end with create-react-app and the back-end with Express. Here's how to work around this constraint, with a proxy middleware and some port-switching logic!

The Problem

Remote development on Glitch has a lot of benefits — it's simply the fastest way to get an app or site up and running live on the web, abstracting away of a lot of the fiddly parts of web development. While this very much makes it a go-to for most ideas that I want to build, I will occasionally run into little speed-bumps that aren't really an issue in a typical local-development setup.

One such speed-bump is that Glitch only serves content on one port. This is typically not an issue, unless you're trying to run both a webpack development server for front-end work and a back-end server in the same project, at the same time — you get one port for serving resources, but both the front-end and back-end servers each want their own port! This is a common scenario when you're building your front end with create-react-app, and your back end with Express.

What's more — Glitch's watcher provides live previews of your changes to a file, but so does create-react-app's Webpack development server!

Ugh. Can't we all just get along?

(Spoiler: Yes. Yes, we can.)

The Solution

I ran into exactly this problem when our team built the web app for Capitol Records' Capitol Royale event in November.

When you create a Node app on Glitch based on the hello-express starter app, the starter project includes a server.js file that implements a basic Express server. This server handles routing to various parts of your app, and is set up to listen on port 3000.¹

Similarly, if you use create-react-app to, uh, create a React app, react-scripts starts a webpack development server that, by default, also listens on port 3000.

So what happens when you're working on a React app, but you also want to add an Express backend?

Essentially, we got it working such that:

If you set your start script to "npm run production" in package.json, it will build the React app and Express will serve the static bundle over port 3000. BUT!
If you set your start script to "npm run development" in package.json, it will concurrently start the webpack dev server/watcher and the Express server. The latter will be listening on port 3001, but you don't need to change anything in your code because: proxies!

😲 WHAT IS THIS SORCERY‽

This works thanks to a couple of moving parts: a proxy that listens for requests on a certain port and forwards them to another, and a bit of scripting and server-side logic that checks for an environment variable to know which port to listen to. Let's dig in!

The proxy

Since we only have one port to work with, we want to watch for requests to some endpoints and forward them through a proxy to our backend server.

If you create src/setupProxy.js, React will register it automatically when you start the development server (details here). So, add this to your src/setupProxy.js file:

const proxy = require("http-proxy-middleware");

// This proxy redirects requests to /api endpoints to
// the Express server running on port 3001.
module.exports = function(app) {
  app.use(
    "/api",
    proxy({
      target: "http://localhost:3001"
    })
  );
};

What React and the proxy are doing here, essentially, is working together to say, "okay, any request to /api isn't a request for a static asset, so pass it on to the target" — that target being the Express server. Don't forget to add http-proxy-middleware to your package.json file, since src/setupProxy.js requires it.

Fun fact! "Globbing" is a weird-sounding word, but what it means is that just adding "/api" in the proxy is enough to correctly route "/api/ping", "/api/user/:userid", etc., to the target — we don't have to add every possible route in the function, which makes our lives much easier.

The ports

With proxying in place, the port situation is less confusing now. However, Glitch will still only serve one port, so we have to do some switching based on what mode we're working in.

In development mode, the webpack dev server listens on port 3000, so we set Express to listen to port 3001, and proxy any requests to /api endpoints through as described above.
In production mode, there is no webpack dev server, so we set Express to listen to port 3000, and Express serves the static resources directly.

The switching

Depending on whether you npm run production or npm run development, different servers and/or proxies are started, and NODE_ENV is set to either production or development — you don't want to have to change this in an .env file.

Setting the value of NODE_ENV is best done in package.json's scripts:

"scripts": {
    "start": "npm run development",
    "development": "NODE_ENV=development concurrently --kill-others \"npm run client\" \"npm run server\"",
    "production": "npm run build && NODE_ENV=production npm run server",
    "client": "react-scripts start",
    "server": "node server/server.js",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  }

What we're doing in the above scripts is defining a development and a production script.

In development, we set the NODE_ENV to development, and use the concurrently package to run both the front-end Webpack server (client) and Express server (server) scripts at the same time. This is like opening two terminals on your local machine, running npm run client in one, and npm run server in the other.

In production, we build the React app, set the NODE_ENV to production, and then start the Express server.

That works great! However, there's still the issue of telling Express which port to use in each mode — we want it to use port 3001 in development, and port 3000 in production. We handle this in server/server.js, where there's a bit of logic towards the end of the file that checks the value of NODE_ENV and sets the listener's port appropriately:

let port;
console.log("❇️ NODE_ENV is", process.env.NODE_ENV);
if (process.env.NODE_ENV === "production") {
  port = process.env.PORT || 3000;
  app.use(express.static(path.join(__dirname, "../build")));
  app.get("*", (request, response) => {
    response.sendFile(path.join(__dirname, "../build", "index.html"));
  });
} else {
  port = 3001;
  console.log("⚠️ Not seeing your changes as you develop?");
  console.log(
    "⚠️ Do you need to set 'start': 'npm run development' in package.json?"
  );
}

const listener = app.listen(port, () => {
  console.log("❇️ Express server is running on port", listener.address().port);
});

Specifically, if NODE_ENV=development, the port Express listens on is set to 3001 and serving assets is delegated to the webpack dev server. We also print a message to the console, suggesting that if you're not seeing your changes as you develop, you might need to check that you've changed the start script in package.json to npm run development.

Likewise, if NODE_ENV=production, the port Express listens on is set to 3000 and a route is added to serve the static resources from the /build directory.

👀 Watching the Watcher

We've now got requests going where they need to go: in development mode, we're serving the webpack development server and proxying API requests to the Express server, and in production mode, we have the Express server handling both the API endpoints and serving the static resources. But we're not quite done yet!

There's one last thing we want to sort out with our project: file watching. Both the Webpack development server and Glitch watch for changes to files, and automatically update the live app as you type. This rapid feedback look is really handy for previewing your modifications, but we don't want the watchers to interfere with each other!

The Webpack watcher only kicks in when the project is in development mode, and watches for changes in the /src directory. We can't really reach in and change much there, but we don't need to — all we really need is to tell the Glitch watcher to only look at what's changing in the /server folder.

We do that by adding a special watch.json file in the project root:

{
  "install": {
    "include": [
      "^package\\.json$",
      "^\\.env$"
    ]
  },
  "restart": {
    "exclude": [
      "^public/",
      "^src/"
    ],
    "include": [
      "^server/",
      "^watch\\.json$"
    ]
  },
  "throttle": 100
}

Here, we specify a couple of conditions for Glitch's watcher.

We only want to run install scripts when changes are made to the package.json and .env files. Installation can take a while, so we don't want to trigger it with any other changes.
We only want to restart the project when changes are made in the /server folder, or to the watch.json file. We're including watch.json in case we need to kick off a restart — a change to the throttle value will trigger this. We're also explicitly ignoring any files in the /public and /src directories from kicking off a restart — we only want the Webpack watcher to handle these files.
We're setting a throttle of 100, which means that the Glitch watcher will wait 100 milliseconds before restarting anything. If that seems too quick, you can increase it.

And with those changes, we're ready to go! If you want a one-click solution, remix this starter app to get going:

Add API routes in server/server.js (I've started you off with a GET route to /api/ping for checking that the server is up) and build your React app in the src directory (the create-react-app starter app you know and love is already there for you to start hacking on).

Have fun, and don't forget to show us what you build!

¹ There's some subtlety to port handling in Glitch that, for the purposes of this article, I'm going to skip explaining. Long story short, Glitch does some work in the background and actually serves apps running on a couple of ports; the default ~hello-node project's Express server uses 3000, but ports 8000 and 8080 would also work, for example.

DEV Community: Angelo Stavrow

Stupid SwiftUI Tricks: Debugging Sheet Dismissal

WriteFreely Mac/iOS App: A Progress Update

Pictures, Worthy of A Thousand Words

Will It Post?

Still To Do

The Promise vs Reality of SwiftUI Multiplatform

The DX of SwiftUI, as illustrated by ToolbarItemPlacement

The Letdown of SwiftUI, as illustrated by broken buttons

The Reality of Multiplatform

SwiftUI Previews: Fix 'Cannot convert value of type SomeType to expected argument type EnvironmentObject' errors

WriteFreely SwiftUI Client

A multiwhatsit who now?

So, what exactly is being built?

WriteFreely Swift Package

What's WriteFreely?

Cool, Tell Me More About The Project

What's Next For The Project?

Dev Diary Week 4 - Saving to SQLite

The plan

How did it go?

What went well?

What did I have trouble with?

What did I learn?

What will I work on next week?

Do you have a rule of thumb for estimates?

Dev Diary Week 3 - Parsing OPML Files

The plan

Parsing an OPML file

How did it go?

What went well?

What did I have trouble with?

What did I learn?

What will I work on next week?

What's in your OPML file?

Dev Diary Week 2 - Reading a Feed

The plan

Reading an RSS Feed

How did it go?

What went well?

What did I have trouble with?

What did I learn?

What will I work on next week?

Do you use a feed reader?

Dev Diary Week 1 - The Kickoff

The build

How it all works

Thinking out loud

Do you keep a development journal?

create-react-app and Express, together on Glitch

The Problem

The Solution

😲 WHAT IS THIS SORCERY‽

The proxy

The ports

The switching

👀 Watching the Watcher

The DX of SwiftUI, as illustrated by `ToolbarItemPlacement`