Forem: Matthew Groves

Matt's Tidbits #103 - Launching an app from a URL

Matthew Groves — Tue, 02 Nov 2021 15:12:38 +0000

This week's tidbit will show you how to launch an app when a user clicks on a link. Last time, I wrote about debugging a view binding issue in Android.

Have you ever had an app launch on your mobile device when you click a link in an email, on a webpage, etc. and wondered how to do the same thing for your app? Wonder no more, because in this simple guide I will show you how to accomplish this!

Android

On Android, this can be accomplished by defining an <intent-filter> in your app's AndroidManifest.xml.

Here's a simple example:

<intent-filter>
  <action android:name="android.intent.action.VIEW" />
  <category android:name="android.intent.category.DEFAULT" />
  <category android:name="android.intent.category.BROWSABLE" />
  <data 
    android:scheme="https"
    android:host="matthew-b-groves.medium.com"
  >
</intent-filter>

Doing something like this would cause any link that began with https://matthew-b-groves.medium.com (the URL for my Medium profile) to launch this app instead.

You can even define multiple <data> listings to allow multiple URL patterns to invoke your app. (Note that any possible combination of schemes/hosts that you have defined will match - even across <data> entries)

Depending on your desired behavior, you can even use something completely custom for the android:scheme, such as mattstidbits, and omit the android:host property entirely. This would allow any URL starting with mattstidbits:// to launch your app. However, this will only work if the user has your app is installed. If you want to direct the user to the Play Store listing for your app if they don't have it installed, you'll want to use an http or https scheme and a host/domain that you own. Then, you can follow these instructions to create a JSON file that you can embed on your website that will instruct browsers to redirect users to the Play Store listing page for your app.

If you want to have your app access information that's embedded in the URL (so you can take them to a specific screen within the app), you'll want to add something like the following to your application's onCreate method:

val action: String? = intent?.action
val uri: Uri? = intent?.data

You can then verify that the action was Intent.ACTION_VIEW and grab the uri that was passed in and use the methods/properties of the Uri class to pull out information from the URI to help you handle the request.

It's also a good idea to test your deep linking, which you can do on a simulator or physical device using the adb command, like this:

adb shell am start -d "your-deep-link-url"

The Android developer documentation for implementing deep linking is really excellent, which you can find here: https://developer.android.com/training/app-links/deep-linking

iOS

Disclaimer: I am not an iOS developer by trade, so I can't provide nearly the level of detail that I can for Android.

Apple appears to offer two different mechanisms for launching an app from a URL - URL Schemes and Universal Links.

URL Schemes are easier/faster to implement, but prompt the user for permission and don't work if the app is not installed.
Universal Links require you to have control of the domain (much like Google's App Links that I described above), so they require more work to set up, but they won't prompt the user and allow you to provide a fallback URL if the user doesn't have the app installed.

This article does a good job of explaining some of the differences: https://medium.com/wolox/ios-deep-linking-url-scheme-vs-universal-links-50abd3802f97

For now, let's focus on URL Schemes, since that's the approach I have worked with before. To set one up, all you have to do is specify the scheme in Xcode via the Info tab in your project's settings. Note that unlike Android, iOS only lets you define the scheme (the part that comes before the :// in a URL). So, you could enter mattstidbits in the "URL Schemes" field, so any links beginning with mattstidbits:// would launch your app (if it's installed).

In your Info.plist file this shows up under the CFBundleURLSchemes key.

If you want your app to access the information that's stored in the URL, then you'll need to handle this inside of your app delegate's application() method. There's a url argument that will contain the data.

As with Android, you can test these deep links by running the following terminal command:

xcrun simctl openurl booted "your-deep-link-url"

