DEV Community: Progress

Testing the new Twitter API v2

Jonathan Pereira — Fri, 21 Aug 2020 16:13:20 +0000

For developers building apps with social interactions, the Twitter API has been one of the most used API. While it was beneficial, it had its limitations. But not for long. Twitter just released the new version of the Twitter API, which has so much to offer.

What's new in Twitter API v2

Twitter seems to have finally answered the prayers of millions of developers using the Twitter API. The new API makes it simpler to listen and analyze the active conversations on the social platform. Twitter has introduced a couple of exciting things, including new endpoints, new tweet payload, conversation identifiers, and even annotations.

Having heard so much about it, we decided to take the Twitter API v2 for a spin. Luckily for us, Fiddler Everywhere can quickly test and debug APIs. SO we decided to test the Twitter API v2 on Fiddler Everywhere.

Fiddler Everywhere to the rescue

For those who haven't used Fiddler Everywhere before, it can capture and inspect network requests, including API calls. It also allows you to modify the request parameters to customize the response as required.

Testing the Twitter API v2

In this blog, we are going to test some of the endpoints of the new Twitter API v2 and see how it works.

Before getting started, make sure that you create a new app using the Twitter Developer Portal and generate the Bearer Token to authenticate the request in Fiddler Everywhere.

Users lookup

The Twitter API v2 makes it simple to get publicly available user information using the users endpoint.

Endpoint URL: https://api.twitter.com/2/users

You can do the following using this endpoint:

/users – Query multiple IDs to retrieve user information
/users/:id – Query the user ID to fetch information about a specific user
/users/by – Query the username to fetch user information

For this example, we'll use the /users/by endpoint.

We open the Composer in Fiddler Everywhere and enter the endpoint in the request bar and set the method to GET.

We need to provide authentication and query parameters. Under the Headers tab, add a new key-value pair called authorization and the Bearer Token as the value.

In the Params tab, add a key-value pair called usernames. You can enter the username or multiple usernames separated by commas in the value field.

Click the Execute button to see the API in action.

If everything were excellent, in the Response section below, you would see the entire response in the JSON tab.

You can modify the response as per your requirement by specifying the user.fields parameters.

I'm going to request the following fields:

Parameter	Description
`name`	Name of the user
`username`	Username on Twitter
`url`	Website URL mentioned in the profile
`profile_image_url`	URL of the user's profile image
`pinned_tweet_id`	Tweet ID of users pinned tweet, if any
`verified`	Boolean response indicating whether or not Twitter has verified the user
`created_at`	Date and time of account creation
`public_metrics`	number of tweets, followers, following, and lists of the user
`location`	Place mentioned in the user account

Once you hit execute, you'll notice the detailed information requested in the JSON tab of the response section.

Tweets lookup

Using the tweets endpoint, we can fetch tweets and information about them using the tweet ID.

Endpoint URL: https://api.twitter.com/2/tweets

We'll open a new request tab in Fiddler Everywhere, enter this API endpoint in the request bar, and set the GET method.

Again, we need to provide authentication and query parameters. You can use the same Bearer Token used in the previous request.

In the Params tab, add a key-value pair called ids. You can enter a tweet ID or multiple tweet IDs separated by commas in the value field.

Click the Execute button to make a call to the API.

You can view the tweets fetched in the JSON tab of the Response section.

We can add additional query parameters to get the required information. I'm going to add the following parameters:
expansions

Parameter	Description
`attachments.media_keys`	Identifies the media attached to the tweet
`author_id`	Returns the user's unique identifier
`entities.mentions.username`	Recognizes the Twitter users mentioned in the tweet
`in_reply_to_user_id`	Provides the user ID of parent tweets author if the tweet is a reply
`referenced_tweets.id`	Identifies the referenced tweet
`referenced_tweets.type`	Identifies if the tweet is a retweet or a reply

text.fields

Parameter	Description
`attachments`	Indicates the attachment types, if any
`conversation_id`	Returns the ID of the original tweet along which includes the thread of all replies
`created_at`	Time of the tweet
`geo`	Location from where the tweet originated, if available
`lang`	Returns the language tag of the language detected
`possibly_sensitive`	Returns a Boolean response indicating if the tweet was marked sensitive
`public_metrics`	Provides the engagement metrics like retweet count and like count
`Source`	Provides the app used for publishing the tweet

If you execute the request again, you will see the requested fields.

Recent Tweets search

The recent endpoint searches and fetches tweets that match the query.

Endpoint URL: https://api.twitter.com/2/tweets/search/recent

Again, We'll open a new request tab in Fiddler Everywhere and enter this API endpoint in the request bar and set the method to GET.

We need to provide authentication and query parameters. You can use the same Bearer Token used in the previous request.

In the Params tab, add a key-value pair called query. You can enter the query in the value field.

Click the Execute button to fetch the response.

You can view the tweets fetched in the JSON tab of the Response section. By default, the endpoint returns ten results from the last seven days. You can use the max_results parameter to indicate the required number of results.

You can use the same query parameters from above to modify the request as required.

This is the response that I received.

These were some of the basic operations that you can perform using the new Twitter API v2. Next time, we'll dive into how Twitter has improved the API using NLP to understand and analyze tweets and how you can implement it using the API.

Fiddler Everywhere makes debugging fun

If you are wondering what else you could do with Fiddler Everywhere, the tool comes in handy to inspect, debug, mock, and share network requests and responses. You can download and try it out yourself. Fiddler Everywhere is available on macOS, Linux, and Windows systems and supports all modern browsers and processes.

How Fiddler Everywhere makes web debugging simpler

Jonathan Pereira — Tue, 18 Aug 2020 10:16:31 +0000

As developers – whether new or experienced, we are always afraid of bugs. These could appear in the form of unexpected results or errors in our websites and apps. Problems like these are where tools like Fiddler Everywhere have been saving time and effort. In this post, we’re going to explore some situations where Fiddler Everywhere makes debugging simpler for developers.

Fiddler Everywhere is the next generation cross-platform network debugging proxy tool, which just came out of beta recently. The tool is trusted by developers for over a decade and is used to inspect and debug HTTP(S) traffic requests between your computer and the internet. If you haven’t tried it yet, download it now.

Identify errors

Fiddler Everywhere inspects every request made to the server as well as the response received. As the requests come in, they are logged by Fiddler Everywhere. The request log provides you a perspective of the activity going on in the background when the browser calls your website.

If at any point, you receive an unexpected response or an error, Fiddler Everywhere can promptly point out the cause. The issue could be something as simple as a wrongly entered file name in the code. While it could be a daunting task to pinpoint the file causing the error, Fiddler Everywhere would throw a 4XX error, which then can be easily debugged.

For example, a 404 error would indicate that the file name does not match the available files on the server, or the file doesn’t exist. Once identified, it is much simpler to rectify the error.

Mock user conditions

Fiddler Everywhere allows you to simulate situations faced by your user. For example, your user might be working on a slower internet connection or entirely offline. Fiddler Everywhere enables you to create rules that add a delay while loading the website to replicate the network latency. The same can applies to check drop requests.

Fiddler Everywhere also tracks the response size and time taken to be transmitted. This data can be of use to highlight files that are heavy and take longer to load.

Additionally, using the Fiddler Everywhere Auto Responder you can create mocking rules for your API. This ability is especially useful when you want to test your app without the live APIs or are behind a firewall.

Test APIs

The Fiddler Everywhere Composer can be used to quickly test API requests and make sure that the server responds as expected. For example, if the API fails to return a response or doesn’t provide the expected response, you can open the request in the composer, modify the headers, and execute it to test the request.

If everything is working fine, you should get a 2XX status, else a 4XX error if there is an issue with the HTTP request or a 5XX error if there is an issue with the server. You can identify several common problems like unauthenticated requests, invalid requests, internal server errors, and service overload.

