DEV Community: Tim Jung 👽

New Year, New Goals! Share your 2020 wins & 2021 goals!

Tim Jung 👽 — Mon, 28 Dec 2020 21:15:28 +0000

As 2020 comes to a close, a new year of opportunity and victories lies ahead. Many of you are already thinking about what achievements you'd like to unlock in the new year. But don't forgot to also reflect upon and celebrate everything you've done in this past year.

Please share:

Wins you're proud of from 2020! Big or small!
Goals you want to accomplish in 2021

I'll post mine in the comments below. 👽✌️

A Speed Run Intro to React Native for Front End Developers

Tim Jung 👽 — Mon, 06 Apr 2020 20:29:06 +0000

If you're already familiar with JavaScript, front end development, or React then this speed run intro will get you using React Native code quickly. It's not a full blown tutorial, it won't equip you with everything, but it will get your feet wet and hopefully be the beginnings of you getting into React Native. We'll skip all the cruft and hurdles of setup. We'll cover the basics and get you right into real code as quickly as possible.

What is React Native?

React Native is a way to use JavaScript to build mobile apps for Android and iOS. This means it's cross-platform. It's name highlights it's two important qualities:

1. React

React Native leverages the existing React library. That means you get to apply all the same concepts from React you're used to like components and props.

2. Native

React Native is rendered in truly native code. You might be thinking - "What? How does that work? I thought for mobile apps to be native they need to be written in languages like Kotlin and Swift?" Luckily, React Native is built to use the native APIs of Android and iOS by having your JavaScript communicate with them. This is all done over something known as the "bridge". You can do pretty much all the complicated stuff, maintain most of the performance, and avoid rendering your code in a bunch of WebViews like some other solutions.

Why should I use React Native?

You might poke around online and see a lot of people grumpily dismissing React Native. Or other holy crusaders may say other solutions such as Flutter are the right path. Both sides of this spectrum might be right... in specific contexts. See - I think that good developers pick the right sword for the right task. You wouldn't bring a butter knife to an epic medieval battle. And similarly you wouldn't bring a two-handed claymore to a dinner party. I mean you could - but it's not going to go over well.

That's why you have to understand what advantages React Native offers and make a smart assessment if it makes sense for you.

So what are some of the important pros and cons to consider?

Pros

It's JavaScript and React - If you don't know anything about writing mobile applications in languages like Kotlin or Swift, and you already know JavaScript or React, then the quickest path to shipping a mobile application for you is to use what you already know by building with React Native. And because JavaScript is so popular, we can draw on it's existing community and support.
It's cross platform - Once upon a time I worked at a company that built an app that had a codebase for the Android version and a codebase for the iOS version. This meant two different teams were building the same features, but in different languages. A lot of the time it meant less knowledge share, and one codebase would often lag behind the other holding up releases. React Native let's you keep all your app developers on the same page while building for both Android and iOS at the same time.
It's well supported - Never underestimate the importance of good support. Facebook and a robust community of open source developers work hard to deliver features, squash bugs, and keep the lights on for React Native. It's why big companies can trust it. And why developers know they can use the React Native docs and their Google-fu to get to the bottom of most any problem.

Cons

Performance - I would wager that in the overwhelming majority of cases React Native has performance that you can rely on and trust. But in some instances that's not the case. If you're doing some crazy computationally intensive calculations like 3D animations then maybe React Native isn't the right fit.
Native code - Sometimes you still just have to get your hands dirty and write native code as a part of your project. Things like push notifications and using the camera aren't always well supported in React Native. This means you'll have to use languages like Kotlin or Swift to get the job done sometimes.

How do I get up and running?

"Okay Tim shut up! I'm reading this article because I'm already interested and you don't need to sell me any further." Got it! Let's get back on track and focus on getting you making stuff with React Native.

Normally we would have to go through a complicated environment install and configuration process. What a pain! That's just going to get in the way of helping you write your first React Native code. So I'll toss some resources toward the end of the article about how to do that. And instead we'll focus on Expo.

Expo

The smart people over at Expo have made it incredibly easy for us to start writing React Native right now in our browser.

Wait what's Expo and why should you trust it? Basically it's a set of tools to help you build React Native. I'll link you more about them later. They're used the official React Native docs too.

Lets start messing around with React Native!

The link above takes us to an Expo snack - basically a boilerplate sandbox - where we can start looking at React Native code and altering it. After opening the link you'll want to observe the project directory on the left hand column. This shows us the basic project structure of our React Native project

We have:

The root Project folder.
The assets folder where things like png images can live.
The components folder where the building blocks of our project live.
App.js is the main "brain file" of your React Native app - it's where we're going to focus on so go ahead and click on it and have it open.
package.json holds your dependencies (for our purposes we can ignore this).

Diving into the code

Now that you're looking inside of the App.js file take a look at the code. We have some imports for things we need at the top such as React, some components known as Text, View, and a Stylesheet. We have a components being imported called AssetExample and Card. We have our default function App. Inside of App we use our components we just mentioned. And below all this we have our styles which all come from a StyleSheet.

Let's break down what these mean and how it might differ from what you're used to if you're familiar with React.

Our App() function is the main brain that represents our App. Everything lives inside of it.
React Native doesn't have the same elements used in web development like <Div> and <Span>. Instead we use Core Components. These are things like <Text> and <Image>. Earlier we talked about how React Native is truly native and communicates with the native APIs of either Android or iOS. These core components handle those communications so either platform can display the correct native API despite whatever differences they have on either platform.
We don't have to just use Core Components. We can also build and use our own. In this example we see AssetExample is being used. It's imported from './components/AssetExample'.
Last we have our styles. We don't use CSS in React Native. Instead we use JSX. Getting started, you won't have to worry about specifying pixels anymore for things like padding. React Native is smart and helps us with sizing across different devices. Your styling could look a tad bit different on different devices depending on each devices pixel density.

That's really the core stuff you need to know about the project. Let's try updating it with a new React Native component - the <FlatList> and some styling changes.

Using a `<FlatList>`

A <FlatList> is a bit of a more complicated Core Component. It displays a list of items based on a data set you feed into it. We're going to display a few of my favorite foods using a <FlatList>. First off, we'll throw in a data variable called favoriteFoods - which is an array of objects that have an id and a title.

Next, the we need to make the component that represents the individual items that the <FlatList> will display. We'll call it FoodItem. Inside of it is a <View> with a nested <Text> component. We can see that the <Text> will display the "title" passed into it by the <FlatList>.

We can then add the actual <FlatList> inside of our App now. Let's drop it below our <Card> component. The <FlatList> take in a parameter for data (our variable favoriteFoods), a renderItem (which takes an item from our favoriteFoods to render into the list), and a keyExtractor (this is just a necessary piece we should include).

We will then throw in some styling for item and title so that everything looks very pretty.

Here's the final product

That's really it. You've now been messing around with React Native. Pretty simple to get going, right? I'm proud of you.

Where to go from here

So now what? Well you should keep writing more React Native code. Try to ship something. Keep the scope really small and don't go feature crazy. You can do that for the second thing you ship. Don't fall for a million tutorial traps either. You should spend more time writing code, googling around, and reading actual documentation.

Seriously reading the documentation is great. The people who made it are way smarter than me. This post was just to get your feet wet and show you this is something you can definitely do. So here's all the resources - including the ones I mentioned earlier that I would link later in the article. Take the time to read them and they will open up your eyes to the different tools React Native makes available to you.

Resources

The docs are your new best friend.
React Native Docs - Getting Started
You should use Expo for experimentation and quick building.
Get Started with Expo
The React Native CLI is more advanced but at some point you'll have to tackle it instead of just using expo for new projects.
React Native Docs - Setting up the development environment
You can also use an opinionated CLI like Ignite which helps with boilerplate and getting your project setup.
Ignite Repo with instructions

My 2019 Year In Review: Working on the Call of Duty Companion App

Tim Jung 👽 — Sat, 04 Jan 2020 19:25:42 +0000

Hello. I'm Tim Jung and I work on the Call of Duty Companion App at Activision Blizzard. The quick rundown of the app is that it's a way for our players to stay connected to the franchise, earn rewards, and interact in cool ways with the games. It's written using React Native, JavaScript, Redux, & React Navigation.

This post is a look back on things I built or worked on - especially things that I had ownership over - during 2019. It's not comprehensive but it's some of the things I'm really proud to have shipped. I'm mostly writing this for myself as a way to remember 2019 (my first full year in the games industry) but perhaps you'll get some enjoyment out of reading it too.

A quick note: Shout out to my amazing team. I couldn't have done all of this without your guys hard work, contributions, help, code reviews, good attitudes, willingness to grow, & commitment to helping others learn. We've all collaborated, teamed up, touched each others code, looked out for each other, and contributed to this project in ways that can't be quantified. Super lucky to work with you all. What we do is truly a team effort.

THE LOADOUT EDITOR