(Again, I don't pretend to be an iOS developer, so please see the official documentation for how to do this.)

React Native

If you've been following my tidbits for a while, you probably wondered if I would touch on this - here's how to do this in React Native!

React Native has two different setups - if you are using Expo, follow these instructions to specify the scheme you'd like to use within Expo's JSON config.

However, if you are not using Expo, you generally need to follow the same steps above for iOS/Android to set up deep linking in your AndroidManifest.xml and Info.plist. To get this working in a React Native CLI project, you should follow these instructions to configure your project. Note that for iOS you'll need to add some special code to your AppDelegate to make this work.

Note that both of these options assume you are using React Navigation for managing navigation within your app (which I highly recommend you do!)

If you want to be able to actually do something with the URL (and not just simply invoke the app), you will need to configure a linking object and assign that to your NavigationContainer.

The linking object is a little funky, in that it's like a copy of your navigation graph. It gives you the power to map URL parameters to internal route names/paths, but does require you to match your app's navigation graph precisely.

For example, you might set this up as follows:

const config = {
  screens: {
    Tidbit: 'post/:id',
    Profile: 'user',
  },
};

const linking = {
  prefixes: ['https://matthew-b-groves.medium.com'],
  config,
};

function App() {
  return (
    <NavigationContainer linking={linking}>
      <Stack.Navigator>
        <Stack.Screen name="Tidbit" component={PostDetailScreen} />
        <Stack.Screen name="Profile" component={ProfileScreen} />
      </Stack.Navigator>
    </NavigationContainer>
  );
}

Where this can start to get a little tedious is if you have nested navigators (which you likely do), your linking object will need to also match that nesting.

For more details, see this article.

To test the link with an Expo project, run the following command (substituting ios in place of android below if you'd like to change what platform you're targeting):

npx uri-scheme open "your-deep-link-url://127.0.0.1:19000" --android

For a non-Expo project, you can test the deep linking via the native iOS/Android commands described in the sections above.

Overall strategies

What can we take away from this?

Deep linking on both iOS/Android/React Native provides sophisticated functionality.
In nearly all cases, you probably want your links to have the same format across iOS/Android for consistency's sake (having links work on either platform seamlessly)
I would recommend starting with the simplest approach and building from there - there can be a lot of red tape to work through to get files changed in your company's/project's website in order to use the more sophisticated App Links (Android) or Universal Links (iOS), so if you're able to get by with the more basic deep linking/URL schemes (where you don't need to modify a website), then start with that.

Interested in working with me in the awesome Digital Products team here at Accenture? We have an opening:

Mobile Developer (Northeast locations)

Do you have other deep linking tips you'd like to share? Let me know in the comments below!

Matt's Tidbits #102 - Debugging a perplexing view binding issue

Matthew Groves — Tue, 12 Oct 2021 13:09:35 +0000

This week I have a tidbit (plus a bonus!) to share about converting an existing app to using Android view binding. Last time, I wrote about how to write a good bug report.

