During a device test, the app APK and test APKs classes use the same classloader, so you’ll have class name collisions. What’s more, depending on the order, the test APK’s classes may be in front of the app APK’s. This is what the root cause of the issue of our tests randomly crashing because some field was not not overridable. The app APK and an obfuscated SDK we used in the test APK had the same obfuscated classpath 🤯

Proguard/Dexguard defaults to putting all the obfuscated classes in the package “o”. However, you can change this using this configuration parameter in your proguard configuration file:

-repackageclasses 'x'

So for all SDK authors out there: shadowjar’ing dependencies and obfuscating the SDK is a good idea. Just be sure to rename your default obfuscation package name so something other than the default! 🙂

Since I wrote that blog, I joined Wayfair’s Core Platform Team as an Architect and what I did was very similar to what I did at KAYAK (short summary of Wayfair work in a previous blog).

After Wayfair, I spent the last year at Twitter as a TL Staff Engineer (before Musk decimated it) and it was different enough that it’s worth describing how it’s a bit different. The great site staffeng.com has a good description of what staff engineers do, as well as the different archetypes of staff engineers.

Staff engineers are generally roles at larger companies and their primary tasks usually intersect with an architect’s tasks:

• Helping set technical direction and engineering perspective —a Staff+ person’s broad and/or deep experience helps immensely with this.
• Mentorship/Sponsorship — Staff+ roles almost always share this responsibility with engineering managers in helping grow the developers in the rest of the company. Mentorship can be done via a more formal 1:1 mentorship program or just via helping out when folks have problems in Slack or via code reviews. Sponsorship requires being aware of what people do throughout the org.
• Exploration — is something shared with architect roles; this means exploring new technologies to see if they will help improve the org.
• Glue — this is a fairly broad term and just means taking care of everything that might fall through the cracks (similar to the “app janitor” tasks I mentioned in previous blogs).
• Tech Lead Archetype — this type of Staff engineer is a partial mix of engineering manager and product manager because the work is an intersection of the work those roles traditionally do and they usually help lead a team or multiple teams.

To elaborate a bit on the TL Staff aspects that I had to do at Twitter, this included tasks like:

• Helping define quarterly goals and OKRs.
• Running the JIRA board/sprints to track if we were going to hit the goals.
• Helping mentor a junior member of the the team.
• Helping out another team (that was missing a TL) clean up their JIRA board and refocus on higher priority issues.
• Helping with the PIP process of a team member.
• Taking care of most of the firefighting issues that would have distracted a team member from focusing on their large project spanning multiple quarters so they could get put up for a promotion.
• Exploring and building out a new way to run sandboxes to help improve the developer experience (these were mini-apps that let developers only load the portion of the project they needed to work on).
• Prototyping ways to map code to teams so we could create/track metrics for teams.
• Communicating/synchronizing with other teams for tooling for the scalable codebases modularization effort.

As you can see, the TL Staff Eng work is very similar to what Architect roles generally do except for the PM/EM intersection. Time spent coding vs. communicating/collaborating is similar as well, with the TL role using a bit more time for the EM/PM work.

Folks who did realize that putting business logic in Fragments/Activities made it hard to test (you usually needed Robolectric), ended up using an MVP (Model-View-Presenter) model (and in some cases, they broke large Presenters down to use cases and interactors or adopted something like the iOS VIPER model). The “View” was an interface that was defined against a Fragment/Activity. The “Model” stayed almost the same but also was where the DB/network access happened consistently. The business logic ended up in the Presenter and the View would call the Presenter and the Presenter would call the View to update the model changes into the view; the Presenter would also handle Android lifecycles with onStart/onDestroy() methods called by the view. MVP was a very calllback-oriented architecture. This is a good summary of what MVP looked like in larger apps:

Unfortunately, these older MVC/MVP architectures are not a natural fit for Reactive UI like Jetpack Compose. The Presenter just ends up being an almost empty data relay middleman which doesn’t have any real logic.

Architectures that Work Best with Reactive UI

Reactive UIs (ReactJS, SwiftUI, Flutter, and Jetpack Compose) work best with, no surprise, reactive data flows. Reactive UIs, by definition, react to changes in their data models, so there is no need for a Presenter (which, by definition, controls the View). Any architecture that has data that can be observed, therefore, will have the least friction when using Reactive UI.

MVVM

The officially supported Android Architecture is MVVM (Model-View-ViewModel); support comes in the form of documentation and library support. Google released this in 2017 as part of the Android Architecture Components (AAC) initiative.

Business logic in a ViewModel updates Fields created as LiveData (for apps not using Kotlin Coroutines) or StateFlow (for apps using Kotlin Coroutines). Apps using RxJava typically keep all network and database calls and other threading in RxJava until they reach the ViewModel boundary where the RxJava streams are exposed as LiveData. For older Android XML layout based applications, Databinding is typically used to bind XML layout field attributes to the LiveData fields on the ViewModel. This typically looks like this:

Folks who adopted the MVVM architecture in 2017 can use this same architecture with Jetpack Compose. However, to optimize MVVM usage for Compose, the fields should be grouped into a state class.

Ironically, when AAC MVVM was announced, the Android community was already starting to adopt the MVI architecture a year earlier.

MVI/Redux

ReactJS was open sourced by Facebook in 2013 and has been the source of inspiration for most of today’s Reactive UI frameworks, and the techniques used in ReactJS also apply to Jetpack Compose. The Redux framework (open sourced in 2015) is a very popular state management framework from the ReactJS world. Redux isn’t usually used in the app world because it requires a global app data store but native apps have multiple screens that get created/destroyed, so you should only consider this for simpler apps.

MVI dates back to a library, inspired by Redux, called “Mosby”, that Hannes Dorfman created in 2016. MVI emits a continuous stream of screen state which Compose can consume directly; this means that the ViewModel is no longer needed in a pure Compose app (or you can consider the MVI state engine as the “viewmodel”). However, an Android Arch Components ViewModel is still useful for retaining state during a screen rotation and handling other Android lifecycle issues like saving state for app resurrection and providing a lifecycle for Kotlin coroutines.

State in this MVI architecture diagram is consumed directly by Reactive UIs like Compose. Because of the rigid definitions of events and state, state can also be played back (aka “time machine” or “time travel” support) for both MVI and Redux.

BLoC

BLoC is Google’s official framework for Flutter which stands for “block of logic”. It’s generally tied to a component/widget, but can also be wired together to create more complex business logic. It was created in 2019, but oddly was never ported over to Android by Google. BloCs are used like viewmodels in Dart.

Elm/MVU

Elm is a web frontend architecture that predates Redux and inspired the Redux (at least according to their documentation :-). It’s also very similar to MVI as you can see:

The main difference is that it provides a View which includes the rendering. In a Jetpack Compose context, an Elm architecture provides a Composable which is the view. This keeps the View rendering closer to the model for tighter coupling.

Pros/Cons

Every architecture has tradeoffs, so you’ll have to decide what works best for you.