I joined the team in November of 2018 and immediately I thought it would be a good idea to take on the hardest, most complex feature I could convince everyone to trust me with. On some level I felt like I needed to prove myself and on another level it seemed like a lot of fun. This feature was the in app Loadout Editor (also called Create A Class) for Call of Duty: Black Ops 4 (BO4).

In BO4, players have the ability to maintain and customize a number of classes (aka loadouts). This means that a player can have multiple setups with their favorite combinations of things such as guns, gun attachments, gear, equipment, perks, and wildcards.

The idea was to bring this functionality into the Companion App. Players would be able to access their personal inventory of loadout options, select new combinations, and then press save - which would update their loadout in Black Ops 4.

This was hands down the most elaborate feature I've ever built in my career. The BO4 loadout editor actually has a lot of rules that needed to be accounted for. Here's a few so you can get an idea of what needed to be coded for:

Players may have loadout options unlocked and available to use based on in game level or store purchases. Weapons have different sets of attachments that can be added to them. Some of these attachments required a different attachment be equipped already for it to be equipable. Some attachments can't be equipped at the same time as others. Players have a limit of 10 points they can spend on a loadout and each equipable item has an associated point cost. Some items cost 2 points to equip. Some items from the "equipment" category had the option to equip a second of the same item once the first was equipped. A user can equip perks (these are special class power ups). They had three categories: perk 1 (blue), a perk 2 (green), and perk 3 (red). Each color of perk category had multiple perks to select one from.

Then there's wildcards which make this all even more complex. Wildcards modify the rule set of how a loadout works. One wildcard lets the player equip two primary weapons or two secondary weapons (so long as that weapon isn't already equipped). One unlocks a new kind of attachment called an operator mod for some weapons. Some wildcards unlocked additional attachment slots for weapons. Gluttony wildcards allow a user to use all three perk slots to select perks from a specific color of perk category. Greed wildcards would allow a player to unlock a second color of a perk category.

Because a user could perform the action of equipping something when they were at the 10 point maximum I also needed to display a screen that warned them of this and gave them options for what items to remove so they weren't exceeding the 10 point limit - called the max 10 screen. This screen also needed logic to make sure things made sense to the user. For example, selecting to remove a wildcard that allowed two primary weapons to be equipped also needed to indicate that any second primary weapon a user may have equipped would also be removed as a consequence of removing the wildcard. These rules cascade into a large number of situation I need to account for in the code, UX, and UI.

Ultimately there's a fair amount of state and a large amount of checks that happen when a potentially state changing action is initiated by a user. I had to be especially thorough with checking and testing all of the actions a user could take (and there were a lot of them) so that they never experienced a situation where a loadout was in an invalid configuration.

This feature was especially fun and challenging for me. In a way it's the closest I've ever been to real game development. In a way I like to think it is real game development. It required me to reverse engineer BO4's in game loadout editor, build a mobile experience of the feature, coordinate with Treyarch, and because it updates players loadouts in the game. It's one of our most used features in the app.

VERSION 2.0

After the Loadout editor released, I started focusing with the team on the 2.0 version of the app which was set to launch alongside the release of Modern Warfare later in the year. So much went into this effort that to me it feels insane that we successfully executed on it. Going into depth on everything that went into the 2.0 release probably deserves its own blog post. But I will try to summarize the key objectives. Essentially, the majority of the app was rewritten.

The 2.0 release consisted of revamping existing features (e.g. the entire Ops section), building new features (e.g. the new Social section), refreshing the design, UI, and UX experience of the entire app, upgrading from React Native 55 to 59, moving from React Native Navigation to React Navigation, rewriting class components to be functional components and using React hooks, more thorough analytics, a rethinking of our file organization and component practices, thorough and proper usage of Redux throughout the app, and meticulous identification and remedying of performance issues (thanks React.memo!).

This was very much an all hands effort and it's especially hard to attribute specific parts of this to individuals on the team. We really united over these goals, shared ideas about performance and best practices, learned a lot, and executed on making the entire codebase something wildly less spaghetti. Ultimately, we ended up with an app that was about half the size of the previous app, had a robust set of components that could be used to rapidly develop new screens and features in the future, significantly faster performance which was especially noticeable on older or less powerful devices that would otherwise crawl or crash previously, smart usage of Redux that tamed the large amount of data we make requests for and use throughout the app, and a navigation system that was a better fit for our project.

OPS REFRESH

Another feature I worked on was doing a complete revamp of our Ops section of the app. In the original version of the app - players were placed into "Squads". They could then vote for an objective to pursue for the week (e.g. "Your squad must get 300 headshots this week") and earn a reward. Unfortunately the feature wasn't particularly engaging so we set out to revamp that entire section of the app with a new experience.