First, the bonus! (Shouldn't dessert always come first?) I recently started getting back into some Android development (after working in React Native for the past 6+ months), and opened up the shiny new Arctic Fox release of Android studio. Upon doing so, however, I noticed that many of my familiar keyboard shortcuts no longer worked (such as ⌘W for closing an editor window). It appears that Android Studio changed the default keyboard mappings - so if you run into this, just go into Preferences->Keymap and select "macOS" instead of "IntelliJ IDEA Classic".

Now, for the main tidbit. 😉

The reason I came back to Android is because I am updating an internal project to work with all of the latest tools/paradigms/etc. This app still uses MVP as its paradigm, and even still uses Butterknife (which has been deprecated for more than a year). The UI for this app is fairly simple - it has a RecyclerView, and when you click on one of those items it launches a new activity. In the process of switching over to Android view binding, however, I ran into a bug - nothing was rendering in my RecyclerView!

I spent WAY longer than I'd like to admit debugging this - putting in breakpoints, print statements, double-checking that the data was being passed to the right place, trying various combinations of calling notifyDataSetChanged() and submitList() - all to no avail. No matter what I did, the onCreateViewHolder() and onBindViewHolder() methods of my adapter were never being called.

Stumped? Thankfully, the solution ended up being pretty simple. Once I looked at a complete implementation for a screen that had a working RecyclerView, I noticed a key difference.

In the activity that wasn't working, I had the following line in the onCreate() method:

setContentView(R.layout.my_activity)

However, the activity that worked had this line instead:

setContentView(binding.getRoot())

That was it! Switching to the newer version that used the binding object I had saved was enough to do the trick.

What did I learn from this?

I need to do some more studying to make sure I'm staying up-to-date with the latest tools (I haven't honestly used view binding that much - I like what I see thus far, but I didn't really know what to look for at first).
Take a break/talk to someone else - I will give my wife the credit for this one - she's not a programmer, but asked me what I was trying to solve, and simply in the process of trying to explain it and showing her the code, I stumbled upon this key difference.
Simplify the problem/challenge your assumptions - I should have done this sooner - stripping out all unnecessary code and sanity-checking myself to make sure I could reproduce a working solution, and then comparing that with what wasn't working.

I hope you learned something, and that if/when you convert your old Android UI code to use view binding that it's a smoother/faster transition than this was for me!

Interested in working with me in the awesome Digital Products team here at Accenture? We have several open roles, including:

What has your experience with using view binding been like? Let me know in the comments below!

Matt's Tidbits #101 - How to write a good bug report

Matthew Groves — Tue, 28 Sep 2021 14:13:34 +0000

This week I have a story to share about filing bug reports -why they're important, and what makes a "good" one. Last time, (sorry for the delay between posts!) I wrote about some Teams-related tips.

I've written several tidbits before where I file a bug report, but I have an exciting update to share - one of the bugs I filed has recently been fixed as a direct result of my report!!

In February of 2020 I wrote about a bug I had discovered where Android Studio's "quick fix" suggestion for Kotlin-based classes that derive from Android view components dangerously auto-generate a constructor with the @JvmOverloads annotation which causes the default style/theme properties to be ignored.

The report describing the bug is here: https://issuetracker.google.com/issues/149986188

What's the lesson to be learned here? Aside from my original caution around using @JvmOverloads, what I would like to impart this time is around how to write a good bug report. This is really one of the key differences between the bugs that get fixed and the ones that get ignored.

So, what goes into a good bug report?

A clear description of the problem - if people can't understand what you're talking about, it will be disregarded very early on in the process. The trick is to be very precise about what the issue is, with a sufficient level of detail - as a developer, I've seen bug reports that say " doesn't work" - that's not good enough. Also try to specify exactly what versions of all components you are using (Android Studio, Kotlin, libraries, phone make/model, OS, etc.), and if you can, do a little extra testing to determine and be able to explain what configurations may be impacted by this issue.
An easily reproducible test case - it's one thing to understand what the problem is, but you can greatly boost the likelihood of your issue being addressed if you do a little extra work to put together a sample project that clearly demonstrates the issue. Don't just upload a copy of your entire project - the smaller/simpler an example you can provide, the better.
A description of what the expected behavior should be - if the person investigating your bug has followed you through the first 2 items above, but you haven't spelled out what you think should happen, your bug may not get worked on - they may believe that it "functions as designed". This is where you can use some persuasive/logical arguments to clearly explain why the current behavior is wrong, and what it should do instead.
Double-check your bug report for errors (logical errors, missing information, typos, poor grammar, etc.) If there are bugs in your bug report, it's not going to be taken as seriously - so be sure to double-check it for errors, and try to write it in a professional tone. Using full sentences with proper capitalization, etc. eliminates the hurdle of the person reading it possibly concluding that you don't know what you're talking about.
Publicize the issue and get other people on board - the more people who are clearly affected by the issue, the more highly it will be prioritized. So, once you have submitted the issue, share it as broadly as you are able - tell your coworkers past & current and ask them to do the same, and consider writing an article about it to increase its visibility.

Follow the above steps, and with any luck, your issue will be resolved! The quality of especially open source projects increasingly relies on members of the community reporting the issues they're experiencing. And, if it seems like your bug is taking a long time to be fixed, consider trying to resolve it yourself! Open source projects often have limited developer resources, so if you provide a solid fix for the issue yourself (or at least have done some research into the cause and provide a suggestion for how to fix it), this can be another helpful boost towards getting the issue resolved.

Finally, note that the above suggestions don't just apply to external bug reports - these same strategies can be used to supercharge your internal bug reports as well!

For reference, here are two other Android Studio bugs I have filed previously which have also been resolved (both of these indirectly, but it can still be helpful the project's developers to provide additional data points):
https://issuetracker.google.com/issues/131403382
https://issuetracker.google.com/issues/143971679

Interested in working with me in the awesome Digital Products team here at Accenture? We have several open roles, including:

Do you have other suggestions for how to write a good bug report? Let me know in the comments below!

Matt's Tidbits #100 - All About Teams

Matthew Groves — Tue, 03 Aug 2021 14:23:07 +0000

This week I have a few Teams-related tidbits to share! Last time I wrote about elegantly handling null/undefined values in a variety of languages.

🎉 First of all, a little celebration for my 100th tidbit! 🥳
The frequency may have slowed down a little bit from when I first started in January of 2019 (because life and work both happen!), but as long as there's a willing audience, I have no plans to stop writing these!

MS Teams - love it or hate it, it's here to stay. Regardless of your personal viewpoint though, you will probably benefit from these tidbits to help you use it more effectively!

#1 - In the past few weeks, I noticed that the MS Teams icon in the Dock on my Mac stopped indicating how many unread messages I had. This is a serious issue, as it's one of the primary ways my team communicates, and caused me to be slow to respond to countless messages. The good news is, I found a way to fix this!!

All you have to do is the following:

Open MS Teams, click the 3 dots in the upper-right corner next to your profile photo, and select "Settings"
Open the "Notifications" section
Under "Notification style", ensure that "Mac" is selected - for some reason, the option that was active for me, "Teams built-in" does not work.
Verify in macOS System Preferences, under "Notifications" that "Allow Notifications from Microsoft Teams" is enabled and "Badge app icon" is checked. Now have someone send you a message and it should work like a charm!

#2 - If you're in a Teams call and, like me, find it a little slow/inconvenient to click the mute button, there's a handy shortcut you can use:

Click the mute button (once, probably early on in the meeting) - this will display a selection box around the mute button
... which means that you can press the space bar to perform the operation of clicking the button! As long as you don't navigate somewhere else in Teams, and Teams stays the active application, this trick will work!

(Thanks to our Northeast Digital Products lead, Binta Patel, for this tip!)

Speaking of teams, I've recently taken on a new role on my team- I am now one of the co-leads for our mobile team in the Northeast. I'm thrilled to have the opportunity to help guide this amazing group of people and set the direction for where we're headed! We have a bunch of openings, so if you'd like to join me on this journey (or know someone who might be a good fit), please check out the following postings, and feel free to send me a message if you have any questions! (All postings are for the Northeast - Boston, NYC, etc. unless specified otherwise)

iOS Mobile Developer Apprentice (closing soon!)
UI/UX Design Apprentice (closing soon!)
Midwest Android Mobile Developer Apprentice (closing soon!)
Midwest iOS Mobile Developer Apprentice (closing soon!)
Mobile Developer #1
Mobile Developer #2
Mobile & Web Engineering Director
DevOps Engineer

Do you have other MS Teams-related tips? Let me know in the comments below!

Matt's Tidbits #99 - Handling null elegantly

Matthew Groves — Tue, 06 Jul 2021 14:16:09 +0000

Last week I wrote about some truthiness edge cases in JavaScript. This time, I have a quick tidbit on elegantly handling null/undefined values.

null - called the "Billion-Dollar Mistake" by its inventor, C.A.R. Hoare - most programmers are probably intimately familiar with this (and why it might be categorized as a mistake!)

We've certainly all written some code like this:

if(foo != null) {
  // Do something with foo
}

But, what if foo is an object with multiple levels of nested objects? You'd probably agree that it gets a little cumbersome to write something like this:

if(foo != null) {
  if(foo.bar != null) {
    if(foo.bar.baz != null) {
      // Now it's safe to use foo.bar.baz
    }
  }
}

Some more modern languages (Kotlin, JavaScript 2020, Swift, etc.) have support for what's known as "safe calls/optional chaining", and it looks like this:
x = foo?.bar?.baz?.doSomething()

The ? indicates that the right-hand side should only be evaluated if the left-hand side is not null. However, if any part of this expression is null, then x will be null.

What if we wanted to specify what value x should have in case any of the null checks fail? We could obviously achieve this by checking if x is null after the statement and then assigning a different value to it, but if we wanted x to be a constant, this would not be possible.

Some languages support a ternary operator, so you could do something like this:
x = foo?.bar?.baz ? foo?.bar?.baz?.doSomething() : <fallback value>

In my opinion, this is repetitive, and it's also error-prone - if doSomething() returns null, then x could still be null! You could work around this by putting ?.doSomething() before the ? of the ternary operator, but are we sure it's safe to call doSomething() more than once? It could have side-effects that introduce subtle bugs into our code or be resource intensive and degrade our application's performance.

Instead, I'd like to propose a better way - the null(ish) coalescing operator:
x = foo?.bar?.baz?.doSomething() ?? <fallback value>

This way, x can still be a constant, we'll catch any possible null values in the entire chain, and we're only calling doSomething() one time (at most).

Now, if you caught it, why did I call this the null*(ish)* coalescing operator? That's because in JavaScript, the optional chaining operator and null coalescing operator apply to BOTH null and undefined. Neat, huh?

I had known about this concept from working in Kotlin, where this functionality is called the "Elvis operator". It's written as ?: - which looks a little bit like the top of Elvis' head (eyes & his signature curly hairdo) - plus, in the Kotlin community we can remember that anything that happens to the right of the operator is what occurs when "Elvis has left the building" (i.e. if you've encountered a null and left the optional chain) And yes, I know - Programmers can be real nerds sometimes. ;-)

Now that I've been working in React Native using TypeScript (which is built on top of JavaScript), I discovered that this functionality also exists there. Which led me to discover that Swift has this same concept too - the "nil coalescing operator" (represented by ??).

All of this to say - I think it's really exciting that more and more modern programming languages are converging and supporting ever more similar ways of writing code. Each language will always have its quirks (as well as advantages & drawbacks), but I think we're getting much closer to a world where Android developers can read through an iOS codebase and understand what's happening (not so back when they were still written in Objective C), or a traditional web developer can work on a mobile application (already a reality thanks to technologies such as React Native).

Know of other languages that support some variant of optional chaining/null coalescing? I'd love to hear from you in the comments!

Interested in working with me in the awesome Digital Products team here at Accenture? We're hiring mobile developers, web developers, and more!

Matt's Tidbits #98 - The truth will set you free (unless you're using JavaScript)

Matthew Groves — Tue, 29 Jun 2021 12:59:19 +0000

Last time I shared a quick tidbit about running individual unit tests. This time, I want to share a few interesting things I learned while debugging a failing unit test.

If you've used JavaScript for any length of time, you may have encountered its slightly special behavior around boolean expressions. In many other languages, if statements can only contain boolean expressions - either a boolean variable, or some other expression which returns a boolean value, such as: greater than, less than, equal to, not equal to, etc.

However, in JavaScript, ALL variables themselves are inherently true/false - this is known as "truthiness", and you can view the full table here: https://developer.mozilla.org/en-US/docs/Glossary/Truthy

Where this becomes problematic is that it's SO easy to misuse this or have subtle errors in your code. In other languages, if you put a string inside of an if statement, you'll get a compile error, since it's not a boolean expression. In JavaScript though, you can do this without any errors at all - not even at runtime. Instead, every value is "coerced" to boolean. And, the rules aren't always intuitive.

The important thing to remember is that ONLY the following values evaluate to false - ALL others evaluate to true:

false
0
-0
0n (BigInt 0)
"" (empty string)
null
undefined
NaN (not a number)

Frankly, this list doesn't look all that bad. It kind of makes sense (don't get me started on -0 (negative zero) - that just has danger written all over it), but having an empty string evaluate to false sort of makes sense. What doesn't make sense, however, is that an empty array [] evaluates to true. C'mon guys - if you're going to have a very flexible/dynamic type system, at least make it consistent! Arrays and strings can both be null or undefined - so why is an empty string treated differently from an empty array?

The answer lies in a subtlety of the JavaScript language - strings are a special type, while arrays are objects. In JavaScript, all object references (as long as they aren't null or undefined) evaluate to true.

Anyways, as you may have gathered by now, I experienced this exact problem, where I was expecting an empty array to be false, but it was in fact true, and it took me running a unit test through a debugger to figure it out.

The moral of the story is, if you're unfamiliar/new to a particular language, make sure you carefully read (and re-read) the documentation, and always challenge your assumptions when debugging.

What are your favorite JavaScript "Truthy" stories? Let me know in the comments!

Interested in working with me in the awesome Digital Products team here at Accenture? We're hiring native mobile developers, hybrid mobile developers, web developers, and more!

Matt's Tidbits #97 - Running/Debugging individual Jest unit tests

Matthew Groves — Tue, 01 Jun 2021 14:16:06 +0000

Last week I wrote about React Fragments. This week, I have a quick tidbit about running tests in VS Code.

I hope you all had a restful long weekend! I've written about the importance of vacation before, and in this pandemic that just seems to keep on going (although hopefully we're starting to see the end), it's more important now than ever to prioritize your health and take care of yourself!

As you may have noticed, since I've been writing about it a bunch recently, my current project is using React Native. We're using Jest for our unit tests, and it's a pretty decent tool. However, it caught me slightly by surprise that the only way (that I knew of) to run our tests was via a yarn test command that ran them all at once. This became especially troublesome when I had to debug a failing unit test (perhaps I'll write about that next time), and was trying to find a way to shorten my write/test cycle.