MVVM is the Google official standard, but does not rigorously enforce Unidirectional Data Flow (UDF). It will also be the most widely known by developers. The libraries are heavily tied to Android so business logic can’t be shared with Kotlin Multiplatform easily (the Moko MVVM library helps though). Least boilerplate (aka contract definitions with interfaces).

Redux inherently enforces UDF but the data store is at the application level. “Time travel” debugging is supported.

MVI inherently enforces UDF and business logic is easily tested. Data store “Time traval” debugging is supported. Data store is at the screen level.

BLoC has been tested extensively by Flutter applications, but is not part of the Android Arch Components supported by Google. It also enforces UDF. “Time machine” support probably isn’t possible because of the private data stores. Logic maps to widget level while the frameworks usually map to screen/app level.

MVU has tight coupling between the view and model which allows you to group them better and also has UDF enforcement. Tighter coupling doesn’t allow you to use the same business logic for different views, however.

Usage in Jetpack Compose

The short summary is that all these architectures can be used in Compose. If you’re still on MVC/MVP, migrate your code to use a UDF architecture for best results; during migration, you’ll find that if you want to keep MVC/MVP, the Presenter will just end up looking like MVVM with an observable state.

MVVM tends to encourage people to expose individual fields as observables because the DataBinding used in the old XML/Layout system needed widget properties exposed individually. People who have used MVVM prior to Jetpack Compose will tend to use separate fields in their viewmodels that are used for Compose as well.

In contrast, MVI and the other frameworks encourage screen state to be further subdivided into what is needed for each subsection of screen state. Compose widgets can take in a single view state class that is used for view state. MVI also tends to have more boilerplate in interface/class definitions to help enforce proper usage.

It’s also possible to build a layer over MVVM to create an MVVM+ framework which adds more guardrails to encourage using a single state class. We’ll cover existing MVI/MVVM+ frameworks and their tradeoffs in another blog.

Why Do Code Reviews?

A lot of developers look at code reviews as a chore. It’s somewhat understandable given how the typical Agile process does not reward you for doing code reviews, but for getting tickets done. But even your Agile process can be sped up by doing code reviews for others so that they’re more inclined to help review your PRs.

There are lots of other reasons to do code reviews, but these are mine:

• Helps your team increase team/company velocity — as part of the Platforms team, I consider all Android developers and the backend decoupling developers part of my team. The faster new features/fixes get to customers, the faster we can learn from them.
• Lets you mentor others — this is especially helpful during language transitions from PHP to Java or Java to Kotlin. During that transition, everyone is learning a new language and may not know some of the nuances of the new language. If you have more experience with a certain technology/language/feature, it’s worth helping others learn by doing code reviews.
• Lets you learn from others — I can’t count the number of times I’ve learned something from a code review. From new language nuances, to better usage of various SDKs, to better usage of internal frameworks, to new standards of coding. One thing that you can be assured of is that the code base changes, so doing code reviews is one of the best ways to learn about this.
• Lets you set a good team culture — I tend to write code review comments as questions to foster discussion and learning. This provides an environment where people can think about what might be wrong or can encourage a discussion of pros/cons of a solution. Contrast this with a code review comment where someone says “this is wrong..do it this way”, which makes the receiver think less because: a) you provided the solution, and b) they’re less likely to ask questions because you’re telling them what to do.
• Lets you see patterns for improvement — this is the same reason I help a lot of people out in a slack channels. You can sometimes see a pattern that can be addressed in a framework or template or lint rules so your team doesn’t keep making the same mistakes.

How much time does it take? It normally doesn’t take me more than an hour a day; sometimes massive Pull Requests (PRs) take a half hour, but most do not. I think most developers should commit an hour a day to do if they agree w/ any of the reasons above.

Code Reviews vs. Domain Reviews

It should be noted that these are very different. Code reviews usually cover code issues or platform or algorithm or framework issues. Domain reviews still need to be done by team mates who work on the same team/features. Domain issues include nuances like what conditions some element of screen should be visible under, or how certain REST endpoints behave, or the proper flow of a screen…i.e., business logic. I do code reviews unless I’m on the team I’m doing reviews for, or if it’s a review for usage of a framework/SDK I’ve written.

Doing Reviews More Efficiently

It’s hard to do reviews efficiently without some workflow, so here’s what I do during my day.

The Github UI has an indication that a PR has been approved, but that doesn’t mean it has been reviewed by you. Everyone finds different things in a code review, so it always helps the coder and your team if you have time to do a review on an already approved PR. You can usually learn something new too :-)

Github’s web UI (and most other source control systems) has a way to filter open reviews by whether they have been reviewed by you, or whether a review is requested from you, etc. I typically refresh a screen with the “Not reviewed by you” dropdown during a build and take care of the simple/small ones immediately. Not everything is simple, so I’ll look at the bigger ones when I have a bigger block of free time.

Several times a day and before I end the day, I also look at the “Awaiting review from you” category.

You can make incremental reviews (reviews of the same PR) less work by marking files that you’ve looked at as “Viewed”. Each file in the Github PR diff has a checkbox you can click to tag the file so you don’t have to look at it every time.

Github has a lot of email notifications. Once you review a PR, you get a notification for every commit or comment. Set up a mail filter to dump all these notifications into a folder and look through this folder a few times a day; sometimes, you’ll find the discussion in a PR interesting and end up joining the discussion. I usually set up different folders for Android, iOS, and backend reviews.

Lastly, when you add comments that aren’t questions, be sure to add some indication for whether it’s an optional request or required change. At an agency I worked at, we used notations like “#nth” (nice to have) and “#req” (required) that are prefixed to the comment.

How to Help Code Reviewers

I’ve noticed that some code reviews are a lot easier if people put up PRs that explain changes better.

The minimal amount of info we require in a PR is approvers, a JIRA ticket, and a short description. There is a line in the PR template that says “remove this” that should be removed as well (you wouldn’t believe how often the template is not filled in properly by not removing this). A longer description describing why something fixes a bug helps more than “fixes crash in xxxx”.

For screen changes, putting up before/after screenshots help immensely because reviewers don’t have to load up the branch build to see if something looks right. But what helps most is having coders do a review of their own PR. Adding their own comments to point out where bug fixes were actually done or explaining something that might look a little confusing to others who are not domain reviews provides context for the reviewer. The best part of doing a self-review of your PR is you can fix stuff that you should not have committed before a reviewer has to point it out.

Most companies have a code reviews slack channel. If PRs are posted there, that helps let people know that you want a review. This is especially helpful if a PR has been marked “WIP” or “Draft” for a while.

When you put up a review, be sure to request a review in the Github UI from anyone you think your code might affect. Github has a CODEOWNERS file that automatically requests reviews from people who “own” the files your PR touches, but if there are other folks who your code might affect or who might be interested in your code (think of folks on other teams as well…e.g., if you’re adding something on Android, but the iOS folks might be interested in doing the same thing, it’s ok to request a review from someone on a different team to let them know about it).

If you have a PR up, and folks have commented on it already, you may need to push a few commits up but the PR might not be ready for another review. Next to a reviewer’s name on the upper right of the PR screen, there is a “refresh” button (the circular arrows). Clicking on this will request another review from that reviewer via an email notification. This is a lot less disruptive than pinging the reviewer directly because reviewers can batch review the ones they’ve reviewed before.

