Navigating some of Gmail ‘s functionality can be a little frustrating. In this tutorial we will concentrate on Gmail ‘s Smart Reply and Smart Compose auto-completion tools, which are designed to save time.

Allowing a machine help you write emails and subject lines may make you feel a little weird, but if you’re willing to at least try it out for yourself, here are the ways to automate your Gmail responses.

Enabling Smart Reply and Smart Compose

To allow Gmail to generate responses and email text, you first have to opt in from your Settings menu. If you are a regular Gmail user (instead of G Suite enterprise edition), here’s what to do:

On desktop

• Click on the gear icon on the upper right side and find the Settings page.
• Scroll down to the separate Smart Reply and Smart Compose options and choose “On” for either or both to enable the automated suggestions.
• You can also choose to allow Gmail’s machine learning to personalize the suggestions based on the way you write your emails by choosing “Smart Compose personalization.” For example, if you greet your colleagues with “Hi, team” versus “Hello, everyone,” it will automatically drop in whatever you use most often.

If you use G Suite, you may notice that the option to toggle on Smart Compose is not available. Your G Suite admin must enable this for the organization, so contact the person in charge if you’d like to test this out at work.

On the Android or iOS app

• Tap the hamburger icon on the upper-left side to open the side drawer. Scroll down to Settings.
• Select the Gmail account you want to address
• Tap the checkbox on Smart Reply and / or Smart Compose to toggle the mode on

Once the settings are turned on, your Gmail is set up to suggest replies and help auto-finish sentences based on your writing style.

What it looks like

Basically, you just start typing, and Gmail will begin suggesting words that might fit the sentence you’re writing.

Be aware that it won’t always come on for every email you write. Because Gmail needs context, you’ll likely find Smart Compose chiming in when you’re responding to an email or if you’re starting emails with some generic statements like “Nice to meet you” or “Hope you’re well.” If Gmail has a suggestion, an opaque set of text will appear next to what you’re typing.

On the desktop version of Gmail, you can press Tab to accept the suggestion. On the mobile app, if a suggested word or phrase appears, swipe right to add it to the email.

Smart Compose can also suggest email subjects. Leave the subject line blank, and start writing your email. Once you go back to fill out the subject line, Gmail will offer a suggestion that you can accept by pressing Tab on the desktop app or swipe right on mobile.

Smart Reply for canned responses

Smart Reply works a little faster than Smart Compose. Instead of suggesting words or short phrases for you, Gmail will offer three responses that might suit the email you’ve received. For example, if you’ve gotten an email reminding you of an appointment, Smart Reply may suggest responses like “Confirmed,” “Thanks,” or “I can’t make it.”

If you are in an email conversation with several people, be aware that responding with a Smart Reply will CC everyone on that email. You’ll have to manually remove the people you don’t want in that response, so it’s best to only choose Smart Reply for emails you mean to send to everyone in the thread.

Should you actually use it?

Choosing to let a machine write your emails may feel impersonal, but it’s not designed to write the whole email for you. Smart Compose and Smart Reply work best when you use them to add filler sentences or quickly respond to yes or no emails. Plus, Gmail has gotten a lot better at suggesting responses that will make sense 90 percent of the time. (In my experience, the responses tend to veer toward affirmative answers, so they may not work best if you’re less prone to agreeing to everything.)

The post How to enable and use AI-powered Smart Reply and Smart Compose tools from Gmail appeared first on Information Stash.

When enabled, the feature allows your Smartphone to receive notification of likely COVID-19 exposure.

However, there is a disclaimer that the software is an API that can only be enabled when the device has installed a third party tracking app.

According to the statement, the feature will remain dormant until it is activated by a COVID-19 contact tracing app, which can be deactivated at any time.

Google and Apple therefore say that the devices won’t be theirs thus saying that the identity of the user won’t be shared with other users.

To ensure this, Google announced that “Access to technology will only be provided to public-health users. Their applications must meet strict Privacy, Protection and Data Use requirements.”