Thankfully, one of my coworkers pointed me at a VERY helpful VS Code extension: https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner

This extension provides links next to each unit test to let you run or debug them individually! If you're using Jest & VS Code, you really MUST download this extension - I guarantee you it will come in handy!

What are your favorite VS Code extensions? Let me know in the comments below!

Interested in working with me in the awesome Digital Products team here at Accenture? We're hiring!

Matt's Tidbits #96 - Cleaner Components with React Fragments

Matthew Groves — Tue, 25 May 2021 12:17:21 +0000

Last time, I wrote about defining constants in TypeScript. This week, I want to share what I learned about React Fragments!

To many of my readers who are Android developers, you already know all about Fragments from the standpoint of building Android UI. However, in the React/React Native world, Fragments serve an entirely different purpose.

First, an example — say you want to define a method (or component) that returns some elements, for example:

const Stack = createStackNavigator()
const SomeComponent = () => {
  return (
    <Stack.Navigator>
      getScreens()
    </Stack.Navigator>
  );
};

A likely first implementation of getScreens() would return an array (at least, this is how I did this at first):

const getScreens = () => {
  return [
    <Stack.Screen name="Screen1" component={Screen1Component} />,
    <Stack.Screen name="Screen2" component={Screen2Component} />,
    ...
  ];
};