The refreshed Ops section still does stuff like placing users in a Squad, letting users create, join, report, and search for Squads. But now the UI and UX had been revamped which required a rewrite. Instead of the old voting mechanic we moved to a more competitive Weekly Tournament. This system places squads of similar skill level into a tournament each week. The squads then compete to be in the top 3 by completing the weekly objective. Being in 1st provides a better reward than being in 2nd or being in 3rd. At the end of a tournament, rewards are determined on the backend, players will then receive an in app notification detailing their reward on their next app open.

Digging into the technical a little more, one of my favorite pieces was building the ranking board for the Weekly Tournament screen. I was able to build it as an agnostic component. This means that I was able to use it in our Leaderboard screen as well. I refactored out the old ranking board in the Leaderboard which helped decouple code for that feature. Now this ranking board component can be used in future features as well. The Ops revamp allowed me to really explore building a feature that has a lot of reused components throughout it.

PUSH NOTIFICATIONS & THE MODERN WARFARE TEASE

I also have built a lot of functionality related to how push notifications are received by the app. I got to work on implementing things like rich push - which is when a notification also shows an image, or in the case of iOS, a gif or video too. One of the coolest thing I built was the custom push notification sound for the Modern Warfare reveal tease.

Android and iOS actually make it available for apps to choose a custom sound to play when an app receives a push notification. Leading up to the announcement of Modern Warfare, we wanted to put a custom push sound into the app to get players excited and talking about what the next Call of Duty could be. The sound happened to be the iconic night vision noise that players associate with the original Modern Warfare series. All the push notification itself said was the reveal date "MAY 30. 10:00 PT.".

The night vision noise is actually an mp3 file that exists in the app itself. We can specify a data field in the notification payload that is then checked for when a notification is received to determine if the custom sound or the users default notification sound should be used. When I originally received the sound file it was named something like "mw_nightvision.mp3". I had the forethought to rename it to the less revealing "push_sound_new.mp3". Later on, I was shown a Reddit thread where the file was data mined but luckily my renaming saved us from making the Modern Warfare reveal more obvious than what we wanted.

CONCLUSION

Like I said at the beginning of this blog post, this list isn't comprehensive. I worked on so many different things this year.

Some other stuff I did: Revamped our Social section including building the feed cards and pinning functionality, worked on the Leaderboard screen and settings, created widgets that appear on the Home screen such as the Ops widget, countless bug fixes that touch nearly every part of the app (especially fond of fixing ones that players report to our Support team), built reusable components, sifted through code reviews, helped teach other developers about the app and how to work with React Native, candidate interviews, going back and forth with UI and UX to make the best user experiences possible, championed adding in our new weekly rewards feature, begrudgingly checked that everything looks good using the iPhone 5s emulator with its accursed tiny screen size, drank too much coffee, collected free Activision swag, lost 25 pounds of fat and then added on 25 pounds of (mostly) muscle, played Blackout in BO4 with my coworkers, and had lots of team lunches at Fast Taco.

When I joined the Call of Duty Companion App team we had about a 2.0 star rating on both the App store and the Play store. Over this last year we all worked super hard and today the app rating is at a 4.1 on Android and a 4.8 on iOS. It's such a huge achievement for us and I'm super excited about what's next for the app. I'm working on some really cool things right now.

It's been awesome an awesome 2019. It was my first full year in the games industry. I'm the busiest I've ever been but I'm loving every minute of it. I wanted to work in the games industry my entire life and now that I get to build things that millions of players use I couldn't be more fulfilled and inspired.

How I Tricked My Team Into Writing More Documentation

Tim Jung 👽 — Mon, 29 Jul 2019 08:16:13 +0000

Documentation is one of those things that every developer will praise in a conversation while probably not doing enough of it, if any. We’ve all heard a million reasons why documentation is good. It helps with knowledge transfer so everyone is on the same page. It saves the new guy from being totally lost in the woods and needing to pester all the other developers to braindump their knowledge through audible conversation. It saves your future self from cursing your past self. Documentation is the holy text that keeps teams lubricated and spinning.

But even though we all largely agree about the benefits of documentation, few teams actually devote meaningful time to doing it. It falls to the wayside. There’s so much actual code to write, so many fires to extinguish, so many deadlines to miss. So how do you get your team to invest in writing more documentation? You trick them.

My Team