Hope these efficiency tips help you. If you have any more of your own, let me know in the comments so I can be more efficient :-)

With my 2nd year anniversary at my current company, I thought it’d be a good time to have a bit of a retrospective/introspective/predictive on the Navigation responsibilities of an architect. Futures are inherently not 100% probability of success, but what fun is a New Year’s resolution w/o outing it so you can see if you make it? :-)

Retrospective

First we’ll go over the state of things when I started and things I was able to change. After spending the first month getting up to speed and then getting embedded in an AR/VR team, various macro issues became visible throughout the year:

• Pull Requests took too long to merge
  While getting up to speed by doing PR reviews and trying to update the app’s libraries, I noticed it took days to get eyes on a review because people hadn’t gotten into the habit of going through reviews daily; there was a code review channel you could ask for a review in, but folks usually avoided reviewing large PRs.
  Team velocity is directly proportional to PR velocity, so I continued reviewing just about every PR that was put up for the Android team. This wasn’t noticed until we added GitPrime a year later. It was gamified a bit by my manager so it’s not me dominating the leaderboard now but still can be improved.
• Bad integration w/ Firebase
  The app was still on Crashlytics. Libraries were outdated enough that this could not be done easily. Frequent library updates require smaller deltas, so I initially tried a monthly cadence (with Google’s monthly release cadence) but that ended up at a quarterly cadence because even monthly updates took a lot of time.
  Firebase is more than Crashlytics though, which brings up the next item…
• No network performance monitoring
  There was some performance observability, but it was mostly comprised of attempts to match measurements on web (measurements were even called “page load time” on app).
  There was no observability of network performance. I was able to integrate Firebase Performance (I also integrated this with Kayak’s app and was part of the EAP/beta) to prove that this was useful. After initial integration, we found an API that the app still called but always returned 400 errors. The server side folks also had not prioritized observability at the time so this was never noticed. There were also a set of APIs that were much slower than others that we flagged for the backend folks using Firebase Perf measurements.
  Later on, I built out a Performance Framework that lets us selectively log to our backend (which uses InfluxDB) and Firebase Performance. DataDog and Perfetto were later easily added to this framework as plugins.
• Builds took too long
  Builds were taking too long both locally and in CI. In CI, I solved issues like multiple jobs running duplicate unit testing and a Sonarqube plugin that had a bug that caused other flavors to be built. These issues reduced CI pipeline time from 45min to 18min.
  Locally, builds were taking too long primarily because the laptops didn’t have enough memory. After optimizing our builds down, I still found that the working set was 24GB of memory on a 16GB machine; iOS folks didn’t have this issue because they were CPU constrained. It took a long time to convince management, but this brought full build times down from 20min to 10min.
  I also found that our antivirus software had a huge memory leak of 500MB/day which would also cause swapping. I had to pester the IT folks who then made Crowdstrike fix a 3yr old memory leak.
• App was too flaky
  There were too many “stuck” screens when there were network issues. Screens would be stuck at loading screens or white screens or display products with prices of $0 (aka “free”). The free prices were because of handling random null fields from server APIs by using the Kotlin construct:
  displayedPrice = serverPrice ?: 0.0
  Fixing this required convincing folks via PR comments to use Float.NaN as a default instead of 0.0 as a default so the UI could handle these cases.
  A teammate took care of error handling by building a framework that handled the LCE pattern. The LCE pattern was drilled into me from my time at RaizLabs but sadly not at many other places I know of.
• App was too slow
  This was caused by multiple issues including the aforementioned slow APIs. We were also downloading full sized images. From previous work at KAYAK, I knew images could be reduced to half size w/o users noticing. This helped reduce our network bandwidth immensely.
  Another source of slowness was our app screens not preloading data before the users hit them. I built a PreloadManager framework that helped developers preload data on app startup so it was available by the time users used the screen.
• Broken analytics
  We have some quirky analytics requirements which include a tracking ID for data displayed on a screen; the tracking ID is needed for ad attribution. However, this requirement was not enforced. I added a guard rail to crash in a local dev environment if that tracking ID was missing.
  We also have a quirky requirement that’s the equivalent of requiring “http referrer” for all screens on the app. This was broken in various ways including an interstitial screen that was added by a feature team. I modified our analytics SDK to support interstitials; the SDK was also modified to crash developers who didn’t handle the “http referrer” requirement correctly.
• QA wasn’t efficiently getting App Builds
  The QA folks were downloading APKs manually off Jenkins. I added Firebase App Distribution to our CI process for all our whitelabels and other apps like a driver app and UI demo app (11 projects because we have dev/prod environments). All PRs automatically pushed builds for QA to use. After QA was satisfied with this, I also helped set this up for iOS builds as well so they could use the same app to search for and download builds to test. QA was much happier to say the least :-)
• Perfecto vs. Firebase Test Lab
  When I started, the Quality Eng team had already started integrating Perfecto. I thought this was a bit odd of a choice because it wasn’t a very mainstream solution. Firebase Test Lab, on the other hand was. I knew several large companies (Amex and Citibank) had used it and there was great tooling already built to shard tests on it by LinkedIn. I integrated FTL into our Buildkite jobs to show how simple it was to set up and that it had all the features of Perfecto (including video recordings of failures) while also costing much less; it’s now part of our PR smoke tests.
• Decoupling needed a smoother road and guides
  This has taken up a good part of my second year at this company. Part of our move to the cloud involved decoupling APIs from our PHP monolith to smaller Java Spring Boot microservices. I was involved early on and reviewed/improved some of the training material, then helped review any PRs when folks were starting to decouple (most were PHP devs learning Java so they didn’t have experienced Java developers on their team). I also improved DataDog support and added Swagger support to the autogenerated templates folks used because the early adopters were having a hard time using/integrating these.
  Our official standard for microservices is Maven and Java, but I also created a microservice with Kotlin and Gradle to show how easy and less verbose they were. The microservice was well documented and handled categorization of errors to provide a good example for others to follow.

A good deal of this was not part of my directly assigned duties, but luckily I had a supportive team and management that trusted that I was doing what’s best for the company while I also took care of my assigned duties. At smaller companies, it’s easy to provide course changes no matter who you are or when you are; a few people in a room can move the entire company’s direction in a few weeks. At larger ones, it’s more difficult unless you’re upper management, but you can still help the giant ship go in the right direction with well-timed nudges early enough (i.e. don’t wait until something bad has set in deeply so it’s too hard to move).

But you may say, hindsight is easy, what about the future?

Futures

Before describing what I think are possible futures, it would help to explain what helps me make predictions. By reviewing most PRs, I can see what guardrails are needed and what pains are felt by developers. By following over 230+ Slack channels and doing horizontal mentoring, I can get a sense of what issues need addressing through the company. By monitoring other Kotlin/Android communities (Slack and blogs and conferences), I can get a sense of what will be upcoming for technologies. By participating in Google UX focus groups and beta programs, I can help influence some of the rough edges in products and see what’s coming earlier. In short, plugging in and being connected provides enough data points to predict relatively accurately a year into the future.