Unfortunately, this approach will yield a compiler warning:

Warning: Each child in a list should have a unique "key" prop

The reason for this is that React dictates that every element in a list must have a uniquely identifiable “key” property — largely to assist in comparing two versions of the same list — were new elements added, were some elements removed, or did existing elements change position in the list? This is a great feature, but in the case of our list of Screens, it’s somewhat redundant to have to define a “key” property on each item. We already have a unique “key” (the name field), and besides, we’re not expecting this list to change over time.

Thankfully, React provides a cleaner solution to this very problem — Fragments!

Here’s what getScreens() would look like if we use a Fragment instead:

const getScreens = () => {
  return (
    <React.Fragment>
      <Stack.Screen name="Screen1" component={Screen1Component} />
      <Stack.Screen name="Screen2" component={Screen2Component} />
    </React.Fragment>
  );
};

Voilà! This works just as well, we don’t have to add commas to the end of each line, and, most importantly, we don’t need to define a “key” property on each item.

There’s one more neat shorthand you can use, and that is to replace <React.Fragment> with the short syntax <> to further clean this up and make it clear that the Fragment is really just a wrapper.

An alternative approach would be to wrap elements within a React <div> or React Native <View> element, however, this has a few drawbacks:

You’re actually adding an additional item to the view hierarchy — Fragments disappear during the rendering process.
Some scenarios, like the React Navigation example above, will not allow for any element other than a <Stack.Screen> to be embedded directly within a <Stack.Navigator> — leaving Fragments as the only viable option.