Alternatively, you can use the Fiddler Everywhere Composer to test new APIs or the API user interface.

Saving sessions

Fiddler Everywhere takes the pain out of repeatedly working with web requests. Fiddler Everywhere has intuitive features that help you streamline the debugging process. The filters across every category allow us to inspect limited traffic from a particular domain, a selected browser, or even a specific file type and status code. You can add multiple filters as required.

Additionally, you can select individual sessions or multiple sessions. You can then save them and open them in a separate tab. Fiddler Everywhere also allows you to put notes and comments on your saved sessions. This feature is useful when you want to share the requests with your teammates, who can then continue from where you left.

Try out Fiddler Everywhere

These are some of the ways that Fiddler Everywhere is known to simplify the web debugging process. Let us know the ones that you use in the comments below.

If you are new to Fiddler Everywhere, check out the video below to help you get started quickly.

Happy debugging!

Getting Started with Fiddler Everywhere

Jonathan Pereira — Thu, 13 Aug 2020 16:02:32 +0000

What is Fiddler Everywhere?

Fiddler Everywhere is a valuable tool for web debugging and monitoring. It logs all the HTTP(S) traffic between the client and the internet. The tool is handy to inspect, debug, mock, and share network requests and responses.

Along with the primary use of acting as a web debugging proxy, Fiddler Everywhere has capabilities that make it an excellent tool for API development, performance testing, security testing, and even malware analysis.

Fiddler Everywhere just got out of beta and is available on Windows, macOS, and Linux and supports every browser. Additionally, it can also be made to behave as a reverse proxy, thereby allowing you to inspect traffic between mobile devices and the internet.

Get Fiddler Everywhere

Head over to the Fiddler Everywhere site to download it.

Fiddler Everywhere is available for Windows, macOS, and Linux. Choose the required platform and download and install the setup file.

Getting Started

Once you open Fiddler Everywhere, you need to create an account. Enter the required details and click on Create New Account. Alternatively, you can sign-in using your Google account.

The first thing you want to do, once you install Fiddler Everywhere is to check and enable the HTTPS traffic capture. Doing this allows you to inspect and debug web traffic, which is transmitted using the HTTPS protocol, which is quickly becoming the default standard for web development.

To do this, click on the gear icon on the top right corner. The Setting pop-up will show. In the HTTP(S) menu, click on the Trust root certificate button. Your system will request your system login credentials. After you enter and authenticate yourself, Fiddler Everywhere will automatically complete the process. Make sure to click on the checkbox next to Capture HTTPS traffic.

If you face issues with the root certificate, you can try importing and trusting it manually.

Navigating Fiddler Everywhere

You are now inside Fiddler Everywhere. You can see the default view divided into two major sections – the column on the left displays the web sessions and the column on the right have the Traffic Inspector. The sidebar displays the saved sessions and requests.

Before you start recording the traffic, you need to make sure that you turn on the toggle in the Live Traffic tab. The tab will display (Capturing) if it is working fine. You can click the toggle again to pause the recording. The tab will display (Paused) when it is not capturing.

Live Traffic

Now you can open any browser and enter the URL you want to inspect. As soon as you hit enter in the browser, you will see the web sessions getting displayed in Fiddler Everywhere.

The tool provides many insights regarding each session at a glance. For example, you can see the filetype denoted next to the request number. You can see the status code of the request and the protocol used. The host server and the URL slug of the request are also displayed. You can also see information about the request method, response size, content type, and caching. Interestingly, the process from where the request originated is also displayed – for example, browser, desktop app, etc.

To make things simpler, you can click on the ellipsis in the menu bar and set filters for each tab and view only the required sessions.

You can right-click any session and save, remove, comment, and mark the session. Additionally, you can also share the session with others by just entering the email address.

Traffic Inspectors

If you want to scrutinize an individual request, you can select the request by clicking on it and see the details in the Inspectors tab on the right. The Inspectors tab displays two panes – the top pane shows the information on the request, and the bottom pane highlights the response.

In the request pane, you can see all the headers which contain the information sent to the servers like the host name, user-agent, encoding status, and even the cookies. You can view the form data and cookie data, or you can check the text, JSON, and XML used in the request, if any.

In the response pane, you can view the response headers received from the server, including the status code, access controls, and even the content length. The body of the response is available as text, JSON, or XML. If the response is an image, it is available in the image tab. Interestingly, the entire response is available as a live web page in the web tab.

Auto Responder

The Auto Responder feature is one of the most loved features of Fiddler Everywhere. You can find this feature in the tab next to the Inspectors. The feature allows the developer to mock responses, without actually transmitting the request to a live server.

You can create a new rule with a match condition and an action to be performed. The term can be a host name, or the URL, or even the file type. If you want to target an URL specifically, you can also set the condition to require an exact match.

The corresponding action which needs to be executed, in the event of a match, has to be provided. This action could be another URL or a filename or a redirect request. This feature can also help set breakpoints, delay (to imitate network latency), rest the connection, and even close the connection altogether.

Composer

The composer feature — next to the “Web Sessions” tab — allows you to modify and send requests to the server. Additionally, you can create your requests and execute it with Fiddler Everywhere.

To modify an existing request, you can right-click on the request in the “Web Sessions” tab and select the Composer option. The request will automatically get loaded in the Composer tab. Similarly, you can create a new request in the Composer tab directly.

In the Composer tab, you need to select the appropriate HTTP method, enter the request URL, the headers, and the request body. You can click on Execute to send the request to the server or click on Save to save it. Fiddler Everywhere supports all the available HTTP request methods.

Start debugging

Now that you know about Fiddler Everywhere, it is time to put the tool to the test and see how it mystically makes debugging simpler. Head over to the Fiddler Everywhere documentation to get more information about the features. If, at any point, you feel stuck or are faced with an issue, feel free to reach out to the live Fiddler Everywhere community.

From Fiddler Classic to Fiddler Everywhere

Rob Lauer — Thu, 30 Apr 2020 19:13:37 +0000

In the more than 15 years of Fiddler's history, it's become one of the most popular Telerik products. Fiddler has also become a victim of its own success, as it has A LOT of distinct features for A LOT of different types of users!

Long-time users of Fiddler are ok with this, should we say, "cluttered" UI. They know where their features are and how to use them. And you know what, Fiddler is popular because what it does, it does very well.

There are some things that Fiddler "Classic" (what we term the current Windows-only version of Fiddler) doesn't do well though. It's not especially inviting to new users due to the aforementioned complicated UI. It also isn't easily accessible to the growing base of web and desktop developers on macOS and Linux.

Fiddler Everywhere FTW

It's primarily out of these concerns that Fiddler Everywhere was born. Fiddler Everywhere is a more focused implementation of Fiddler that provides access to the most-adored features of Fiddler Classic. And it works across all platforms equally well: macOS, Linux, and Windows.

Suffice it to say, Fiddler Classic isn't going anywhere. You know it, you love it, and we will continue to support it.

Those of you who have been using Fiddler for a long time might be curious about exactly which features are migrating to Fiddler Everywhere, where they are, and how you use them.

Traffic Inspector

One of the primary uses of Fiddler is to inspect HTTP/HTTPS traffic to and from browsers and desktop apps. This is a critically important feature for Fiddler users, so it was a no-brainer feature to add to Fiddler Everywhere.

Inspector in Fiddler Classic

Fiddler (both Classic and Everywhere) can log all traffic between your device and any remote endpoint. Any application on your computer that supports a system network proxy (all modern browsers and likely any desktop app you are developing) can have its network traffic monitored and debugged.

Fiddler Classic allows you to dive into the details of any specific network request, including:

Headers
TextView
SyntaxView
WebForms
HexView
Auth
Cookies
Raw
JSON
XML

Inspector in Fiddler Everywhere

