Typescript: Preventing generic string keyed objects from overlapping with Arrays

 This was a bit of a doozy and took me the better half of a day to find a semi decent fix for it.

Here's the unsuspecting use case and why it caused problems (try it out on Typescript playground)

  • SingleConfig and MultiConfig are different types. One is a single object value, the other is an array of that.
  • conditionalReturn() returns either one of those depending on the input.
  • onlyWorksWithSingleConfig() as the name states will only work with an instance of SingleConfig
  • Typescript doesn't seem to detect an issue when using onlyWorksWithSingleConfig() with the result from conditionalReturn()

Why? Because Javascript is a hot mess when Arrays are considered to be objects. It is possible that Typescript allows that behaviour because Javascript arrays are keyed by strings (not numbers) so it will fit the type interface specified by SingleConfig.

For instance, look at this output.


So now that we have a possible reason why this is allowed in Typescript, how can we prevent it?

Attempt 1 - use type guards

As documented here, I tried using them to enforce some sort of sanity. It did not work.

Attempt 2 - disallow [index: number] in SingleConfig

I found this on StackOverflow and thought it was an elegant solution to the problem, however quickly realised it broke a valid use case where this syntax would be marked as incorrect.


Attempt 3 - Disallow "random array prototype member" ✔

A smart fellow at work suggested being a bit more specific with the "never" clause.

Instead of trying to capture all the cases, why not filter out a specific case, like "length"? (Just to be safe, I used something a bit more weird like "lastIndexOf" to avoid potential issues)

And it worked! Just like that, Typescript is now correctly detecting the two separate types.


It even fixed up the type guard function isSingleType() !

Android: How to disable Chrome's useless share menu (aka the "Chrome Sharing Hub")

Note: this flag should also work on Chrome derived browsers such as Brave and Vivaldi.


It's frustrating when a company like Google tries to be all user-friendly up in your face by adding extra steps to what used to be a simple workflow.

Before:

  • Click share button
  • Choose app to share to
After:
  • Click share button
  • Scroll through horizontal list of apps (which has no visual clue to indicate that you can scroll)
  • Click on "More ..."
  • Find the app you want to share to

 I know it isn't that much but its a chore, so lets kill it.


This fucken thign right here.

Steps to disable

  • Open a new tab
  • Go to chrome://flags/#chrome-sharing-hub
  • Double check you're looking at "Chrome Sharing Hub"
  • Click on "default" for that setting
  • Change it to "disabled"
  • I also changed the setting for "Chrome Sharing Hub V1.5" but not sure if its needed

Source

Android: How to figure out which key store your app was signed with

It's been more than a few years since I've signed an APK for release and over time I've forgotten which key store I used to sign apps.

Fortunately, if you've got Java installed then you already have everything required to verify this information.

Step 1 - Acquire the APK(s)

Grab the APK file off Google Play Console (it's in "App Bundle Explorer" > "Downloads").

If its a publically published app then you could probably try grabbing it from a 3rd party APK host as well, but be wary that some dodgy ones may resign your APK.

Step 2 - Get the certificate fingerprints from your key store

Using command prompt, go to the "bin" folder in your Java install path. For me, it was at:
cd "C:\Program Files (x86)\Java\jre1.8.0_251\bin"

 Use "keytool" to read the key store information:

keytool -list -keystore "C:\Coding\Android\keystore"

It should print out a bunch of info, but the line you're interested in here is the bit after:

Certificate fingerprint (SHA1): ...

Take note of that information somewhere along with the key store filename.

Step 3 - Determining the APK certificate fingerprint

From the APK file, open it with an archive utility like 7-zip. If you can't figure out how, just rename it from "whatever.apk" to "whatever.zip".

Extract "META-INF\CERT.RSA".

Reusing your command prompt terminal from before, staying in the same path and run keytool again but with a different set of arguments:
keytool -printcert -file "C:\Users\twig\Desktop\whatever\META-INF\CERT.RSA"

Enter in the password if needed.

This will again spit out a bunch of information. The bit you're interested in is the SHA1 line under "Certificate fingerprints

Certificate fingerprints:

         MD5:  ...

         SHA1: ...

         SHA256: ...

Remember, a key store may contain multiple entries! This means there could be multiple certificate fingerprints.

By verifying the SHA1 fingerprints in the APK and the key store, you should now have enough information to figure out which key store entry was used to sign the APK.

Good luck!


Sources

 
Copyright © Twig's Tech Tips
Theme by BloggerThemes & TopWPThemes Sponsored by iBlogtoBlog