I hope you learned something useful about Fragments that will help improve your React code! Do you use Fragments in other/unique ways? I’d love to hear about it in the comments!

Interested in working with me in the awesome Digital Products team here at Accenture? We’re hiring!

Matt's Tidbits #95 - Defining constants in TypeScript

Matthew Groves — Tue, 11 May 2021 12:13:29 +0000

Last time I wrote about how to write safe enums in TypeScript. This week's tidbit is also TypeScript related - how to define constants!

Defining a constant in TypeScript can be pretty simple - you can just write something like const SOME_CONSTANT="FOO";. However, that const keyword only works if you're defining variables at file-scope or inside a function. What if you want to group your constants under some kind of named object (as is common in other languages such as Java, C++, etc.)

The obvious way (and what I did to start), was simply to define an object to contain my constants, like this:

const NamedVariables = {
  SOME_CONSTANT_1: "FOO",
  SOME_CONSTANT_2: 42,
  DEFAULT_FONT_WEIGHT: "700",
};

This allows me to use this like this: NamedVariables.SOME_CONSTANT_1. Great!

However, there's one tiny gotcha. This works fine for some situations, but in cases where TypeScript is expecting a value that's part of a union type, such as specifying the fontWeight property of a React Native TextStyle, you may see an error such as this:

Type 'string' is not assignable to type '"normal" | "bold" | "100" | "200" | "300" | "400" | "500" | "600" | "700" | "800" | "900" | undefined'.

