Marc Palmer

One of a series of posts about our next app as we make it. It’ll include some details about our technology and design choices and challenges.

Since I added some functionality to Bloop that uses Flint, we have been getting Flint’s detailed logging for free. You can however have too much of a good thing.

By default Flint’s logging will let you know when every action you perform starts and completes or fails. As I have added actions for some of the on-screen controls that show in our content player, the console output has become a bit too noisy.

Flint’s logging lets you toggle logging levels per-topic (a Feature is a topic) at runtime, so all I had to do was call this for the features that are too noisy and set the log level to warning on those, as I want debug for everything else in the app at the moment.

What we were getting was a mix of our on-screen controls logging as well as output from Flint’s internal workings.

🐞 16:58:18.428 Debug • main | Activity 'Dispatch' | OSDFeatures/PlayerOSDFeature/#ShowPlayerOSDAction | Starting | State: XXXXXX
🐞 16:58:18.428 Debug • main | Activity 'Dispatch' | OSDFeatures/PlayerOSDFeature/#ShowPlayerOSDAction | Completed (success (not closing action stack)) | State: XXXXXX
🐞 16:58:18.428 Debug • N/A | Activity 'Intent Dispatch' | FlintFeatures/SiriIntentsFeature | Action completed but did not return an intent to donate: Request 5 for PlayerOSDFeature action ShowPlayerOSDAction

The fix was very simple, but I had forgotten my own Flint API for this and hadn’t yet written up Flint documentation for it, so I added it. I changed my code so that the App delegate does this:

FlintFeatures.setLoggingLevel(.warning)
OSDFeatures.setLoggingLevel(.warning)

All features that are sub-features of those feature groups are now quiet as a mouse. All the other features of the app retain the default logging level.

One of a series of posts about our next app as we make it. It’ll include some details about our technology and design choices and challenges.

Bloop has been in the works on and off since 2017. Late in 2017 I switched my focus to building the Flint framework because I had an epiphany about how I think things should be built, and Bloop would need all this to be a great Apple platforms citizen. TL:DR; Flint lets you design and define the features of your app as small chunks of code, and does cool things mostly automatically like NSUserActivity, URL handling, Siri, Analytics, In-App Purchase feature gating etc.

Now we’re back on Bloop, I have to take this pre-Flint code and turn it into Features and Actions. This is a useful exercise to discuss here as it can help demystify usage of Flint.

My starting point was for the on-screen controls we have, and the app’s default behaviour which is to automatically start playing the last content you were watching.

In order to do this I had to break this down into conceptual features and actions, and then they can be represented in code. This brings clarity to what your app is and represents to users. We’ll just look at the player part of it as an example.

So we have a player feature that lets users play content. Right now, it can show the player UI, and it can be told to play the last content it was playing, so those are two actions: “show” and “play the previous content”.

In code this becomes:

public class PlayerFeature: Feature {
    public static var description: String = "Player"

    public static let show = action(ShowPlayerAction.self)
    public static let playPreviousContent = action(PlayPreviousContentAction.self)

    public static func prepare(actions: FeatureActionsBuilder) {
        actions.declare(show)
        actions.declare(playPreviousContent)
    }
}

The action types mentioned there deal with the internal plumbing of how we show and play the content, calling into other dependencies in the app to do the actual work using a presenter passed in when performing the action.

If we look at the PlayPreviousContentAction, we see something cool:

public final class PlayPreviousContentAction: FlintUIAction {
    public typealias InputType = NoInput
    public typealias PresenterType = UIViewController

    public static let activityEligibility: Set<ActivityEligibility> = [.handoff, .prediction]
    
    public static func prepareActivity(_ activity: ActivityBuilder<PlayPreviousContentAction>) {
        activity.title = "Play the previous content"
    }
    
    …    
}

I’ve not included the details of the perform implementation of that action. However with the above coded and wired up to load the previous content and play it, and the AppDelegate set up to use these actions to start the player when the app launches, we can run the app and we get:

• Free logging of when the player is shown or previous content played (including Flint’s timeline/activities debugging tools)
• Siri prediction for the playback of previous content.

This latter part is great. Though I’m cheating a bit because without implementing anything else new the app starts and shows previous content anyway — Siri already starts suggesting I run Bloop to show the previous content when I’m at work. Flint deals with all of this because of the activityEligibility setting in the action. The app has no explicit code to register activities.

It already feels like we’re getting things for free with Flint. I just need to hook up the App delegate activity continuation code to call into Flint and we’ll have something that can properly handle this when there are multiple actions or URLs that could launch the app.

One of a series of posts about our next app as we make it. It’ll include some details about our technology and design choices and challenges.

Bloop will not be releasable until well after iOS 13 is public. It’s a spare-time project right now and that means progress is slow. There’s often a great benefit to this however, in that you get a lot of “out-of-band” time to think about the problem you’re solving and how to do it.

As a consequence of this future release date, we can use all the iOS 13 specific APIs right now and this includes SwiftUI.

Our app is a sort of video player with on-screen controls and a bunch of UI for editing content or settings. Most of our on-screen controls are likely to use UIVisualEffectView for system blurs, vibrancy and materials. This sadly means we can’t seem to use SwiftUI for this because of issues with nesting views inside the effects views and SwiftUI not supporting materials or vibrancy yet.

However since the Xcode 11 beta which added support for SwiftUI forms, the main editing and settings UI have turned out to be a brilliant candidate for SwiftUI. Especially so because we will want to build up many different variations of some of this UI based on the user’s content. SwiftUI should make this really easy because we can conditionally include UI elements easily in code.

This approach has already allowed us to quickly prototype the UI and prove out possible navigation controller issues we were concerned about. I also learned something I never fully understood about UINavigationController — namely that no matter what nesting level a view controller is, if it pushes something new onto the navigation stack, that nested view controller’s navigation item is used for Back navigation. This is really smart and very handy — and amazingly is supported with SwiftUI code that sets navigation bar titles, even when nested inside a UIKit UINavigationController and another child UIViewController. Go SwiftUI team!

Obviously all things SwiftUI are still very rough, but we found a part of the app where SwiftUI will give us a great deal of productivity and reduce code while minimising risk. In the unlikely event it doesn’t work correctly, it has been so easy with SwiftUI that we won’t lose much if we then have to write it in UIKit.

One very painful problem with SwiftUI has been that at the time of writing, it seems impossible to run SwiftUI previews that are inside a framework of your own or in an app containing certain frameworks — the preview process crashes with what look like Thread Sanitizer related issues. We have to run previews in a separate project with no dependencies as a scratchpad.

I’ve raised Feedback of course (FB6962455 “SwiftUI preview canvas crashes when adding a framework to an app”).