These are the main top of mind topics for me in the upcoming year with probabilities of getting them done:

• Jetpack Compose Migration (80%)
  This has to be the main consideration for any Android app in the next year. Jetpack Compose is an entirely new mindset that has the huge potential to improve development times for Android developers. However, what’s simple to integrate and use at smaller companies is a lot harder when you have a company with 50 Android developers, 13 teams, and a huge codebase written with the VIPER architecture. This is a large undertaking because you have to consider migration, guardrails for developers, new testing paradigms, and better frameworks.
  The first major issue is the architecture. Our current application is done using VIPER (took 2 years to migrate from MVP). Jetpack Compose is a reactive architecture, which has no “P — Presenter”. It would have been much simpler if we had used an MVVM architecture which is compatible with a reactive UI. I’ve done a presentation/proposal to create an MVI/Redux framework behind VIPER so that when a feature is migrated to Compose, it should be a simple removal of the VIPER architecture.
  There is a lot more than just an architecture change though. With large companies, you have to build guardrails to help developers do the right thing. We have this complex internal analytics system that tracks the equivalent of “http referrer” on native app, so safeties have to be put in place to make sure that’s handled properly. In addition, we have a performance framework that needs to be hooked into all screens to measure load/wait times for users. We also have an LCE (Loading/Content/Error) pattern that should be enforced so developers account for all these cases on their features. One of the biggest issues with the current VIPER framework is there were no lint rules to enforce correct component calling and that’s a mistake we should not make again.
  Besides all that, we are starting to do UI integration testing and that is very different with Compose. This also has to include accessibility testing. Screenshot testing seems like a natural fit for this.
  Jetpack Compose is also a natural fit for server driven UI which we’ll be attempting with an internal content management system (CMS). There’s also the question of whether Flutter would work better for this use case.
  As you can see, there are a lot of moving parts to getting us onto Jetpack Compose.
• Speed Improvements(80%)
  Despite having made all the speed improvements we did last year, there is space for a lot of other improvements.
  For developer builds, we should look at the new M1x MacBooks to see if we can justify upgrading to them again (and hopefully in less than the year+ it took us last time). If they’re not fast enough, remote builds are another option we can use. Our current 32GB Macbooks thermal throttle way too much, even though they’re a lot better then the old 16GB Macbooks.
  For speeding up the build in general, there are still opportunities to build only modules that users need to build. There are a few blog articles and techniques I’ve seen to minimize the modules that need to be built. Our CI can be parallelized more because we have a 40min job that runs all our tests. There are tools that let you find out which modules have changed so we don’t need to run all the tests and this can be applied to our UI testing as well.
  There are other things that might help to improve build speed but they require code changes. e.g. using Square’s Anvil to remove kapt from a module.
• Backend improvements and app API decoupling (70%)
  We chose a “safe” standard for the API decoupling effort (Spring Boot with SpringMVC and Java) but as we scale out to thousands of microservices, cost becomes a very real issue. For high traffic, reactive frameworks like Spring WebFlux don’t require as many containers for the same amount of traffic as SpringMVC. The JVM and Linux images take up a large amount of space and memory. GraalVM AOT lets JVM applications be compiled down into executables that aren’t much bigger than Golang executables and they start up a lot faster and use less memory, so scaling is much more efficient; large companies like Alibaba already use GraalVM. For a microframework, Quarkus looks extremely promising in not only the support for GraalVM, but the extremely fast development cycles with TestContainers.
  Our native app feature toggles are in serious need of a rebuild on the backend as well as client side. The server side feature toggles are in the PHP monolith and should be replaced. This can be replaced with Firebase Remote Config with an in-house admin UI layer that is friendly for everyone to use. This was a project I was hoping to get to last year but didn’t have time to.
  Logging from native app is super inefficient (we send enough to DDOS our Kibana servers because we filter server-side). The ability to send down configuration strings for logging from Remote Config will give us a lot more configurability and controlled observability when we have issues in a particular section of code as well as reducing traffic we send to our poor servers.
  Because the PHP monolith is going away, we have to decouple our remaining native app endpoints. We have a startup endpoint that is hit on app startup that could be made faster by decoupling it (assuming we can be independent of PHP sessions). Our logging endpoints are also PHP and could be switched to Golang or Quarkus; I started work on a Golang version but shelved it because our infrastructure was not ready to expose public external decoupled endpoints at the time.
• Automation and AI (20%)
  Our AppDirectory and Code Quality metrics can continue to be used for automation (more on our Code Quality metrics initiative should be in a forthcoming company blog). Now that we have ownership metadata in our repositories, we can use that to automate user feedback from the app stores via simple keyword matching or via ML classification.
  For more longshot initiatives, the natural language tools (LaMDA) that Google should be adding to GCP soon can give us the ability to add a smart shopping assistant to the app as well let us add a first-level virtual call center assistant to reduce the load on our call center personnel at high traffic times.
• New Kotlin features (50%)
  Kotlin MultiPlatform may finally be ready for usage. iOS developers might not hate us for sharing a library with them because the new iOS mem model and XCFramework support this Fall will make it an acceptable experience instead of the multithreading/freezing fun it is now. Our internal Scribe analytics library is a clear candidate for this because it has no UI and the upcoming Avro schema for the analytics events has nice Gradle support.
  The improved Kotlin IR backend also means that Kotlin/JS might be stable enough for usage. This has much better support for debugging Kotlin/JS code and will let us replace our internal React/JS UIs with Kotlin/JS without worrying about a lot of Kotlin/JS API changes.
  Kotlin coroutines seem to be getting more widely used in Google libraries we depend on. Up to this point, they’ve offered interop w/ the RxJava we use but it’s obvious that coroutines are the future. In a large codebase, RxJava has more features than coroutines, so it may not be needed, but coroutines are definitely more understandable by people so we should evaluate them. For all new projects I’ve worked on, I’ve used coroutines and they are easier to use in most cases, and also less verbose, but they also come with new footguns we have to document/mitigate.
• New platform features (20%)
  This year appears to be a strong push for Android Foldable devices (though I suspect they won’t take off until Apple sells one). Google appears to have provided enough ecosystem improvements to make them easy to develop for so it’s not a lot of work to support large screen devices like Foldables and Chromebooks. The rumored foldable Pixel should also help the ecosystem if cost is close enough to normal phones instead of the 2x cost for foldables currently.
  Android Widgets will also hopefully get some love from our UX folks now that iOS has them. There are compelling use cases like a delivery tracking widget or a hot sales widget.

There are other organization level changes that can improve team speeds, but the above list only covers things I can directly influence.

The next retrospective should be interesting. Has stating this publicly changed the future already? How far do goals/predictions change even 6–9 months out and how much of this will be done in a year? We’ll find out… ;-)

This common setup isn’t as well documented as I expected given how prolifically the Okta folks blog, so I’m going to cover the issues I encountered recently when setting up a Spring Boot microservice API protected with Okta authentication and used by a React.js web app (sometimes referred to as an SPA or Single Page App) that is also served by the same microservice. I’ll also cover some of the issues I hit getting it packaged for use in production.