Likewise, Fiddler Everywhere provides access to a similar set of details:

Headers
Text
Web Forms
Cookies
Raw
JSON
XML

API Composer

Modern apps are oftentimes powered by separate remote APIs. Tools such as Postman are widely used to help test and debug these remote API endpoints.

Fiddler Classic provides an API composer, similar to what can be accomplished with Postman:

API Composer in Fiddler Classic

With Fiddler Everywhere, we've seen how critical this piece of functionality is in your debugging workflow. So not only have we included this feature from Fiddler Classic, but we have improved upon it:

API Composer in Fiddler Everywhere

With Fiddler Everywhere, you can edit headers and add parameters to your requests. For instance, if you want to hard code in your authorization test key, you can now do so!

Auto Responder

One of the most useful features of Fiddler (in this writer's humble opinion) is the Auto Responder. Using Auto Responder, you can set up rules to alter specific requests and test out a myriad of debugging scenarios. You can use local file assets instead of transmitting requests to the server and answer questions like:

What happens if my CDN goes down?
Does my app break if the remote API returns a 500 error?
If images aren't served properly from the server, does it completely bonk the layout of my app?
What about if there is significant latency with my remote APIs?

Auto Responder in Fiddler Classic

Auto Responder is back (with a vengeance) in Fiddler Everywhere! Not only can you construct your rules in a more elegant and intuitive manner, but you can also stack and re-order rules to provide a fully customized means of responding to complicated requests.

Auto Responder in Fiddler Everywhere

But [Insert Feature Name] is Missing!?!

Clearly Fiddler Classic is chock-full of features it has accumulated over its 15 year lifespan:

And not all of them are in Fiddler Everywhere, nor will all of them ever be in Fiddler Everywhere. Does this mean you should stop using Fiddler Classic? No! In fact, you can use the two tools in parallel if you need to, especially as Fiddler Everywhere features ramp-up.

Try Fiddler Everywhere Today

There is quite literally no reason to wait! Especially if you are already on macOS or Linux, download Fiddler Everywhere today and take a spin through the features available. Over the forthcoming weeks and months you will start to seeing more significant improvements in the usability and feature set of Fiddler Everywhere.

Happy debugging! 🐛

Fiddler Everywhere is Getting a New Look

Rob Lauer — Fri, 17 Apr 2020 13:49:11 +0000

Fiddler: you know it, you love it. Some of you have even been using it for 15+ years! This venerable network debugging tool for desktop and web apps remains one of the most popular products in the Telerik portfolio for good reason: it just works.

But one of the top feature requests we have repeatedly received is to provide a compatible version for macOS and Linux. And that's precisely where Fiddler Everywhere comes in!

Join our webinar on Thursday, April 28th as we dive into the new features of Fiddler Everywhere.

Fiddler Everywhere is the next generation of Fiddler. It was built from the ground-up to work in a cross-platform manner for macOS, Linux, and yes of course, Windows. We've taken the most-used and most-loved features from the original Fiddler (which you may see called "Fiddler Classic"), are applying some additional polish, and actively making them available in Fiddler Everywhere.

In the coming weeks and months you're going to see a lot of activity from the Fiddler team in relation to Fiddler Everywhere. We have some exciting plans in place for feature additions, expansions, and improvements. Today though, I'd like to specifically call out the new user experience.

You can download the latest beta of Fiddler Everywhere right here. And before you ask, nope, the original Fiddler isn't going anywhere!

The NEW Fiddler Everywhere UI

The Fiddler team is working on moving from the relatively antiquated Fiddler Everywhere UI we have today (for example):

...to a much more engaging and intuitive experience!

New UX == New Features

Along with a new UX comes a variety of new and improved features as well. For instance, to make it easier for you to manage multiple concurrent sessions and tasks, we are introducing a tabbed interface. 📑

Improved filtering options will make it easier for you to see only the requests you want, when you want them. 🔽

You can view a history of your saved sessions and request history, and easily access them. 📜

And the Auto Responder feature is getting some major improvements in its UX and functionality, allowing you to more easily debug a variety of network scenarios with your web and desktop apps.

Need to test what happens when your CDN goes down? Want to swap in some local assets in place of remote files to see how your production site reacts? Auto Responder to the rescue! ⛑️

We even have a brand new collaboration feature coming out, but you'll have to attend our webinar to find out more. 🤫

Try Fiddler Everywhere

We welcome you to download Fiddler Everywhere for free today and get a head start on some of these features.

Please note that depending on when you are reading this, the new UI we just covered may or may not be implemented, but with the auto-updating feature in place rest assured you'll get it as soon as it's available.

Tips for Updating NativeScript Apps on App Store and Google Play

Rob Lauer — Thu, 26 Sep 2019 18:24:06 +0000

So the time has come, once again, to make some updates to my fun little beer app I affectionately call "Hoppy".

Shameless promo: You can find the app on the iOS App Store and Google Play. It's 100% free, you just need a 100% free Untappd account to use it! Oh, it's also fully open source.

Now, those of you familiar with the app store submission processes know that you tend to have to completely re-learn the steps nearly every time you submit an update (especially on the iOS side 🤬).

Well, I'm here to provide you NativeScript developers some shortcuts and save you some hair-pulling when publishing your app updates to the public app stores.

But let's start with the easiest way to update your app: avoiding the app store submission process entirely! 🤯

NativeScript AppSync

Should you discover an error or minor issue with your app in production, the normal solution to this is to generate a new build of your app and wait the hours (Google Play) or days (iOS App Store) to see your fix go live. Plus you then have to hope and pray that your users are set to automatically install app updates, lest you wait in vain for them to manually install them.

What if you could push an update to your app immediately, avoiding the app stores entirely? This is the basic concept behind NativeScript AppSync.

If you've heard of CodePush from Microsoft, you're on the right track. NativeScript AppSync is based on that very same code!

AppSync is a NativeScript plugin (available on the NativeScript Marketplace) and is completely free to install and use:

tns plugin add nativescript-app-sync

With the plugin installed, you just need to call the AppSync.sync() method in your app's app.js or main.ts file:

import { AppSync } from "nativescript-app-sync";

AppSync.sync({
  deploymentKey: "..."
});

There's a little more to it than that, so be sure to check out TJ VanToll's excellent blog post about NativeScript AppSync for the full story.

Ok, back to the traditional way of updating our apps. 😭

Updating Your App on Google Play

Google makes app store submission relatively easy. To create a new version, you'll need to start on the Google Play Console.

Pick your app, go to Release management --> App releases --> Manage in the Production Track tile.

From here, you simply Create Release, add some release notes, and upload your build.

Create Your Build for Android

My go-to way to create a release build for Android is the following NativeScript CLI command:

tns build android --release --env.snapshot --key-store-path [path to your key store] --key-store-password [key store password] --key-store-alias [key store alias] --key-store-alias-password [key store alias password] --aab --copy-to [path to where you want the aab file created]

There's a lot to unpack in that one command, but you can find all the details of the build command in this doc article.

NOTE: Due to Google requiring 64-bit builds of your app, I also had to alter my app.gradle file and replace the android section with this:

android {
  defaultConfig {
    generatedDensities = []
    ndk {
      abiFilters.clear()
      abiFilters.addAll(['armeabi-v7a','arm64-v8a'])
    }
  }    
  buildTypes {
    debug {
      ndk {
        abiFilters 'x86'
      }
    }
  }
  aaptOptions {
    additionalParameters "--no-version-vectors"
  }
}

YMMV though, as this should be fixed with an upcoming version of NativeScript!

With your .aab file created, you will simply upload it via the Google Play Console and you should be good to go.

Updating Your App on iOS App Store

Oh Apple. I love/hate you so much. You make me spend way too much time in Xcode just to create a release build of my app. Sigh.

Regardless, here are my quick tips for app store glory:

Xcode seems to have a hard time (sometimes) picking the correct certificate and provisioning profile for my app builds. By default, the provisioning profile is "automatically" chosen. However, I've always had to turn this setting off and instead manually pick the distribution profile I wanted to use for a release build:

If you're having trouble locating the .xcodeproj file for your app to open in Xcode, check the /appname/platforms/ios directory!

Next, I create a release build of my app with the NativeScript CLI:

tns build ios --release --for-device --provision [provisioning profile id]

Hmmm...so what is this "provisioning profile id"? I've always found it best to explicitly define which provisioning profile I want to use. YMMV of course, but this seems to be the safest way to create a problem-free build.

"How do you get the provisioning profile id" you ask? Open the provisioning profile file you downloaded from Apple in your text editor of choice, and scroll down to the UUID key. Therein lies the id:

<key>UUID</key>
<string>aaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee</string>

With your build created, you'll find the .ipa file at /appname/platforms/ios/build/Release-iphoneos/appname.ipa.

Head over to Apple's App Store Connect site and create a new version of your app:

Now you'll need to somehow upload this newly-created build. You'd think Apple would just let you upload your build through the website. But no!

To upload an app build, we've traditionally had to use a utility called Application Loader. This tool is no longer available in Xcode though, and, to be completely frank, I was not able to get my app build uploaded using the process in Xcode 11 🤷. So I went the CLI route:

xcrun altool --upload-app --type ios --file [path to ipa] --username [apple id username] --password [app-specific password]

Using this command will use the Xcode CLI tools to upload and verify your app.

What's this "app-specific password" thing? Since Apple now requires two-factor auth by default, you'll have to head to Apple ID Account Management and create an app-specific password for this step. It's actually quite easy:

When this is done, you should get a couple of emails from Apple notifying you about the status of your build. When you get the all-clear, head back into your developer console and select the new build as part of this new version!

I Feel Your Pain

Yep, app store approval processes can be a huge drag, no doubt. BUT, you can make your life easier in the future by giving NativeScript AppSync a try! 🤩

My Top 5 Tech Speaking Tips

TJ VanToll — Wed, 21 Aug 2019 18:44:41 +0000

This article is an eclectic set of speaking tips I’ve learned from giving dozens of tech talks at conferences around the world. I hope these tips help new speakers prepare their first talk, and help give experienced speakers ideas to potentially improve.

One thing I’ll note though: these are tips that I’ve found work for me, which doesn’t necessarily mean they’ll work for you. Each speaker needs to find their own style and workflow, so try to take inspiration from these tips and don’t interpret them as hard and fast rules.

With that disclaimer out of the way, on to the tips!

Tip #1: Don’t worry about slide design
Tip #2: Make an outline
Tip #3: During slide creation, make your intro slides last
Tip #4: Make the audience do stuff
Tip #5: Speak—a lot

Tip #1: Don’t worry about slide design

I’ve never cared about slide design and you probably shouldn’t either.

I offer this as a tip because I find that new speakers spend a lot of time trying to find a good color scheme or font for their slides. Or get confused about whether to use PowerPoint, or Keynote, or something web-based.

You don’t want this sort of thing to get in your way. Start with a tool you like (for me that’s PowerPoint because it’s simple), pick the blank slide template, and get started.

Just to give you an idea, I typically have three types of slides that I use.

Design #1: Plain text

I use simple slides with just text on them a whole lot. For colors I use black text on a white background for readability, and I use the Avenir font—but only because that was the font on some slide deck I started with years ago. It looks nice to me though.

Design #2: Screenshots

For a lot of my slides I just take a screenshot of something and then just toss it on a slide. It works.

Design #3: Bullets

I use bulleted slides when I need to present a list, and I just use the default PowerPoint design for this.

I do occasionally mix things up, but that’s the approach I take on 95% of the slides I make. And for most cases that’s all you’ll need as well.

Unless you’re an actual designer and want to spend the time to create something really unique, I’d encourage you just to pick the blank slide deck in your tool of choice and call it good enough.

My second tip deals with what to do next.

Tip #2: Make an outline

I make an outline for every talk I give. The outline is dead simple, and includes only three things: the talk’s main audience takeaway, 3–4 topics that help support that takeaway, and an actionable next step.

When written out that structure looks something like this.

State the takeaway, aka what I want the audience to get out of the talk.
Topic #1
Topic #2
Topic #3
Topic #4 if necessary
Restate the takeaway again
Give an actionable next step

For example, below is the outline I had for a Is Augmented Reality the Future? talk I recently gave in Montreal.

Takeaway: AR (Augmented Reality) is cool, but still pretty hard for your average developer.
Topic #1: History of AR
Topic #2: AR today
Topic #3: Building AR apps
Restate the takeaway
Provide my preferred place to get started building AR apps.

Once I have this outline I start including the outline in my slide deck directly. Specifically, I create a slide called “Agenda” that looks something like this.

This act of creating an outline helps you organize the talk in your head, and placing that outline in slides helps you visually see your progress creating content for each topic. Audiences like structure as well, as it helps them know what to expect from your talk, and therefore makes it easier for them to follow along.

To make it even easier for the audience, I always include the same agenda slide in my deck when I transition between topics. For example, after I complete the “Brief history of AR” topic I show the slide below.

These slides give me a logical place to summarize the previous topic and segue to the next.

Next, I create a slide that summarizes the key takeaways of my talk at the beginning and end of my talk. Here’s what that slide looked like for my AR talk.

When I show this slide at the beginning of my talk I say something like, “This is what I plan to prove/show you today”, and at the end I restate the points, and usually talk about how the topics I presented support those points.

Once you have this basic outline in place you’re ready to start developing your introduction and your main content.

Tip #3: During slide creation, make your intro slides last

When creating slides most people start with the introduction, because, well, it’s the first thing you actually present. The problem is that creating compelling introductions can be hard, even for experienced speakers.

And because of this, it’s really easy to waste a lot of time searching for the perfect way to introduce your topic, when in reality it’s fairly insignificant.

Your introduction can be as simple as stating the following points, especially when you’re just getting started.

I’m <your name>.
State topic
State audience takewaways
Show agenda
Start talking about topic 1.

By saving the introduction until the end you’ll have a better idea of what you might want to say to start your talk with. You can also rest assured that the bulk of your work is done.

All that being said, I don’t mean to imply introductions aren’t worth spending any time on, because done well they can be way to engage the audience and draw them into your talk. I would just save them for last.

When you do create an introduction you need to experiment a bit and find what works for you. My go-to introduction is to telling a story that relates to my topic or the place I’m speaking. For example, to open my AR talk I told a story about my love for Pokémon GO, and how that’s what got me interested in AR in the first place.

I was lucky enough to give a talk in Denmark last year, and I opened with a slide with pictures of me around the area for fun.

If you have an idea for a story to tell I’d encourage you to take it and run with it. Deliver the story with confidence and have fun.

But if you don’t have an idea don’t worry either. Save the intro for the end, and if you can’t think of anything, stick with the basics and get into the meat of your talk right away.

And when you’re delivering the bulk of your content I have a tip for that as well.

Tip #4: Make the audience do stuff

Walk into a room halfway through a random tech talk and you’ll likely see at least half the attendees looking at their phones or laptops.

The thing is, it’s hard to keep people’s attention on anything, and tech topics aren’t the world’s most engaging material. As a speaker there are a few things you can do to help keep your audience’s attention.

The simplest thing you can do is poll your audience at given points in your talks. I often do this before I introduce a new topic. For example, in a talk I recently gave called One Project. One Language. Three Apps. I used the slide below to introduce two frameworks, NativeScript and React Native.

Before I introduced each framework I asked the audience, “How many people here are familiar with React Native”, and then, “How many people here are familiar with NativeScript”.

These simple questions accomplish two things. First, it forces the audience to look up and engage with the talk, if only for a minute. Second, it helps me get a read on the room. If I see 5% of hands go up I know I need to give a thorough introduction, whereas if every hand goes up, I know a short explanation will suffice.

Polling the audience is the easiest way to engage the audience, but there are a variety of more creative ways you can accomplish the same goal.

For example my significant other gives talks on CSS, and one fun thing she does is include mini quizzes in her slides, like the one below.

This again solves multiple goals. First, it forces the audience to not only pay attention, but to also really try to understand the content to get the correct answer. (It’s 600px, by the way.)

Second, it gives the presenter a good sense of whether the audience is following along with the content. If you see a lot of hands going up and a lot of correct answers you know people are understanding your material.

There are professional tools out there to make this sort of audience quizzing even more engaging. For example the service Kahoot! makes it easy to configure quizzes that an audience can easily complete on their laptops and smartphones.

Overall, the specific tool or approach doesn’t really matter. What does matter is finding some way to break up the inherent monotony of a tech talk by engaging the audience.

Tip #5: Speak—a lot

The phrase practice makes perfect applies more to public speaking than any other life skill. No amount of practicing in front of a mirror will prepare you for the experience of delivering a talk in front of a live audience, and the only best way to improve is continue to do just that—deliver talks, repeatedly.

This doesn’t mean you have to constantly give talks at conferences around the world though. Occasionally giving a presentation at a local user group, or for a few coworkers at work, will help you learn how to be in front of an audience and deliver your material effectively.

As you get more comfortable speaking you’ll want to work on how to improve the quality of your talks. And for that I have two recommendations.

Watch yourself on video

Most people would choose elective surgery over watching a video of themselves presenting—myself included. But it’s extremely important, as you’ll learn things about your talks you can only see from a third-person perspective.

Personally I started as a heavy “um” user, which I had no idea about until I saw myself on video. Later, I developed a habit of using my hands... a lot. It was awkward. But knowing these tendencies helps me consciously think about avoiding these habits, and ultimately helps me stop repeating them in the future.

It’s important. Get a friend to record you and watch the video. You’ll hate it, but it’s worth it. Promise.

Find a trusted friend for feedback

In addition to watching yourself speak, it’s good to get feedback from others as well. However here you have to be extremely careful for two reasons.

Reason #1: Some people are horrible, and will leave negative feedback on your talk for silly reasons, like not liking the framework you’re using (seriously).

And even if you know the feedback is unreasonable, the human brain has an unfortunate tendency to fixate on the negative, even if you get an onslaught of positive feedback to go with it.

And I can say this from many personal experiences. Remember the talk I mentioned earlier that I gave in Denmark? It’s the most well received talk I’ve ever given. I’ve had random people at conferences compliment me on it; it’s shown up in all sorts of positive tweets, and has gotten numerous mentions in popular newsletters and such.

This was great, until I made the classic mistake of reading the negative comments on the YouTube recording, which if I’m honest, has ruined a lot of the positive experience I had from preparing and delivering that talk.

Overall, be careful asking for feedback broadly because the human brain has the not-at-all-useful tendency to heavily focus on the negative.

Reason #2: Most people won’t be honest. If you deliver a talk to a group of friends or coworkers and ask for feedback, the vast majority of people will reply with something like “It was good.” or “I liked it.”.

Although this is supportive, it’s also good to get honest feedback on how you can improve. For this you need to find that blunt person in your life that’s not afraid to tell you like it is, and will call you out on things you can improve on.

The big difference between asking a friend and random people is a friend can provide context and details on things you need to work on. There’s a big difference between “That talk sucked” and “I had trouble following along in the middle part of the talk. I think you could have explained the concepts better or maybe used more examples to prove your points.”

You can also ask questions of your friend, like “did you understand the first topic?”, or “did I use my hands too much?”.

If you’re having trouble finding that blunt person in your life try being blunt yourself. I find that people that give generic “it was good” feedback find much more to say if you press them.

Final tip: Just do it!

Ok that’s it for now. I have a lot to say because speaking has been very important to me over the last 6–7 years of my life, and it’s opened up a ton of opportunities that I wouldn’t have had otherwise.

Hopefully you found these tips helpful. If so let me know, because I could easily come up with 5 more 😉

TIP: If you want to see me speak in person I’ll be at DevReach in Sofia, Bulgaria in October, and at at jsMobileConf in Boston in November. Both are great events.

Why ‘Sign in with Apple’ is Actually Pretty Great

TJ VanToll — Tue, 02 Jul 2019 16:29:41 +0000

I believe that Apple’s recently announced ‘Sign in with Apple’ workflow is an important step for improving the security and usability of login screens.

In this article I’ll explain what ‘Sign in with Apple’ is, why I believe it’s a great thing for users, the drama around Apple’s implementation, and some of the lingering concerns I have.

The crux of my argument is that Apple’s new workflow provides badly needed innovation for a process everyone hates—logging in. Even if Apple’s implementation is flawed (which we’ll get to), hopefully this effort will spur other ideas from other tech giants in response, ideally making the login process better for everyone. To show what I’m talking about let’s start with a bit of background.

Why passwords are the worst

A 2018 survey done by LastPass showed that 59% of people always or mostly use the same password—everywhere. The same study found that 45% of people don’t bother changing their password when their accounts get hacked, and that 42% of people keep passwords in a file, like, a Word doc or Excel spreadsheet.

As I write this article, the top-selling book in Amazon’s “Internet & Telecommunications” category is the internet address & password logbook. Sixth place in the same category is the INTERNET PASSWORD LOGBOOK, which honestly has a nicer design than the top seller.

We have failed. Failed hard.

As easy as it is to mock books like this, it’s important to remember that these books are solving a real problem. Using unique passwords is important, but remembering multiple passwords in your head is impossible, and not everyone has the money and tech savviness to use a password manager.

Funnily enough, you can make a compelling argument that physical-password-book users are more secure than password reusers, assuming the physical-password-book users create unique passwords for each service they use.

Regardless, the sheer existence of these books is indicative of just how broken the login process is for most users today.

Making login better

Everyone knows the current way we log in is not ideal, and plenty of tech companies have tried to make this process better. One big improvement to login screen usability was the advent of Single Sign-On, wherein the user uses a single account to authenticate with multiple apps or services.

An example of Single Sign-On in an iOS app. The user can use Google or Facebook to authenticate.

The main appeal of SSO is that users don’t have to create and remember a new set of credentials, allowing them to maintain a one-password lifestyle, without the normal downsides of password reuse.

However, despite its appeal, SSO has its drawbacks as well. Specifically, most SSO providers require that you provide your email address (and sometimes other information as well) to the service you’re authenticating with.

While providing an email address seems innocuous, shady services will often sell lists of email addresses to advertisers or spammers, greatly increasing the spam mail you have to deal with. Far worse, even if a service has no malicious intentions, data breaches can expose your email to hackers worldwide, opening up the possibility of attacks on accounts you’ve created around the Web with that same email.

Enter Apple

With this backdrop in mind, earlier this month Apple announced a new ‘Sign in with Apple’ feature that, at first glance, works very similarly to the SSO mechanisms from Google, Facebook, and others that thousands of apps use today.

However, Apple’s new authentication workflow offers one innovative twist: when you sign in with Apple, you get to choose whether you want to share your email with the service you’re signing up for, or, whether to hide it from that service.

An example of ‘Sign in with Apple’ in action in a sample app.

If you choose to hide your email, Apple will create a randomly generated Apple-hosted email address, which will receive all messages on your behalf, and forward them to your legitimate email address.

This workflow alleviates many of the privacy concerns associated with similar SSO solutions from companies like Google and Facebook. If a shady service sells your email to an advertiser, you’ll be able to easily turn off email forwarding to stop the unwanted spam. Even better, if your generated email address gets exposed in a data breach, you can rest assured, as your Apple-generated email address is unique, therefore hackers will be unable to use that address in subsequent attacks.

It’s an elegant solution to a common problem; a solution that the likes of Google and Facebook might be hesitant to replicate, because each are companies that earn the bulk of their revenue from advertisers—advertisers that very much like to track users by their email address around the Web. Because Apple does not rely on a similar revenue model, they’re uniquely positioned to innovate and offer users a privacy-focused authentication option. That being said, Apple is not without its own motives.

The drama

Apple has a vested interest in being seen as a privacy-focused company, therefore, for them, creating and promoting the ‘Sign in with Apple’ workflow makes a lot of sense.

More interesting is the news that broke shortly after WWDC, when developers found documentation that stated Apple will require apps that support third-party logins to provide a way to sign in with Apple. Here’s the exact wording from Apple’s site.

“Sign In with Apple will be available for beta testing this summer. It will be required as an option for users in apps that support third-party sign-in when it is commercially available later this year.”

This controversial decision immediately sparked a heated debate in the tech world. Those against Apple’s decision argued that Apple is using their monopolistic control over the iOS platform to advance their own SSO solution.

Leveraging their position as gated community guard to push their own single sign on product? Yeah, thats going to get looked at by the EU at the very least. Doesn't matter if its an additional option or not, the fact that its required is enough...
— Richard Price (@richardprice) June 3, 2019

woah. It is "walled garden" moves like this that make me glad I write web apps.
— Jared Beck (@jaredowenbeck) June 3, 2019

Monopolist gonna monopolist
— Caitlin Fitzharris (@caitlintackles) June 5, 2019

The timing is indeed interesting, as Apple is actively being sued by developers and consumers for its App Store policies. You might think the company would avoid potentially monopolistic moves while other parts of iOS have active anti-trust lawsuits pending—but apparently Apple isn’t worried, or they don’t believe their actions here are monopolistic.

On the other side of the argument, those in favor of Apple’s decision to require ‘Sign in with Apple’ argue that Apple has to require their new workflow for apps to actually use the feature.

The problem "Sign In With Apple" is that it's so delightfully privacy-safe that developers won't offer it. They crave your real email address for reengagement campaigns. Fb happily provides it.
— Josh Constine (@JoshConstine) June 3, 2019

Seems like it'd have to be. Otherwise it'd share the same fate as all that BrowserID, OpenID kinda stuff. I think apps often support SSO because they want the data that comes with it. Most were never interested in supporting an option that didn't come with the data.
— Moxie Marlinspike (@moxie) June 4, 2019

This side of the argument is compelling. For better or worse, there’s very little incentive for individual apps to implement privacy-focused features for users, so it stands to reason that most would just ignore Apple’s new API if they could.

Remember BrowserID? It was a feature championed by Mozilla to provide SSO across the web using your email address. It was a great idea, and had some real benefits for users, but it never took off because very few developers actually integrated it.

If you’re an app maker, why would you implement BrowserID or ‘Sign in with Apple’ when you have a roadmap full of backlogged tasks? Moreover, the Apple-based workflow aims to prevent your service from gathering user data—data that all marketing and sales departments will have a hard time giving up unless forced.

So although ‘Sign in with Apple’ isn’t perfect, and although it’s concerning to give Apple even more control over iOS users, at least the mandate will force all apps that use third-party logins to seriously reassess how they handle their user’s data.

The broader point

More broadly speaking, my hope is that Apple’s push here will lead to further advancements into the password management world. It’s 2019 and most people are buying password managers, buying books to write down their passwords, or just giving up and logging in with their cat’s name across the Web. I think we have every right to demand more of the tech giants to help fix this.

For example, both Google and Facebook claim to care about their users’ privacy, and both have the resources to create similar systems, so why shouldn’t we demand they provide a way to authenticate into third-party apps with similar privacy protections? Better yet, what if a tech company reimagined a BrowserID-like solution that avoids one company having total control?

There’s no easy win here, but hopefully Apple’s assertive move will spark innovations that move user security and privacy forward.

At Progress we already have you covered to work with Apple’s new APIs. NativeScript users can start experimenting with ‘Sign in with Apple’ today with the new nativescript-apple-sign-in plugin.

And because ‘Sign in with Apple’ is based on OAuth 2.0, Kinvey users will be able to work with Apple’s new workflow with Kinvey’s Mobile Identity Connect later this fall.

What the Apple Supreme Court Decision Means for Developers

TJ VanToll — Thu, 16 May 2019 13:14:08 +0000

Earlier this week the US Supreme Court allowed an antitrust lawsuit against Apple to proceed. If you’re like me this decision sounded super important... but also super confusing.

To try to clear things up, in this article, we’ll break down what this ruling means for your average developer, the ruling’s effect on the iOS ecosystem, and the ruling’s implications on the future of mobile development.

What does the ruling mean?

Let’s start with a little background. If you develop an app for the iOS platform, the only way to get that app to users is through the iOS App Store, and Apple takes a 30% cut of all transactions that occur there. That cut ends up being incredibly lucrative for Apple, as App Store revenues were a staggering 46.6 billion dollars in 2018.

This court case calls Apple’s app-distribution model into question. Specifically, the case’s plaintiff alleged that, by requiring iOS users to buy apps exclusively from the App Store, and taking a 30% commission on all transactions that occur there, Apple is adding a fee that developers pass on to customers. Simply put, the plaintiffs claimed that Apple is using their monopoly over app distribution to raise prices for iOS customers.

Apple’s counterargument was that iOS users buy apps from developers and not Apple, and therefore Apple is not subject to some complicated provisions of US antitrust laws. (The specifics involve a 1970s legal doctrine called Illinois Brick and a kind-of confusing “indirect purchaser” discussion. Being a lawyer must be so fun.)

The court ruled against Apple, and in a 5–4 decision, allowed iOS customers to sue Apple for allegedly driving up prices of iOS apps.

What effect does this ruling have?

Let’s start with one important point: this ruling only allows iOS customers to sue Apple for their app-distribution business model; it did not rule that the App Store violates anti-trust law. However, this ruling clears the way for legal proceedings that attack the App Store’s business model directly, which could force Apple to fundamentally change the way app distribution on iOS works.

That being said, it’s possible (likely even) that the subsequent cases that challenge this model will take years to play out. After all, the initial court procedures that started the just-resolved case were made in December of 2013. Therefore, don’t expect this ruling to have any short-term effect on way you build and distribute iOS applications.

One reason the proceedings may take longer than expecting is dealing with the finer points of the law. For example, suppose the court rules that Apple’s model indeed violated anti-trust policies, and consequently raised prices for consumers. How do you determine the amount prices were raised? And who does the extra money go to? Customers? Developers? The current suit was done on behalf of customers, but it’s very possible that a class-action lawsuit on the behalf of developers could complicate the issue.

Long term, if legal restrictions do come down on Apple they’re likely positive effect on iOS developers. We might see a future where Apple is forced to permit third-party app stores, or to provide ways for users to side load apps—each of which would give developers more control in how they get their apps to their users.

Interestingly, these changes would make iOS work a lot more like Android, which already allows for alternative app stores and side loading, and is therefore not subject to these legal actions.

The ruling’s broader effect on the software world

Although these court proceedings have centered around Apple, this ruling has consequences that could extend to software distribution on other platforms, because there are a lot of platforms that have monopolistic control over app distribution that you might not think about.

Consider Rokus, Fire TVs, and basically all smart TVs platforms. In each of these, the only way to get apps is through a single vendor-controlled store.

Here’s another interesting one: Microsoft recently announced an Xbox that doesn’t come with a disc drive. Presumably the only way to purchase games for this new Xbox will be through a Microsoft-provided store; therefore, does that new Xbox violate US anti-trust law?

These cases will depend on how each platform makes money. For example, if Microsoft doesn’t make any additional money from digital purchases, there’s not much reason for developers or customers to file a lawsuit. But the court’s recent decision does open the door for class-action lawsuits against platforms with a business model similar to Apple’s.

Quick takeaways

If you’re still confused by all of this here’s a quick wrap up: the US Supreme Court ruled that customers have the ability to sue Apple for its monopolistic control over iOS app distribution, alleging that this monopoly unfairly raises prices for consumers.

This ruling doesn’t have any immediate effect on iOS users or developers, but it allows for further lawsuits to proceed—lawsuits that could fundamentally change how iOS app distribution works, and could have a broader effect on how all platforms control app distribution.

Add Basic Crash Reporting to Your NativeScript App

Rob Lauer — Thu, 25 Apr 2019 14:47:35 +0000

While I've personally never written a buggy line of code in my life, odds are some of you out there have. And what's the golden rule of open source?

Identify and fix errors before your users have a chance to create a GitHub issue!

We've collectively taken many approaches to logging errors with our apps (be they web or mobile). In my past as a .NET web developer, I often took a rudimentary approach by leveraging the global Application_Error event to have my app send a simple email with the error details. Meh 😐. It works, but doesn't provide the consolidated reporting required by enterprise-grade apps.

Times have changed and numerous, far more robust, "crash reporting" services have emerged. Some of the more popular ones being CrashProbe, Sentry.io, and Firebase Crashlytics.

Now if you're not using any error-reporting mechanism, my instinct is to shame you, but in reality I want to give you a hug and let you know it's going to be ok.

Today we are going to learn how to leverage Crashlytics (part of Firebase) to log and report on errors in our NativeScript apps for both iOS and Android.

TIP: NativeScript 5.2 came with vastly improved error logging improvements!

The Firebase Plugin

Quick history lesson: Crashlytics has been around since 2011. They were acquired by Twitter a couple of years later, and most recently acquired by Google for inclusion in their Firebase offering.

Not to get all marketingy on you, but if you're looking for a competitive, NativeScript-optimized serverless backend, take a look at Progress Kinvey.

While Firebase contains numerous services, the only one we care about today is Crashlytics. And what better way to utilize these services than via the NativeScript Firebase plugin!

To get started with Firebase, all you need to do is head over to the Firebase console and set up a new (free) account.

From here I would have you follow the simple instructions to get your first Firebase project set up and properly configured with your NativeScript app.

TIP: During plugin installation, the setup script will prompt you to activate one or more Firebase services. It's kinda important at this point to make sure you mark the Crashlytics services with a big Y when prompted. Worst case scenario, you can always reconfigure the plugin by going to the node_modules/nativescript-plugin-firebase directory and running npm run config.

Before you ask, note that the instructions provided allow for usage with NativeScript Core (i.e. plain JavaScript), Angular, or Vue.js!

Working with Crashlytics

With the Firebase plugin installed and Firebase initialized in your app, it's time to look more closely at Crashlytics.

NOTE: At this time, make sure your firebase.nativescript.json file has "crashlytics": true and "crash_reporting": false noted. This enables Crashlytics and disables the older Firebase crash reporting service. If you have to make a change to this file, remove the platforms folder in your app (it'll come back at the next build!).

Now at this point you can say, "I'M DONE!"...and you wouldn't be wrong. Crashlytics will start tracking app crashes and display them in your Firebase console:

But we can do better! It's a far better practice to catch errors before they crash your app and provide a meaningful error message to your users. Sometimes we can't predict error-prone spots, but when we have external dependencies that can change on us (like remote APIs for instance), we should play it safe, check for errors, and log them.

Capturing an Error

Anytime you want to explicitly log an error, you just need to plug in some tiny code snippets. You first need to import Firebase:

import * as firebase from 'nativescript-plugin-firebase';

Next, call the Firebase sendCrashLog method to send a customized error log to your Firebase project:

firebase.sendCrashLog({
  message: 'You screwed up! Here is the error: ' + error,
  showInConsole: true
});

Not only can you compose a custom message to be logged in Firebase, but you can also optionally show the same message in your console.

A good example of this in practice is the fetch module. Since fetch can be configured to catch an error response, we can log any errors quite easily:

fetch("https://httpbin.org/get")
    .then((response) => response.json())
    .then((r) => {
        // do something with the data!
    })
    .catch((error) => {
        // oh no!
        firebase.sendCrashLog({
          message: 'Error with that one API: ' + error,
          showInConsole: true
        });
    }
);

It gets better though. Since sendCrashLog returns a promise, we can also alert our users to a problem with some friendlier UI (in this case a native alert):

firebase.sendCrashLog({

  message: "Error!",

  showInConsole: true

}).then(

    () => {

      alert({

        title: "Sorry!",

        message: "Hey, we screwed up. Just thought you should know.",

        okButtonText: "OK"

      });

    }

);

Faking an Error

It's all fine and good to implement error logging in your apps, but how do we know it's working? Luckily it's pretty easy to fake a crash on both iOS and Android:

import { isIOS, isAndroid } from 'tns-core-modules/platform';

declare const Crashlytics: any;

public forceCrash(): void {

    if (isIOS) {

        // some nonsense code that is guaranteed to throw an exception :)

        var __error = 1/0;

    } else {

        throw new java.lang.Exception("Forced an exception.");

    }

}

Crashlytics Reporting

With some crashes logged, it's time to head over to your handy Firebase console and check on your report!

Happy 🐛 squashing!

Offloading Tasks to Worker Threads with NativeScript

Rob Lauer — Thu, 18 Apr 2019 13:13:59 +0000

Performance. Performance. Performance.

When we talk to NativeScript developers, performance consistently ranks as one of the top reasons they have chosen NativeScript. It's also something we can never get enough of. While mobile hardware continues to improve, there are always ways to improve the performance, and hence user experience, of the apps we create.

Aside from providing truly native UI across both iOS and Android, NativeScript has some additional tricks up its sleeve to allow you to customize your app for unique scenarios and squeeze even more out of those precious CPU cycles.

Let me introduce you to worker threads on NativeScript.

Worker Threads

Better known in the web world as web workers (or service workers), worker threads allow you to take the single-threaded environment NativeScript provides and turn it into a multi-threaded one.

NOTE: The Workers API in NativeScript is loosely based on the Web Workers API and the Web Workers Specification.

Service workers (a type of web worker) are quite popular with Progressive Web App (PWA) developers, as they allow for notifications and other non-blocking tasks. But where PWA functions end, NativeScript picks up the slack.

As evidenced by this NativeScript demo app, 99% of the time the single-threaded model is just fine (as running everything on the UI thread is super fast):

There are however scenarios when operations can take longer and hence impact the app's UI. This can lead to the app feeling slower than it should.

To solve this problem, NativeScript provides a Workers API which allows you to create tasks executed on separate threads that are completely isolated from the main app context.

Let's take a look at some examples of when (and when not) to use workers with a NativeScript app.

When to Use a Worker

Virtually any task that can run outside of synchronous UI operations is, at least in theory, a candidate for worker threads.

TIP: Before you start thinking a worker thread is a silver bullet for complicated performance issues, make sure you take into account the overhead needed to spin up additional threads.

CPU-intensive, non-UI related tasks are probably the best examples of when worker threads can be beneficial. If you are very heavy user of Google Analytics, you may find yourself measuring every user action, page view, feature use, and remote service call in your app. Even though these calls should run asynchronously, they can still have a negative impact on the main thread.

Another good example is image processing - a CPU-intensive task on its own, made much more complicated when you mix it into the UI thread!

A great example of offloading image processing is presented in these demo apps for NativeScript Core and Angular.

Sample Code

Lets look at how we can build a very simple worker ourselves:

var worker = new Worker("./workers/my-worker.js");

The above code initiates a new thread (runtime instance) and executes the script referenced (my-worker.js). Next, we will want to communicate with the worker and/or receive a message or result from it. This is accomplished with messages:

// send a message to our worker
worker.postMessage("Hello worker thread!");

// receive a message from our worker
worker.onmessage = function(msg) {
    console.log("Received this message from the worker thread: " + msg.data);
}

In our my-worker.js file, we will provide the onmessage method to receive the message from the main thread:

onmessage = function(msg) {
    console.log("Received this message from the main thread: " + msg.data);

    // perform some crazy cpu-intensive task here!

    // send a message back to the main thread
    postMessage("Hello main thread!");

    close();
}

Error Handling and Terminating the Thread

Using worker threads can be a bit scary, as threads left open can consume resources and potentially bloat memory usage and destroy performance. Therefore, make sure you catch any errors and close/terminate the threads when you are done:

Basic example in my-worker.js:

onerror = function(e) {
    console.log("Oh no! Worker thread error: " + e);
    return true;
}

And in your app code (should you want to display an error):

worker.onerror = function(e) {
    console.log("Worker thread error: " + e);
}

IMPORTANT: Worker threads are kept alive until explicitly terminated by the main thread or closed themselves!

Close the thread in my-worker.js with close(); (as shown above). Or terminate the thread in your app code with worker.terminate();.

If the worker thread is not terminated/closed, the garbage collector will not collect and dispose of the worker instance.

When NOT to Use a Worker

It's important to keep in mind that every time you spin up a new worker thread, you are adding to the resource and memory footprint of your app. This means that should you spin up too many at once or use them in the wrong situations, the performance of your app may actually decrease.

If you think a worker thread will help you process input from a form, or displaying a chart, or many other basic app features, think again. The NativeScript framework has already been optimized for the vast majority of these scenarios.

Your best bet is always to measure the functional performance of your app on a variety of both iOS and Android physical devices during development!

That being said, workers can be super useful in edge cases where performance of the main thread is lacking. The best you can do is test individual scenarios and measure which route is best for your situation.

Secure Your Mobile App - Episode Four (Secure User Auth)

Rob Lauer — Tue, 19 Mar 2019 14:51:18 +0000

Whether you are developing a traditional native app, a cross-compiled app from the likes of Appcelerator or Xamarin, a hybrid app with Ionic, or a JavaScript-native app with NativeScript or React Native, a common thread that runs through each is app security.

In the previous article, we made sure that data in transit was 100% secure from end-to-end, device to cloud. We learned that by leveraging Progress Kinvey we have a turnkey solution ensuring data integrity, compliance, and robust performance.

Watch the webinar Best Practices for Securing Your Mobile Apps to get some tips and tricks on NativeScript security!

As we wrap up this series, we want to conclude with a topic that is critically important: securely authenticating and authorizing your app users.

Part One: Protecting Your Source Code
Part Two: Securing Data at Rest
Part Three: Ensuring Data Integrity Between Device and Server
Part Four: Enterprise User Authentication and Authorization (hey that's today!)

Check out the new course from NativeScripting.com on mobile app security and get 30% off with the code: NSSECURE.

Biometric Authentication

We are long past the days of passwords and passcodes being the standard in securely authenticating our app users. With biometric security capabilities (e.g. fingerprint and facial id) built in to most iOS and Android devices, our apps should be focused on leveraging these vastly more secure technologies.

For fingerprint recognition, Touch ID is an iOS feature that allows users to unlock their devices with the tip of their finger. Android has an equivalent effectively known as "fingerprint scanning". Both are, of course, based on authenticating users via their fingerprints scanned before devices are unlocked.

For facial recognition, Face ID is a system designed and developed by Apple for the iPhone X line. Face ID will likely eventually succeed Touch ID as the defacto biometric authentication technology on iOS devices.

To use these biometric authentication options in your app, there is a fantastic plugin built by Eddy Verbruggen called nativescript-fingerprint-auth.

TIP: Even though it's called a "fingerprint" plugin, it also supports Face ID on the iPhone X line of devices!

Basic usage of this plugin includes capabilities such as checking if biometric support is available:

import { FingerprintAuth, BiometricIDAvailableResult } from "nativescript-fingerprint-auth";

class MyClass {
  private fingerprintAuth: FingerprintAuth;

  constructor() {
    this.fingerprintAuth = new FingerprintAuth();
  }

  this.fingerprintAuth.available().then((result: BiometricIDAvailableResult) => {
    console.log(`Biometric ID available? ${result.any}`);
    console.log(`Touch? ${result.touch}`);
    console.log(`Face? ${result.face}`);
  });
}

And verifying a fingerprint (or face on iPhone X):

fingerprintAuth.verifyFingerprint(
    {
      title: 'Android title', // optional title (used only on Android)
      message: 'Scan yer finger', // optional (used on both platforms) - for FaceID on iOS see the notes about NSFaceIDUsageDescription
      authenticationValidityDuration: 10, // optional (used on Android, default 5)
      useCustomAndroidUI: false // set to true to use a different authentication screen (see below)
    })
    .then((enteredPassword?: string) => {
      if (enteredPassword === undefined) {
        console.log("Biometric ID OK")
      } else {
        // compare enteredPassword to the one the user previously configured for your app (which is not the users system password!)
      }
    })
    .catch(err => console.log(`Biometric ID NOT OK: ${JSON.stringify(err)}`)
);

Check out this tutorial for a walkthrough of using this plugin with NativeScript and a Progress Kinvey backend.

The nativescript-fingerprint-auth is a great way to easily add biometric security to our apps. But what about using existing secure protocols and services to tie a verified individual to authorized roles in our backend systems?

OAuth 2.0

You've probably heard of OAuth before, as OAuth 2.0 is a commonly used industry-standard protocol for user authorization. Thanks to our extensive community of plugin developers, there is in fact a plugin for interacting with OAuth 2.0 in NativeScript, the nativescript-oauth2 plugin.

The OAuth 2.0 plugin helps to simplify access to OAuth providers that support the OAuth 2.0 protocol (e.g. Microsoft, Facebook, and Google), but you can also roll your own (or even use your organization's own provider).

Be sure to consult the plugin documentation for help getting started.

If you're curious about how the technical implementation of this plugin works with NativeScript apps, check the provided demo apps available for all NativeScript-supported frameworks:

Easy Enterprise Authentication

Still with me? Ok, I'll admit it: user authentication is a giant pain. 😥

If you're rolling our own auth provider, you have to tediously set up login forms, password recovery systems, and the supporting backend infrastructure. Or maybe you’re trying to integrate with an existing enterprise auth provider that uses acronyms like SAML, OAuth (see above), or Open ID. 😵

For easier enterprise authentication, look no further than the Enterprise Auth template in NativeScript Sidekick.

NativeScript Sidekick offers an Enterprise Auth template, as well as a handful of new features designed to help you connect to your authentication provider as quickly as possible. Powered by Progress Kinvey, the Enterprise Auth template guides you through the process of connecting to your provider of choice and makes it easy to customize the look and feel of your login screen.

You can read more about using the Enterprise Auth app template here on the NativeScript blog, or even register for a free online course on NativeScripting.com that walks you through the usage.

TIP: If you are rolling your own authentication system, you'll want to design a UI that is intuitive and as user-friendly as possible. We've put together a blog post and example app to show off some best practices for building your own awesome login screen with NativeScript.

Conclusion of the 📱🔐 Series

We've covered A LOT over the past four articles! We started out learning how to easily secure our source code, moved to making sure data stored locally is safe and encrypted, talked about some best practices for securing data over the wire, and concluded with some easy ways to make sure we are securely authenticating and authorizing our end users.