If you're like me, you might scratch your head over this for quite a while. Until you realize (do some fervent Google searching) that Object properties are not constant by default.

The const in const NamedVariables above means that the reference to that object is constant - so it would be illegal to do something like NamedVariables = <something else> after it's already been defined. Which is good - we definitely don't want someone to reassign our constants object. But how can we define its properties as constant?

The first thing I found is to use Object.freeze() - this returns an object whose properties are read-only. So, if we try this with our example:

const NamedVariables = Object.freeze({
  SOME_CONSTANT_1: "FOO",
  SOME_CONSTANT_2: 42,
  DEFAULT_FONT_WEIGHT: "700",
});

Unfortunately, this STILL doesn't work if we try to use DEFAULT_FONT_WEIGHT in a union type. Why is this? As best as I can understand, it's because TypeScript doesn't recognize this as a true constant - Object.freeze() makes use of some somewhat crazy runtime checks that throw an error if you try to modify it. So, chalk this one up to a limitation (maybe temporary? maybe permanent?) of TypeScript.

So… is there any way to achieve this? The good news is, yes!

Here's how we can make all properties on an object be treated as constants:

const NamedVariables = {
  SOME_CONSTANT_1: "FOO",
  SOME_CONSTANT_2: 42,
  DEFAULT_FONT_WEIGHT: "700",
} <b>as const</b>;

That's it - those two little keywords at the end as const - are a TypeScript addition (not part of JavaScript) that instruct the type checker that all properties on that object should be treated as constants.

I highly recommend adding this to all of your Objects that you intend to be constants. Let the type system help you!

Do you define constants differently? I'd love to hear from you in the comments!

Interested in working with me in the awesome Digital Products team here at Accenture? We're hiring!

Matt's Tidbits #94 - Writing safe enums in TypeScript

Matthew Groves — Tue, 27 Apr 2021 21:08:32 +0000

Last time I wrote about how to get started with React Native. This week, I have a quick tidbit about writing safe enums in TypeScript!

Many programming languages have support for enums, but they work slightly differently in TypeScript.

It’s really simple to define and use an enum — you can do so like this:

enum MyEnum {
  A,
  B,
  C,
}

function foo(enum: MyEnum) {}

foo(MyEnum.A);

What really surprised me is that it’s also perfectly valid to do this:

foo(42);

WHY?!!? To be honest, this really makes no sense to me at all. If I’ve gone through all the trouble of defining an enum (and specifying an enum as a parameter to a function), why can I specify any arbitrary number in place of this enum and have it still be valid code?

<5 minute meditation break/>

The good news is, there’s a way to guarantee that your enums cannot be used in this way!

As in many other programming languages, enums are typically represented as integers — the first enum value is equivalent to 0, the second is 1, etc. However, TypeScript has support for two other types of enums: string-based and heterogeneous enums.

Unfortunately, heterogeneous enums suffer from the same problem as numeric enums. But, string-based enums do not!

So, if you change your enum definition to look like this:

enum MyEnum {
  A = 'A',
  B = 'B',
  C = 'C',
}

Now the only way to call our foo function is by passing one of the valid enum values — passing arbitrary numbers (or strings) will produce the following compile error:

Argument of type '42' is not assignable to parameter of type 'MyEnum'.