JWT vs. OIDC

First of all, it’s important to understand how you’re configuring Spring Boot with Okta authentication. You can either set it up for OIDC (basically OAuth2) authentication or JWT token (signed token with metadata) authentication.

OIDC is not used for Single Page Application web clients like React.js. The authentication forms and flows stay within Spring Boot with OIDC and session management is also done in Spring Boot. This flow requires an Okta ClientId/Secret keypair to be kept on the server so it can generate access tokens.

JWT authentication on the other hand is done with tokens that are validated by Okta servers. The authentication flow is done mostly on the web client (we’ll get to the “mostly” part when we configure Spring permissions). Both the server and the client only require the Issuing URL (used to validate tokens) and the ClientId. The React.js Okta library handles connection to the Okta server and refreshing the JWT token. The server just validates tokens it gets from the React.js client with Okta. All JWT scopes (e.g., email and groups) are managed on the Okta server.

CSRF

CSRF should be disabled for microservices that support only API calls and SPA. It’s only used for Form authentication based web sites. This is why CSRF tokens are needed to prevent malicious attacks from form submission:

CORS

During development of any React.js app, you’ll have to handle Cross Origin Resource Sharing. This means that your Javascript code is trying to contact a hostname/URL that isn’t the same URL as where your web app was loaded by the web browser. React.js apps typically are at http://localhost:3000 during development. At the network level, this is what actually happens so you can recognize it in Chrome devtools:

Authorization Calls

Now that we have an understanding of JWT and CORS, we can see what the network traffic looks like for the login and logout process. We have to understand this a bit before we configure Spring Boot to handle everything.

As you can see in the diagram below, Okta login will redirect to /login/callback and include the JWT token. The logout will redirect to “/”. It’s important to note that these URLs go to your server, not back to the React.js client, so the server has to forward back to the React.js client in the browser.

Okta Configuration

To support debugging of the React.js client, you’ll have to go to Security/API/TrustedOrigins in your Okta Admin Dashboard and add these values to the allowed CORS endpoints:

http://localhost:3000
http://localhost:8080

If you want to use only localhost:8080, you can also edit your package.json and add a proxy to get past CORS issues w/ React.js which Yarn starts on port 3000 (this is typically not worth it):

"proxy": "http://localhost:8080",

Login Redirect URLs

In the Okta Admin Dashboard, you’ll also have to configure your valid login redirect URLs as:

https://www.yourdomain.com/login/callback
http://localhost:3000/login/callback
http://localhost:8080/login/callback

Logout Redirect URLs

And finally, in the Okta Admin Dashboard, you need to configure your valid logout redirect URLs. All these are required to ensure your site is secure and the JWT authentication happens properly.

https://www.yourdomain.com
http://localhost:3000
http://localhost:8080

Spring Boot Permissions

Spring Boot permission configuration can be categorized into setup for CSRF, CORS (during local development), configuration for the React.js client, and permissions for your APIs that need JWT tokens.

CORS configuration and React.js resource handling is done via a class that provides a WebMvcConfigurer Bean:

@Configuration
class CorsConfig(val environment: Environment) {

    val isLocalEnv: Boolean
        get() = environment.activeProfiles.contains("local")

    @Bean
    fun corsConfigurer(): WebMvcConfigurer {
        return object : WebMvcConfigurer {
            override fun addCorsMappings(registry: CorsRegistry) {
                if (isLocalEnv) {
                    // this disables CORS so we can debug the React client easily
                    registry.addMapping("/**")
                        .allowedHeaders("*")
                        .allowedOriginPatterns("*")
                        .allowedMethods("POST", "PUT", "PATCH", "DELETE", "HEAD", "OPTIONS", "DELETE", "GET")
                        .allowCredentials(true)
                }
            }

            override fun addViewControllers(registry: ViewControllerRegistry) {
                // this routes paths to the React.js client routes;
                // excludes our service's read-only APIs, health endpoints, and Wwagger
                registry.addViewController("/web/**")
                    .setViewName("forward:/")
                registry.addViewController("{spring:^((?!/v?/|/health/|/swagger-ui/).)*$}")
                    .setViewName("forward:/")
            }

            override fun addResourceHandlers(registry: ResourceHandlerRegistry) {
                // this is used to handle the /login/callback from Okta from React.js
                registry.addResourceHandler("/login/**")
                    .addResourceLocations("classpath:/static/")
                    .resourceChain(true)
                    .addResolver(object : PathResourceResolver() {
                        override fun getResource(resourcePath: String, location: Resource): Resource {
                            val requestedResource: Resource = location.createRelative(resourcePath)
                            return if (requestedResource.exists() &&
                                requestedResource.isReadable
                            ) requestedResource else ClassPathResource(
                                "/static/index.html"
                            )
                        }
                    })
            }
        }
    }
}

The WebMvcConfigurer’s addCorsMappings() only disables CORS if the currently active Spring profile is “local” which indicates it’s the local dev environment.

The React.js client’s routes live in the /web path and the overridden addViewControllers() adds all the special routing for it so that the browser gets routed properly by React.

Finally, addResourceHandlers() adds handling for any images in the /static folder and redirects for Okta’s /login callback.

A class that subclasses WebSecurityConfigurerAdapter is used to configure CRSF and API endpoint permissions:

@Configuration
class SecurityConfiguration(val environment: Environment) : WebSecurityConfigurerAdapter() {

    val isLocalEnv: Boolean
        get() = environment.activeProfiles.contains("local")

    override fun configure(http: HttpSecurity) {
        http.sessionManagement()
            .sessionCreationPolicy(SessionCreationPolicy.STATELESS) // web UI is SPA

        // CSRF tokens not needed for SPA
        http.csrf().disable()

        http.authorizeRequests()
            .requestMatchers(EndpointRequest.to(HealthEndpoint::class.java)).permitAll()
            .antMatchers("/**/*.{js,html,css}", "/", "/static/**").permitAll()
            .antMatchers("/web/**").permitAll()
            .antMatchers("/built/**", "/images/**", "main.css", "/favicon*", "/site.webmanifest").permitAll()
            .antMatchers("/swagger-ui/**", "/swagger-ui.html", "/v3/api-docs/**").permitAll()
            .antMatchers("/actuator", "/actuator/**").permitAll()
            .antMatchers("/v1/query/**", "/v1/ui/**").permitAll()
            .antMatchers("/login/**", "/logout").permitAll()
            .anyRequest().authenticated()
            .and()
            .oauth2ResourceServer().jwt()

        // Send a 401 message to the browser (w/o this, you'll see a blank page)
        Okta.configureResourceServer401ResponseBody(http)
    }

    @Throws(Exception::class)
    override fun configure(web: WebSecurity) {
        web.ignoring().antMatchers(HttpMethod.OPTIONS)
    }
}

First, since we don’t support server-side web pages, we can turn off sessions so they don’t waste memory. After that, CSRF is disabled because we don’t need it.

For URL permissions, we allow all the static resources needed by the React.js client. We also allow unauthenticated access to the Swagger UI and heath endpoints. Next we allow access to APIs that the React.js client uses as well as login/logout redirects. Anything not mentioned in this configuration is then configured to use JWT authentication by default.

