Zero Inbox

Milestone: Zero Inbox can handle HTML emails now. There are some rough edges but it's good enough for today, and maybe even for the launch.

Many of us don't realize that a lot of the emails we receive are actually not plain text. They are HTML with CSS and everything. The HTML email uses a subset of the HTML tags and doesn't support JavaScript. But, that doesn't change the fact that if you are building an email client, you have to be able to render HTML.

This is easy if you are just building a web app. Web apps run in browsers and HTML rendering is the core functionality of a browser. It's not as easy if you are building a mobile app. Both Android and IOS offer a browser component that can be embedded in mobile apps - WebView in Android and WKWebView in IOS.

Spent yesterday wrangling the WebView/WKWebView library for Flutter. It was disappointing to realize that the official library (webview_flutter) lacks some important functionality, such as setting zoom and choosing a font-size. Especially because both WebView and WKWebView support this functionality. So, I ended up using a 3rd party library called (flutter_inappwebview), which still partly uses WebView under the hood I believe.

Another quirk I had to deal with was the layout needs of the WebView Flutter Widget. It really didn't like being in a container that gave it infinite height. I ended up wrapping it in a container that resizes itself after the WebView component is done rendering the HTML so that it knows about the height of the content. It's gross. I know 🤷‍♂️

In my first update, I had mentioned refactoring the example email client app out of the Flutter Gallery, and into a new app I created with the goal of learning Flutter quickly and painlessly.

Learning I did. Was it quick and painless? Depends on who you ask. I found it to be painful, but quick.

First step was to literally copy the Dart files that belonged to this email app into my app. And immediately attempt compile & run. The goal here is not to cross our fingers that it just works. That ain't gonna happen, friend. But letting Flutter scream while it attempts to compile the Frankenstein I provided produces a todo list for me.

The rest of this process is a loop.

1. Fix some errors
2. Attempt to compile
3. Go back to step 1 until the app just compiles and runs.

Hopefully after every iteration of this loop, we have fewer errors.

I need to exercise some discipline here. I can't let my ADHD go all perfectionist here. I don't know this language or framework. I also can't let my efficiency obsession to attempt to keep as much code as possible just because every line is technically working code that can teach me something. I need to focus on learning specific things, not just anything. I need to execute with a focus on moving forward.

Long story short, I nix a lot of stuff. Theming and I18N are the first to go. Anything I can't nix, I fix just enough keep Flutter from screaming at me. Little ashamed to admit but I even downgraded my Flutter version so that I don't have to fix a ton of null-safety issues the example code came with.

But I reach a milestone.

I have an email client app that compiles and runs on web and the Android emulator.

In order to build a Gmail client, I need access to the Gmail API. Well, it turns out Gmail API access is a little hard to get, understandably. It requires an independent, 3rd party security audit that may cost upwards of $15k. Ouch. Hit the first roadblock.

Google specifically mentions "the ability to access data from or through a third party server" necessitating the $15k-$75k security review. Prior to this point, the architecture I had in mind included a backend that helped classify emails into more categories than Gmail currently does (e.g. "requires action", "records/receipts", etc.) Improving the search in Gmail was another goal I had and it definitely requires a server to store and index the email data.

Constraints make us more creative. I realize I can actually build this classification engine on the client side. It will be a more interesting way to implement this feature anyhow. Improving search only on the client-side feels like a bigger challenge but there are ways I can improve the Gmail search without any backend changes.

Result: Scope reduction and new architecture that is only client-side.

Need to figure out how much I can store on the client (Android, IOS and web) and how to do that with Flutter.

Dart is a cool language. It's a little bit Java-like, but it supports dynamic typing where you don't have to specify the type of a variable when you are declaring it. Although it also offers and encouraged type safety, so I found myself writing it like I used to write Java.

The documentation is pretty good. I also found the language pretty interesting so started reading the Dart language tour. Probably won't finish it right away. It's more useful to see some code and then come back to read the relevant parts.

Challenge:

I didn't know Flutter or Dart at all. But I have experience as building software and already know a few programming languages quite well so learning a new programming + framework isn't super scary, but it's still time consuming.

How I tackled it:

I checked out at a few tutorials. Finishing a tutorial isn't quite my style. It feels like too big of an investment with unknown returns. Flutter has great documentation. I started reading the documentation. Reading documentation beginning to end isn't quite my style either. I skimmed and focused on parts that helped me learn the most. Then I came by the Flutter Gallery repo.

Next challenge is to refactor the example email client app out of Flutter Gallery and into a new app of my own. This will teach me a lot of Dart and Flutter. Also, UI is my weakness. This example app has the UI of an email client. Bingo.