There may be cases where you want to be able to specify arbitrary numeric values for enums, but I will be sticking to the string-based version!

For more information on enums in TypeScript, check out the official handbook: https://www.typescriptlang.org/docs/handbook/enums.html

If anyone knows why TypeScript enums were designed with this behavior, please let me know in the comments!

Interested in working with me in the awesome Digital Products team here at Accenture? We’re hiring!

Matt's Tidbits #93 - Getting started with React Native

Matthew Groves — Tue, 06 Apr 2021 14:16:00 +0000

Last time I shared a few IDE-related tidbits. This week, I have some quick tidbits on getting started with React Native!

My latest project is using React Native (with TypeScript), so I've been doing a lot of studying and preparation.

One of the tutorials I went through had me set up a fresh project using React Native's TypeScript template. Unfortunately, I discovered that it wouldn't build for iOS! After a little searching, it turns out there's a known issue: https://github.com/facebook/react-native/issues/30836

In my sample project, I took the approach of commenting out the "Flipper" dependency, which allowed the app to build successfully.

I know React Native gets a lot of bad press, but in my opinion, the underlying principles modeled in React (unidirectional data flow, etc.) are awesome, and native Android development could benefit a lot from using patterns like this! If you're interested in learning more, this "Thinking in React" article from the official React website (and the rest of their "Main Concepts" documentation) were especially helpful: https://reactjs.org/docs/thinking-in-react.html

As an Android developer, I haven't had many reasons to use Xcode before, but I'm excited by the idea of getting to develop for iOS (I've been an Apple fan for the past 25+ years). I did run into one issue (at least on my somewhat locked-down work laptop) - the standard instructions of installing Cocoa Pods via the gem command didn't work for me. But, I was able to get it working by installing them via brew.

It's also important to make sure the Xcode Command Line Tools path is set in Xcode->Preferences->Locations. If it's not, you won't be able to build iOS apps in React Native!

Have any other helpful tidbits for someone getting started with React Native? Let me know in the comments!

Interested in working with me in the awesome Digital Products team here at Accenture? We're hiring!

Matt's Tidbits #92 - A few neat IDE tidbits

Matthew Groves — Tue, 23 Mar 2021 14:18:31 +0000

In my last post, I wrote about the RxJava share operator. This week, I have a few quick IDE tidbits!

I've written about some fun IDE plugins before in Tidbit #6, but I recently got a new work laptop, and in the process of reinstalling Android Studio discovered a new one!

Previously I had been using the NyanCat progress bar (because work should be fun!), but when I found out there's a MARIO PROGRESS BAR I knew I needed to check it out:
https://plugins.jetbrains.com/plugin/14708-mario-progress-bar

If Mario isn't your thing, that's ok - there are a LOT of different options, depending on your preferences:
https://plugins.jetbrains.com/search?search=progress%20bar

I alluded to multiple tidbits in the title of this article, so hopefully you're still with me! My next project is going to be written in React Native, so I have been refreshing my JavaScript and learning all about the new frameworks. Part of the change means leaving the familiar confines of Android Studio for other editors - in this case, Visual Studio Code.

I've used Visual Studio before at a previous job, and VS Code is a fine editor, but I've really gotten used to working in Android Studio. For me, part of the biggest challenge of switching development languages is changing tools.

The good news is, I discovered a plugin for VS Code that applies many of Android Studio's keyboard shortcuts to VS Code! You can find it here: https://github.com/kasecato/vscode-intellij-idea-keybindings

I'm still refreshing my JavaScript skills, learning TypeScript, and getting used to programming in a dynamically-typed language (that's the real challenge), but being able to navigate in the editor in a way I'm used to has been very helpful thus far.

This type of plugin is available for many other different editors. So, if you're moving to a new project, and aren't comfortable with the tools, see if there's a keymapping plugin that will make the editor behave like one you already know!

Two questions this time:

What editor has your favorite keybindings? (Not your favorite editor per-se - I'm not trying to start a vi vs. emacs war)
What is your preferred progress bar for Android Studio? Standard? Nyan Cat? Mario? Something else?

Let me know in the comments!

Interested in working with me in the awesome Digital Products team here at Accenture? We're hiring!

These tidbits were discovered on March 10, 2021.