Still, app creators should be committed to minimise the vulnerabilities of their products.

On Android phones, the feature can be found in ‘Google‘ under ‘Settings‘ where ‘COVID-19 exposure notification‘ is displayed. For Apple devices, ‘COVID-19 exposure logging‘ is found under ‘Health‘ in ‘Privacy settings‘.

By design, this technology is meant to support the efforts of governments and private players that are building contact tracing apps. When an app is used to opt in, it generates randomly changing IDs based on location. Through Bluetooth, it periodically checks other IDs to confirm if any is associated with the infection. And if it finds any, it sends a notification.

For this to work, a person who is affected or has been exposed to the infection needs to share their IDs with the app, which will immediately alert all that have come in contact with them.

While countries like India make contact tracing apps compulsory for residents, only a few startups have made an attempt at this technology in Nigeria; this explains why adoption is low.

In fact, on the Google Playstore, there’s currently no authorised contact tracing app available in the country currently. Conversely, on the Apple app store, it shows two apps, one of which has already been disabled.

Despite some countries already putting the pandemic behind them, infection cases are unfortunately still increasing across Nigeria. Currently, the figure stands at 25,694, with Lagos state  — 10,510 confirmed cases — still the epicentre.

As economic activities resume fully in states that were previously on mandatory lockdown, this appears to be the time for the adoption of massive contact tracing tools to reduce citizens’ chances of infection.

Recall that before now the use of smartphone tracking and surveillance for COVID-19 tracing have been adopted across the world in China, Hong Kong, Israel, and even in Rwanda.

But there are concerns that this feature has privacy risks, disproving Google and Apple’s promise. Considering past events, this scepticism is not misplaced.

Google, like other tech giants, has at some point been accused of turning user data into narrowly targeted ads without consent. This is often possible because users are usually unaware of the data they are agreeing to share and the company’s plan for the information.

While these privacy concerns remain, we cannot undermine the possible positive impact of the tools this Apple-Google feature will effectively support. Perhaps, it is a case of choosing the lesser evil.

The post The Adoption rate of the Apple-Google COVID-19 tracker feature in Nigeria appeared first on Information Stash.

With numerous advantages over hybrid applications, native apps have ruled the game for so many years. It’s due to the ability to embed features brilliantly, to let the app perform functions in a sublime manner and to embrace the hardware in an ideal manner, which still is beyond hybrid framework’s competence. Cross-platform apps face a crucial choice in their development planning phase – should the application be developed as a native app, or should it be developed as a hybrid or web-based application? This question used to impact the amount of work to be done – namely, until recently, choosing to pursue a native approach for your application meant consigning your development team to simultaneously developing functionality in Objective C/Swift (for iOS) or Java (for Android).

However, this is no longer a consideration when it comes to creating a native app experience. Below we’ll look at using JavaScript to create a cross-platform native app experience by examining React Native and the combination of AngularJS 2 and NativeScript.

Native Apps:

Native apps have a number of advantages over hybrid and HTML 5-based apps. First, native applications are closer to the device’s processor, meaning that on average native code will perform better than equivalent code written for a hybrid framework. Additionally, a native app lets you build in some features that may not be available in your hybrid framework of choice, as you can target specific platforms with specific features, integrating with the hardware on a mobile device can be done right in the same set of source code, rather than having to include a custom module or non-web component in a hybrid app. Couple this with being able to provide an idiomatic user experience for a given device, and choosing to develop a native app becomes a much more compelling choice. By using a framework with a native component, we can further mitigate the costs necessary to develop the app natively.

React Native

In March 2015, Facebook introduced React Native, a tool built to allow developers to use the same base JavaScript code on either iOS or Android. As React was a set of functions with minimal external side effects and a tangential dependency on a DOM, Facebook was able to abstract away the use of a DOM as the primary rendering model into a pattern that allows for the easy substitution of native components instead of web views and HTML components. Thus, using the same code, an application can implement alert windows using UIAlertView on iOS and android.app.AlertDialog on Android, all without having to write any extra native code to support the UI views. Further, the capability of the tool enhanced when it was coupled with React’s speed, which allows you to build a super powerful cross-platform mobile application without making you write the entire code again. Couple this with React’s focus on speed and dirty-rendering, and you can build a blazing-fast cross-platform mobile application with only one code base.