The http OPTIONS method is also configured as allowed, because web browsers use this to check whether CORS is configured properly for the React.js call to the APIs.

MockMvc JWT Testing

Doing testing of authenticated APIs was also not documented that well; there is an Okta blog that describes how to do OIDC testing with Spring’s MockMvc that almost gives you enough hints to get it working.

Spring’s website doesn’t document this well either, so I had to get some help from folks on Gitter.im’s Spring Security forum (big thanks to Nicolas Fränkel pointing me in the right direction).

The core code is the following that sets up a valid security context with a JWT token:

private fun authenticationToken(jwtToken: Jwt): AbstractAuthenticationToken {
    return JwtAuthenticationConverter().apply {
        val claim = jwtToken.claims["sub"] as String
        setPrincipalClaimName(claim)
    }.convert(jwtToken)!!
}
private fun setupJwtMvcContext(email: String = "kyee@somewhere.com") {
    val jwt = Jwt.withTokenValue(ID_TOKEN)
        .header("alg", "none")
        .claim("sub", email)
        .build()
    SecurityContextHolder.getContext().authentication = authenticationToken(jwt)
    val authInjector = SecurityContextHolderAwareRequestFilter()
    authInjector.afterPropertiesSet()
    mvc = MockMvcBuilders.webAppContextSetup(this.context).build()
}

companion object {
    // just a valid dummy JWT token
    // see https://developer.okta.com/blog/2019/04/15/testing-spring-security-oauth-with-junit
    private const val ID_TOKEN = "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9" +
        ".eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsIm" +
        "p0aSI6ImQzNWRmMTRkLTA5ZjYtNDhmZi04YTkzLTdjNmYwMzM5MzE1OSIsImlhdCI6MTU0M" +
        "Tk3MTU4MywiZXhwIjoxNTQxOTc1MTgzfQ.QaQOarmV8xEUYV7yvWzX3cUE_4W1luMcWCwpr" +
        "oqqUrg"
}

You can then call setupJwtMvcContext() at the beginning of a test to load the JWT info into the security context:

@Throws(Exception::class)
@Test
fun testAddAdminInvalid() {
    setupJwtMvcContext()
    val addRequest = AdminUser(
        email = "invalidemail",
        name = "Test User"
    )

    val postBody = addRequest.asJsonString()
    mvc.perform(
        MockMvcRequestBuilders.post("/v1/admin")
            .content(postBody)
            .contentType(MediaType.APPLICATION_JSON)
            .accept(MediaType.APPLICATION_JSON)
    )
        .andExpect(MockMvcResultMatchers.status().isBadRequest)
}

You can then retrieve the email address from the JWT token by doing this in your controller:

@PostMapping("admin")
@PreAuthorize("hasAuthority('SCOPE_email')")
fun addRepo(
    @RequestBody addAdminRequest: AddAdmin,
    @AuthenticationPrincipal jwt: Jwt
) {
    val email = validateEmail(jwt)
    adminService.addAdmin(addAdminRequest)
    logger.info("${addRepoRequest.repoName} added by $email")
}

Okta Javascript Library

Hopefully, Okta’s authentication javascript library is stable now, but be aware that the API can change a lot between versions. The blogs also can be using older versions of the API. You can find the latest here:

okta/okta-react

My project was done using the 5.0.x version of the API and it has gone to version 6.0 within the past 6 months, so that gives you an idea of how rapidly it changes.

Using it is fairly simple. Your Router has to be wrapped for it to handle authentication checking routes and you have to add a route to handle the login callback. Routes that require an authenticated user has to use the SecureRoute tag:

const oktaAuthConfig = new OktaAuth(config.oidc);

