Featured

Force commits to pass TSLint

Story

I was recently working on a project and multiple collaborators started to contribute to. All seemed fine until one day, I synced up with the master branch and had 100 warnings pop up in VSCode. I thought about buying my hot dog cart and moving to a beach area finally.

 

hotdogcart.jpg

Being totally honest, that cart near the beach looks way more fun than sitting behind a desk staring at a beam of light sucking my soul away sometimes, but that’s just me. You are different and still love programming, because you’re young and full of energy. You’ll mature once you realize you attend meetings that could have been emails for years.

At any rate, lets get back to the issue.

So here I was staring at 100+ warnings all related to TSLint. At first, I thought, “Damn, I’m gonna Macho Man Randy Savage elbow drop someone.”

elbowdrop.gif

I then started thinking “how could they commit with these warnings?”, it turned out I had the TSLint extension for VSCode installed and they did not, so they never seen the warnings as they worked on the project. Worse yet, nothing was in place to warn them or prevent the code from being committed.

The Solution

We already use a precommit hook that runs Prettier against files so it was a simple step to add tslint to run during the precommit hook we have in our project.

"lint-staged": {
    "*.ts": [
      "tslint",
      "prettier --write",
      "git add"
    ]
  }

The above basically runs on all the TypeScript files and runs `tslint` then `prettier` and last `git add`.

As for how this gets executed I have a brief write up on adding a precommit hook for Prettier. Which outlines the dependencies on `husky` and `lint-staged`. If you don’t want to look at that, then add the following as a script in your package.json `scripts` section:

    "precommit": "lint-staged",

Be sure to add the dependencies to your project as well under the `devDependencies`: `lint-staged` and `husky`.

Now when someone tries to commit files to the repo their files will be ran against `tslint` (at this point I shouldn’t have to tell you that you need it inside your project). If all the tslint checks pass then the commit works, if not you’ll have errors with your git logs.

Dismiss the Android SoftKeyboard Programmatically in a NativeScript App

Be Gone You Damn KeyBoard

If you’re like me you get really frustrated with apps that leave the soft keyboard open when you’ve completed some action that should have closed it. Maybe you completed a form and tapped a ‘Submit’ button, well that keyboard is pointless now so hide the thing please. There are some use cases where you don’t want to but oh well I’m going to tell you how to get rid of it when you want to in your code.


import * as app from 'application';

import { isAndroid } from 'platform';

/**
* Hide the keyboard with a conditional Android platform check.
*/
private hideKeyboard() {

   if (isAndroid) {
      try {
         let activity = app.android.foregroundActivity;
         let Context = app.android.currentContext;
         let inputManager = Context.getSystemService(android.content.Context.INPUT_METHOD_SERVICE);
    inputManager.hideSoftInputFromWindow(activity.getCurrentFocus().getWindowToken(), android.view.inputmethod.InputMethodManager.HIDE_NOT_ALWAYS);
      } catch (err) {
         console.log(err);
      }
}
}

The code is pretty simple and just uses the Android InputMethodManager service and calls the hideSoftInputFromWindow() method. Has worked great in my apps and hopefully it helps you out if you ever need to get rid of the keyboard in your Android NativeScript app.

 

Do NativeScript Plugins Add Weight to My App?

Intro

Something that comes up all the time during app development is the overall app size for the application. Well simple logic, the more you add the larger the app will be. Typically you want your app to remain light weight. In this post I just want to cover plugins and how they will affect your final app size.

I’m assuming you have some familiarity with NativeScript. If not, I encourage you to check it out for mobile app development. It’s in the same boat as React Native and Xamarin, not the same as Cordova based frameworks like PhoneGap or Ionic. At any rate, the NativeScript site can provide much better information about what it is and how it works than I can and it’s outside the scope of this post. So lets dig into a couple plugins and see how they will impact our app size.

We will look at two plugins for NativeScript, one that I built and maintain and another from Nathanael Anderson.

My plugin contains native Android and iOS dependencies, Nathanael’s plugin is just plain javascript and it contains many nice utility methods for accessing UI components in a NativeScript app. So with those two plugins you’re adding something extra to your app so it will simply increase the app size, but exactly how much weight does it add?

Plugin with Native Dependencies

Well there are a few ways to find out but I’m going to show a quick and simple route for both. Lets start with the plugin that is adding native android/iOS dependencies to our application first (color-picker plugin). If you look at the plugin source and find the library listed in the include.gradle located in the platforms/android/ folder here. You’ll find the dependency listed on line 11. You can copy the dependency `com.pavelsikun:vintage-chroma:1.2` and paste it into MethodsCount website and it will give you the stats on the library. Which should give you the following on your screen and tell you approximately how much ‘weight’ will be added to your Android application if you add this plugin (which consumes this native library).

colorpickermethodscount

Now for the iOS side, which is even easier if the library is coming from CocoaPods. This NativeScript plugin uses a library from CocoaPods and you’ll find that listed in the  PodFile here. If you go to the CocoaPods site and search for that library you’ll find it and the information you’re looking for. Here is the page for this library. On the right side bar toward the bottom you’ll find the size of the library. Below is a screenshot.

mscolorpickerpod

That’s it for the native dependencies, now we can look at the plugin that’s just adding some javascript, which in most cases you can expect to be fairly small in added size.

Plugin with javascript only

While we’re on this topic, a good plugin distributed to NPM should only have published the necessary files to NPM. The source files, package.json, and a license file if desired. Images and junk files should not be published to npm and if so, I suggest making a PR to the repo’s .npmignore file so those files aren’t published. This plugin from Nathanael does a good job of not shipping wasted files and the README, LICENSE, and changelog.md files are really small in size so it won’t add much. What I’m most curious about is the actual javascript source file for the code, thanks to GitHub for easily finding that info out for any file. Just open the file on GitHub and in the top you’ll see the file size. Only 11.4 kb.

nsdomgithub

Reducing the Size

There are several ways to reduce the overall footprint of the plugins. You can manually delete files from the node_modules folders that you don’t need. Webpack is another option. If you want a simple hook to delete modules from the build there is a hook plugin for NativeScript from Markosko here.

Notes

Keep in mind there are other ways, you could open your file explorer and find the node_modules folder of your app and see how large the folder is for the plugin, this works only for the plugin itself. If the plugin is adding native libraries compiled into your app, this won’t work the same. You can use Android Studio to find out however, but I’m not going over that here.

Swift Runtime Size

I’ve been told by Nathanael Anderson that if the Pod for iOS uses Swift, it will add 6+ MBs for the Swift runtimes.

Conclusion

This should show you one approach to determine the weight that a plugin could potentially add to your NativeScript application. There are other options to determine the size and several options to reduce the application size. Before going to production you should strongly consider reducing the application size.

AHHH! This NativeScript plugin doesn’t work

Keeping this short and to keep myself from having to repeat these instructions all the time for developers trying to understand the Android and iOS build process and how you need to  download and compile certain things with apps. Mainly since NativeScript is not running a webview and you can’t drop a javascript file and start working with third party libraries without a build step.

Continue reading “AHHH! This NativeScript plugin doesn’t work”