AngularJS 2 + NativeScript

Kendo UI, introduced by the team at Telerik was intended to produce magical stuff (in this case hybrid and HTML5 apps) by blending it with the popular Angular framework. When used for hybrid apps and HTML 5 apps, this created a consistent cross-platform UI experience simply by leveraging the tools provided in the framework. When Telerik began working on NativeScript to provide a true cross-platform native experience, the dependence of Angular 1.x on tight coupling with a DOM for rendering posed problems when attempting to create a native UI map for Angular applications. However, with the advent of Angular 2, this all changed. Angular 2’s looser coupling with a DOM for rendering allowed the developers of NativeScript to perform similar tasks to those performed by Facebook when genericizing React Native – abstracting away view rendering and components so that a DOM was no longer necessary. As a result, Angular 2 integrates easily with NativeScript, allowing you to code your native app in a declarative style that can run on any mobile device platform.

Comparison:

The fundamental difference between the two, lies in the approach they follow in creating mobile applications with the help of the same written code base. Both of them have their advantages and disadvantages, which can’t overlap to dismiss the other. Let’s see what they have to offer. NativeScript takes a holistic approach, working to be a true “Write it once, run it anywhere” framework. This means that a lot of the UI elements used will be decidedly lower-level, as NativeScript is attempting to manage the UI in a transparent and repeatable way between the multiple platforms it supports. Add in the coupling with Angular 2, and you can create cross-platform applications that, through the virtue of Angular’s declarative UI focus, are more conceptually consistent than an application having to interpret between multiple UI paradigms.
On the other side of the debate is React Native, which chooses to embrace – rather than hide – its multi-platform nature. This means that while you can write React Native code in a platform-agnostic manner, you can also get down to the platform-specific UI layer. Stated another way, React’s goal is to abstract the business logic while supporting the differences inherent in UI rendering between each platform, while NativeScript has a focus on creating a singular development experience regardless of platform. Couple this with React’s focus on speed of rendering and execution, and you can easily create performance-focused cross-platform apps that can both run on the same code base, and leverage platform-specific components at will.
Which approach you prefer will ultimately be dependent upon the needs of your application – relatively generic database-powered apps will likely favor NativeScript as the UI is not typically resource-intesive enough to warrant a more platform-focused approach. And even in that case, the use of Angular 2 to drive the application’s architecture negates a lot of the speed benefit that React Native brings to the table. However, the use of Angular 2 with NativeScript requires adopting a traditional Angular architecture for your application’s code, something which React’s library approach doesn’t require. Additionally, with NativeScript being a separate project from Angular 2, this introduces additional dependencies into your application’s pipeline – a problem not as pronounced with React Native, which handles all of the cross-platform functionality in the React framework itself.

Conclusion:

Cross-platform app development has levelled up big time, be it NativeScript app development or React Native app development. Choosing between React Native and a combination of Angular 2 and NativeScript is, in many ways, similar to choosing between React and Angular themselves. React is designed as a blazing-fast lightweight rendering framework to be leveraged within the context of a larger application, and React Native continues this pattern of providing tools instead of patterns. Angular, on the other hand, is an opinionated application development framework that has a “right way” of developing applications in mind, something that the integration of Angular 2 and NativeScript carries further at the slight expense of deeper native device integration.
Thus the choice between the two is largely the same. Is you application focused on complex UI with lots of rendering and custom elements? If so, React Native might be the right choice for you. However, if having a single cross-platform code base with a declarative UI paradigm is more in-line with what you envision for your application’s architecture, then combining Angular 2 and NativeScript can help you realize the same gains you’d see in adopting Angular for a web application, all while maintaining similar development patterns and program architecture.

The post AngularJS VS React Native appeared first on Information Stash.