const App = () => {
    const restoreOriginalUri = async (_oktaAuth, originalUri) => {
        window.location.href = toRelativeUrl(originalUri, window.location.origin)
    };

    return (
        <Router>
            <Security oktaAuth={oktaAuthConfig} restoreOriginalUri={restoreOriginalUri}>
                <Container text style={{marginTop: 'none'}}>
...
<Switch>
    <Route path={config.oidc.callbackPath} component={LoginCallback}/>
    <Route
        path='/'
        exact
        render={props =>
            <RepoList {...props} mineOnly={false}/>}
    />
    <SecureRoute
        path='/web/edit/:id'
        render={props =>
            <Edit {...props} />}
    />
</Switch>
/>

You can then have a navigation bar component wrapped with withOktaAuth that checks for a logged in user and put up Login/Logout buttons as appropriate:

export default withOktaAuth(class NavigationBar extends Component {

    constructor(props) {
        super(props);
        this.state = {isOpen: false};
        this.toggle = this.toggle.bind(this);
        this.login = this.login.bind(this);
        this.logout = this.logout.bind(this);
    }

    async login() {
        await this.props.oktaAuth.signInWithRedirect();
    }

    async logout() {
        await this.props.oktaAuth.signOut();
    }

    toggle() {
        this.setState({
            isOpen: !this.state.isOpen
        });
    }

    render() {
        if ( this.props.authState.isPending ) {
            return (
                <div>Loading authentication...</div>
            );
        } else
        return <Navbar color="light" light expand="md">
            <NavbarBrand>App Directory</NavbarBrand>
            <NavbarToggler onClick={this.toggle}/>
            <Collapse isOpen={this.state.isOpen} navbar>
                <Nav className="ml-auto" navbar>

                    {!this.props.authState.isAuthenticated ?
                        <NavItem>
                            <Button color="secondary" outline onClick={this.login}>Login</Button>
                        </NavItem> :
                        <NavItem>
                            <Button color="secondary" outline onClick={this.logout}>Logout</Button>
                        </NavItem>
                    }

                </Nav>
            </Collapse>
        </Navbar>;
    }
});

Packaging React.js Web App with Spring Boot JAR

Typically, a microservice is packaged up as a single JAR file that is run in a container via a java command line. However, this isn’t as simple as it sounds because the files are not served from a static directory, but as resources in the JAR file.

This is done using the maven resources plugin via a pom.xml config:

<plugin>
   <artifactId>maven-resources-plugin</artifactId>
   <version>3.2.0</version>
   <executions>
      <execution>
         <id>position-react-build</id>
         <goals>
            <goal>copy-resources</goal>
         </goals>
         <phase>prepare-package</phase>
         <configuration>
            <outputDirectory>${project.build.outputDirectory}/static</outputDirectory>
            <resources>
               <resource>
                  <directory>${frontend-src-dir}/../build</directory>
                  <filtering>false</filtering>
               </resource>
            </resources>
         </configuration>
      </execution>
   </executions>
</plugin>

The front-end-src dir is defined at the top of the pom.xml file like so if you created your React.js app in the webclient directory:

<frontend-src-dir>webclient/src</frontend-src-dir>

The pulls all the files in webclient/build directory into your microservice’s JAR file.

Yarn Bundling and Private Artifactory

The webclient is built using the frontend-maven-plugin which is configured like this:

<plugin>
   <groupId>com.github.eirslett</groupId>
   <artifactId>frontend-maven-plugin</artifactId>
   <version>${frontend-maven-plugin.version}</version>

   <configuration>
      <nodeVersion>${node.version}</nodeVersion>
      <yarnVersion>${yarn.version}</yarnVersion>
      <workingDirectory>${frontend-src-dir}</workingDirectory>
      <installDirectory>${project.build.directory}</installDirectory>
   </configuration>

   <executions>
      <execution>
         <id>install-frontend-tools</id>
         <goals>
            <goal>install-node-and-yarn</goal>
         </goals>
      </execution>

      <execution>
         <id>yarn-rpm-registry</id>
         <goals>
            <goal>yarn</goal>
         </goals>
         <configuration>
            <arguments>config set registry ${npm.registry}</arguments>
         </configuration>
      </execution>

      <execution>
         <id>yarn-install</id>
         <goals>
            <goal>yarn</goal>
         </goals>
         <configuration>
            <arguments>install</arguments>
            <yarnInheritsProxyConfigFromMaven>false</yarnInheritsProxyConfigFromMaven>
         </configuration>
      </execution>

      <execution>
         <id>build-frontend</id>
         <goals>
            <goal>yarn</goal>
         </goals>
         <phase>prepare-package</phase>
         <configuration>
            <arguments>build</arguments>
            <yarnInheritsProxyConfigFromMaven>false</yarnInheritsProxyConfigFromMaven>
         </configuration>
      </execution>
   </executions>
</plugin>

We mirror our NPM artifacts as well as Node.js versions in our artifactory and that’s what the “config set registry” takes care of.

Also be sure to set this on your local machine because Yarn’s package.json includes hardcoded URLs to the NPM artifacts. If you don’t reference them from your artifactory, they’ll use the public npmjs artifactory which may not be accessible from your CI pipeline.

Conclusion

I hope that gives you enough tips to get around speed bumps you might encounter getting JWT logins to work with Spring Boot and an SPA app. I sure wish I had seen these tips while working on my project :-)

p.s. this was the first production Kotlin microservice at our company and I’m happy to report I didn’t encounter any issues writing it in Kotlin. Big thanks to Sébastien Deleuze’s hard work for helping make it so seamless.

References

• https://developer.okta.com/blog/2019/04/15/testing-spring-security-oauth-with-junit

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

Then you can install a bunch of useful stuff with choco:

choco install gradle
choco install graalvm
choco install cloc
choco install putty
choco install autohotkey

cloc is a useful tool for counting the lines of code in your codebase.

AutoHotkey is a useful tool for mapping specific Alt key combos to Ctrl key combos because it involves less contorting of your thumb (the Mac layout swaps the ctrl-alt keys which is more comfortable). You normally just need a subset of keys mapped instead of actually swapping the ctrl/alt keys though. This example is for mapping the usual editing keys as well as adding home/end/pageup/pagedown to laptop keyboards that are missing those keys (e.g. the Asus Zephyrus G14). Place this file in C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\fixkeys.ahk:

#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
; #Warn ; Enable warnings to assist with detecting common errors.
SendMode Input ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory.
Control & Left::Send {Home}
Control & Right::Send {End}
Control & Up::Send {PgUp}
Control & Down::Send {PgDn}
;stack keys with the same modifiers
; Saving
!s::
; Selecting all
!a::
; Copying
!c::
; Pasting
!v::
; Cutting
!x::
; Opening
!o::
; Finding
!f::
; Undo
!z::
; Redo
!y::
; New tab
!t::
 ; close tab
!w::
; Jump to definition in IntelliJ
!b::
 ; add bookmark
!d::send % "^{" substr(a_thishotkey, 2) "}"

Another neat feature in Windows 10 is the Task Scheduler. You can do cool stuff like detect when your laptop goes into battery mode and run a script. On gaming laptops, it’s useful to do this to turn off the discrete GPU to maximize battery life. This is an example task (put it into a file with a .xml extension) that can be imported into Task Scheduler:

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
      <Triggers>
        <EventTrigger>
          <Enabled>true</Enabled>
          <Subscription>&lt;QueryList&gt;&lt;Query Id="0" Path="System"&gt;&lt;Select Path="System"&gt;*[System[Provider[@Name='Microsoft-Windows-Kernel-Power'] and EventID=105]]&lt;/Select&gt;&lt;/Query&gt;&lt;/QueryList&gt;</Subscription>
        </EventTrigger>
      </Triggers>
      <Settings>
        <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
        <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
        <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
        <AllowHardTerminate>true</AllowHardTerminate>
        <StartWhenAvailable>true</StartWhenAvailable>
        <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
        <IdleSettings>
          <StopOnIdleEnd>false</StopOnIdleEnd>
          <RestartOnIdle>false</RestartOnIdle>
        </IdleSettings>
        <AllowStartOnDemand>true</AllowStartOnDemand>
        <Enabled>true</Enabled>
        <Hidden>false</Hidden>
        <RunOnlyIfIdle>false</RunOnlyIfIdle>
        <WakeToRun>false</WakeToRun>
        <ExecutionTimeLimit>PT1H</ExecutionTimeLimit>
        <Priority>7</Priority>
      </Settings>
      <Actions Context="Author">
        <Exec>
          <Command>Powershell.exe</Command>
          <Arguments>-ExecutionPolicy Bypass C:\Users\me\UseIGP.ps1 -RunType $true -Path C:\Users\kenky\</Arguments>
          <WorkingDirectory>C:\Users\kenky</WorkingDirectory>
        </Exec>
      </Actions>
</Task>

And put this script in your C:\Users\me\UseIGP.ps1 file if you have a Zephyrus G14:

## run this script when going off A/C power

## kill nVidia processes 3X to make sure they don't resurrect
Get-Process | Where-Object {$_.Path -like "*NVIDIA*"} | Stop-Process -Force
Get-Process | Where-Object {$_.Path -like "*NVIDIA*"} | Stop-Process -Force
Get-Process | Where-Object {$_.Path -like "*NVIDIA*"} | Stop-Process -Force

## kill off Epic games launcher
Get-Process | Where-Object {$_.Path -like "*Epic Games*"} | Stop-Process -Force

## kill off Steam games launcher
Get-Process | Where-Object {$_.Path -like "*Steam*"} | Stop-Process -Force

## this disables the dGPU...
Disable-PnpDevice -InstanceId (Get-PnpDevice -FriendlyName *2060* -Status OK).InstanceId -Confirm:$false
Enable-PnpDevice -InstanceId (Get-PnpDevice -FriendlyName *2060* ).InstanceId -Confirm:$false

sealed class Option<out A> {
    object None : Option<Nothing>()
    data class Value<out A>(val value: A) : Option<A>()

    companion object {
        fun <A>from(value: A?): Option<out A> {
            return value?.let { Value(value) } ?: None
        }
    }
}

Usage is pretty simple…just do Option.from<YourClass> on any value that may be nullable. Then you can use this to pass through a reactive stream since you can’t pass nulls through; on the other wise, unwrap it with:

when (it) {
     is Value ->
           val value = it.value
     is None ->
           // handle error
}

It’s the end of another year and a time to reflect on the meaning of life (also known as annual reviews). This is my third company that has had 360 Degree Reviews and writing a self review always has meant a deeper self reflection/introspective that I usually don’t have time to do during the course of the year.

When I left KAYAK earlier this year, I wrote a farewell/thanks memo and unusually signed off with a few nicknames that I was surprised no one asked about before I left (though the team lead did hilariously ask whether I misspelled the CEO’s name deliberately which I guess management believed because my farewell lunch was at the mall food court :-)

Little did I know, these nicknames were attributes that Wayfair quantified and documented as things that are expected of their architects. The nickname a.k.a. list included:

“I Bleed So My Team Doesn’t Have To”

For taking care of issues while the teammates relax (e.g, fixing a crash spike in code I didn’t write during Thanksgiving).

For testing all the alphas/betas of tools before they need to use them including Android Studio, Gradle, and Kotlin (and setting up ktLint/Detekt to keep help them transition from Java).

For helping fix CI/CD issues so the team can operate smoothly.

“Iceberg Navigator”

• For trying to steer everyone towards the future without hitting icebergs on the way.
• For pushing hard to get Kotlin into the app (and server-side but they steadfastly refused to use Kotlin even though over the next year, Spring added huge amounts of support for it thanks to Sebastian Deleuze) before and after Google approved it.
• For steering the use of Android Arch Components as our official architecture from a mix of BBOM (Big Ball of Mud) and an acquisition’s MVP architecture.
• For trying to add UI integration testing two years before it was asked for by management.
• For working on early features like App Slices before management asks because it looked important to the business.
• For warning our team and legal about GDPR in June 2018 because other app devs were freaking out over it, but we weren’t told to implement it until Jan 2019 when a privacy story blew up.

“Google Liason”

• For working with Google on various Early Access Programs like Google Pay and Firebase performance and helping improve their UX and APIs.
• For working with the Crashlytics/Beta folks on testing their migration tools to Firebase and helping improve their UX via various focus group sessions.
• For pre-alpha testing various Android libraries including the Arch Nav Components and Arch ViewModel SavedState to see whether they should be used in our architecture.
• Filed bug reports with Google and provided repro code.

“Bridge Builder”

• For working with the API team by helping test their early checkout APIs and reviewing code and identifying APIs that could be improved.
• For working with the iOS/mWeb teams by comparing API usage with them and warning them when finding idiosyncrasies.
• For bridging the Android developers in Berlin by getting up early to help with anything they needed before my Cambridge coworkers were awake.
• For building bridges to the acquired Momondo Copenhagen Android team to acclimate them to our development culture.
• For bridging the UX team by helping them understand what is needed for Android Vector Drawables, Android Material Theming, and Tablet Layouts; and by attending an After Effects course with them to improve their understanding of Lottie.
• For bridging w/ the Data Science team in a great in-house data science course to see whether we can apply ML to predictions in-app by looking at device usage to see when people would like to travel. It didn’t hurt that our mentor from the DS team was an avid Kaggler…we ended up winning the competition at the end thanks to Remi ;-)