I’m a developer at Activision Blizzard on the Call of Duty Companion App. We’re a pretty small and tight knit team. I believe I’ve figured out a way to get my team to write a lot of documentation. And I believe that these tips on how I did it can be applied to any team. A few months ago we were investing almost no time into documenting things. Now we spend a lot of time documenting things.

But before I explain how we got to that point, here is the most important thing not to do. Don’t boss people around. I have never been a believer in telling your peers what to do. Real change happens on a more authentic and organic level. So it is important to understand that statements like “you should write more documentation” definitely won’t work. Behavior doesn’t change at a wand wave. Your fellow developers plates are already full with Thanksgiving sized heaps of other tasks and responsibilities so we need a better solution than making demands.

Phase 1: Doing It

So how did I actually get my team onto the documentation bandwagon and pumping out tons of legitimately useful docs? It’s simple. I started writing documentation.

You have to be the first person to step up and write great documentation. Once you do you now have a team writing documentation. Even if it’s just one person so far. You should be writing documentation as you go too. It needs to be a part of your routine anytime you fix something, setup a new process, build a new feature, or whatever else may be worthy of being documented.

Okay, but now you’re thinking “how do you get the rest of the team to write documentation? Isn’t that what this is all about?” Here are the next steps you need to trick everyone else into doing it too.

Phase 2: Broadcasting That You’re Doing It

Congratulations. Now you’re actually writing documentation. And you’re doing it every time it makes sense to. This is a critical foundation for tricking everyone else into doing it. Now you need to start broadcasting that you are writing documentation.

Anytime you write a new wiki article or document something you need to gently let everyone know. Note the word “gently”. Remember the goals of good docs are team cohesion and improved output. So your words should reflect this. “I just wrote this wiki page for feature X that I just built. It tells you everything you need to know to start using it too. Please let me know if you think I missed anything.”

You’ve now broadcasting that you are writing documentation and planted the seed that this is something your peers can do too. They are going to see the value in writing documentation because they are going to pop open your wiki page for feature X and quickly get up to speed about what feature X does. You have empowered them. And if there is four people on the team then you have empowered all four of them.

Phase 3: Let Others Know When It Would Be Useful To Do It

Now that you’ve started to broadcast that you write documentation, you can look for opportunities to suggest that they write documentation. Did another team member just finish building feature Y? Or did they invent a new plan for building the Xcode project that doesn’t cause that weird bug? Did they do anything at all that made you think, “wow I have zero idea how to do that and it would be really useful if the team and I knew how to do it too”? These are the moments you can gently suggest they write some docs. “Hey, that new feature is super useful! Would you be willing to take some time and write something up about it please?”

Most likely the first several times you suggest documenting they won’t do it. That’s normal and okay. There’s no need to pester. In fact, pestering or reiterating you want something specific documented just feels like you are trying to put food on their already full plate. But stay consistent. Anytime something worthy of documentation appears just continue using the strategy of letting them know how helpful it would be if they documented it. If they do document something then make sure to express appreciation.

Phase 4: Reminding Others That You Did It

Here’s where I think the most powerful convincing happens. This is the thing that will actually get your team members to write documentation too. Make sure to refer to your documentation as often as possible. If someone asks you, “how do I do X again?”, then you should be able to point them toward documentation about it. If you are staying resolute about writing documentation as you go then these opportunities will definitely pop up. Don’t be a jerk about it though. First you should actually address their question as if the documentation didn't exist. Just linking them to a doc might come off as rude or passive aggressive. Help your peer and afterward politely mention something like, “hey by the way, here’s where to find this information in our documentation in case you need it later.”

The Results

So maybe all of this isn’t necessarily trickery but that’s more fun to say than “setting a good example that politely demonstrates the value of good documentation”. If you keep up these four strategies (write docs consistently, broadcast when you do, suggest when others could write docs, and refer to existing docs when possible) then I know you will eventually get traction and the rest of your team will start writing more documentation. It will start as a trickle and domino into an avalanche

On the Call of Duty Companion App team, it started with me documenting simple things like our style guide or information about our push notification capabilities. I stuck to my method and then one day my team lead created a gif on how to configure settings in Xcode with some written instructions in an internal wiki article. The trickle had begun. After that another developer started documenting components with screenshots and breakdowns of how to use them throughout our app. Now we’re all writing documentation regularly. Our documentation is helping us all be on the same page. We are seeing it speed up our development process. And now any time we have a brain 404 where we don’t remember how to do something, we aren’t bumbling through the woods again wasting time re-figuring it out. It’s all there in our documentation.

If you're looking to achieve similar results, all you need to do is trick a few people.