“App Janitor”

• Because being an architect, tech lead, team lead is not always a glamorous job.
• For cleaning up 3000+ lint warning despite management saying “no one looks at them so why bother”.
• For updating all the libraries that were years up to date and doing multiple 300–2300 file PRs to bring the app up to date.
• For bringing our crash rate from 96% to 99.96%.
• For providing a better way to help solve crashes than just looking at stack traces.

This can be summarized into these simple guiding principles that I’ve always lived my life by:

• Always help others become better because it makes you better: mentor, do code reviews, help out in “not your expertise” areas, write wikis, write blogs, do presentations, help at local meetups and conferences.
• Never stop learning because you never know everything and the more you learn, the better you can see; share what you learn (see the previous point) because it makes people around you better.
• Be a good role model so people can respect you and follow your lead; always be professional, courteous and friendly and call out things that are illegal or morally questionable.

These are all attributes anyone with these titles above should have and should cultivate…they’re definitely ones I’ve tried to improve and live by through my career.

Hope everyone has a great New Year!

p.s. yes it was a typo…one ‘f’ not two. I’d blame it on the crappy Mac butterfly keyboard but I didn’t have one at the time :-)

Here are a few tips after migrating a few projects to AndroidX:

Use the MigrateToAndroidX Refactor only on build.gradle files

The built-in Android Studio Refactor/MigrateToAndroidX tool is a memory hog and adds AndroidX package prefixes to your code instead of only renaming the import lines. E.g., you’ll see stuff like this:

androidx.recyclerview.widget.RecyclerView cartList = findViewById<androidx.recyclerview.widget.RecyclerView>(R.id.recycler)

This is hard to find in the initial big commit (for one of the projects I converted, it was 2300 files); it will also do this for other random classes like the ViewPager and FragmentManager. The best thing to do is use the tool to update your build.gradle files which it does well with, then revert the rest of the changes and use a renaming script (see below).

The Refactor/MigrateToAndroidX tool also has memory issues if you have a large project because they tried to speed it up from the slowish version in Android Studio 3.3; if you can’t increase the heap space in Android Studio 3.4/3.5, try the previous version. Or you can just change your build.gradle by hand and run the renaming script below instead.

Be sure to check all your build.gradle files afterwards. If you use a nice clean .ext block in your top level build.gradle to version everything, you’ll find that the migration tool hardcoded all the library versions in all of your modules to this :-(

kapt "androidx.room:room-compiler:2.0.0"

Get/Use a package renaming script

As mentioned above, the built-in refactor tool has issues in getting a little overzealous in prepending package paths (probably because it leans on the Android Studio renaming refactor framework). In most cases, you’ll be doing the AndroidX migration in a branch and every time you merge master/dev into your branch, you’ll have to run the package renaming script before you can rebuild if someone has added any references to non-AndroidX classes.

WrongConstant Lint Check Broken

The WrongConstant AndroidX lint check is plain broken once you finish the migration. You should add a

<issue id=”WrongConstant” severity=”ignore” />

line in your app’s lint.xml. Star this issue to see when it gets fixed: https://issuetracker.google.com/issues/119753493

Jetifier Partially Jets

Some libraries that are nested don’t seem to get Jetified (converted to AndroidX) automatically. One example is the uiautomator library which was indirectly referenced by fastlane as well as included in our build.gradle: https://issuetracker.google.com/issues/123060356

The fix is fairly simple…exclude the artifact out of the other library:

androidTestImplementation (‘tools.fastlane:screengrab:1.2.0’) {
// https://issuetracker.google.com/issues/123060356
exclude group: ‘com.android.support.test.uiautomator’, module: ‘uiautomator-v18’
}

InstrumentationRegistry Application References

The way you get the reference to your custom application class is different. Instead of using getTargetContext() (which is the test application) in a test, you have to do:

InstrumentationRegistry.getInstrumentation().targetContext.applicationContext as TestApplication

References

Thanks to Dan Lew’s original article on this process: https://blog.danlew.net/2018/11/14/the-reality-of-migrating-to-androidx/

And AndiMiko for writing a Python version of Dan’s script, which I’ve hardened a bit and added a few more flags for testing to: