Ionic

Understanding TypeScript interfaces

An interface is a programming feature that helps to define the expected structure of an object allowing that to serve as a contract of sorts for the class where it is implemented.

That helps explain the concept but how does this actually translate into working with real world code?

Let’s say for example we have the following method:

public requestSpecificArea(lat : number, lng : number) : Observable
{
  return this.http.get(this._api + `locate-neighbourhood?q=${lat},${lng}`);
}

As you can gather from the code we’re using Angular’s HttpClient class to query a remote API which returns data as an observable that we can subsequently subscribe to.

The data that is returned will be structured as follows:

{
  "description": [
    {
      "id":1,
      "region":"somewhere",
      "summary":"something"
    },
    {
      "id":2,
      "region":"somewhere else",
      "summary":"something else"
    }
  ]
}

Should be fairly straightforward and any expected data will be returned right?

Not necessarily.

If Angular doesn’t ‘understand’ the returned data then the HttpClient object will return back an error like the following:

Property 'description' does not exist on type Object

Pretty frustrating right?

This is where interfaces come to the rescue.

Defining your objects

In the previous example Angular’s HttpClient class didn’t understand the shape of the returned object hence the error that was published to the console.

Using interfaces we can define the expected structure of such an object (i.e. the keys and their expected data types) like so:

export interface IRegion {
   description: Array;
}

export interface IRegionDescription {
   id: number;
   region: string;
   summary: string;
}

Here what we have done is very simple – created the following 2 interfaces (FYI: the generally accepted convention for naming interfaces is to prefix the name with a capitalised:

• IRegion
• IRegionDescription

We begin with the IRegion interface which defines the expected data type for the description property within the returned data (which will be an Array type). Notice that we created a second interface named IRegionDescription to describe the structure of the data for that array? We then use this to help explain the structure for the property value within the IRegion interface.

By using interfaces we can describe the expected structure of our object be defining both their properties and their expected data types (I.e. string, number, boolean, array etc).

What if we encounter a situation where some of those properties might be present in some returned objects but not others?

In TypeScript these are referred to as optional properties and can be handled using the ? operator like so:

export interface IRegionDescription {
id?: number;
region?: string;
summary?: string;
}

Putting it all together

Typically I define my interfaces in separate files and store these within their own interfaces sub-directory within the Ionic applications’ src directory. This allows me to separate my interfaces into one easily identifiable, central location making them easier to manage in the long run (it also keeps my code DRY – Don’t Repeat Yourself – which I appreciate as a developer striving for good practice).

Alternatively you might prefer to store your interfaces within your TypeScript files above the class where they will be used.

Either approach is fine and I’ll demonstrate both below.

Within my ionic-project/src/interfaces directory I create a TypeScript file named interface.region.ts which is structured as follows:

export interface IRegion {
   description: Array;
}

export interface IRegionDescription {
   id: number;
   region: string;
   summary: string;
}

This is then imported into the class where it needs to be used with the following import statement:

import { IRegion } from '../../interfaces/interface.region';

We then implement this interface using type assertion to instruct Angular’s HttpClient class on the expected data structure for the returned Observable:

public requestSpecificArea(lat : number, lng : number) : Observable
{
  return this.http.get(this._api + `locate-neighbourhood?q=${lat},${lng}`);
}

This then allows the data to be returned and parsed without throwing up any property not found errors.

If you prefer to define your interface within the class where it will be used simply do so as follows ABOVE the class definition like so:

export interface IRegion {
   description: Array;
}

export interface IRegionDescription {
   id: number;
   region: string;
   summary: string;
}

@Injectable()
export class YourPageComponentClassOrProvider {

}

For more information and to build Mobile app using Ionic, Hire Ionic Developer from us as we give you high quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft“.

Improved Perceived Performance with Skeleton Screens

When building an app, you’re always making sure that you are doing everything correctly from a technical perspective to ensure great performance. But another, often ignored part of performance is called perceived performance. Perceived performance is how fast an action appears to happen to the user.

Skeleton screens are a great way to improve the perceived performance of your app, when combined with traditional optimizations (lazy loading, code splitting, etc).

Let’s dive a little deeper into what skeleton screens are, why they are better than traditional loading spinners, and how Ionic makes it easy to use them!

Skeleton screens, not a scary movie

You have probably seen skeleton screens before if you have used Facebook, Slack or Medium, but let’s go into detail about what they are. We can think of skeleton screens as rendering the “skeleton” or a “mockup” of content before it has actually loaded. For example, here’s what Medium does:

Pic courtesy: blog.ionicframework.com

As you can see, Medium is rendering some grey bars where content will be once it has loaded and also renders a grey box where the image will be once it has loaded.

Another good example is Facebook. They make heavy use of skeleton screens in their native app and web app. They use a similar implementation to Medium, rendering a Skeleton Screen where content will eventually be:

Pic courtesy: blog.ionicframework.com

That’s coo…but why?

As we mentioned above, skeleton screens can be better at increasing perceived performance than loading spinners, but why?

Let’s consider an app that only uses loading indicators and look at how it could benefit from using skeleton screens.

Loading Indicator

Pic courtesy: blog.ionicframework.com

Skeleton screen

Pic courtesy: blog.ionicframework.com

The page using a skeleton screen has several advantages here that lead to a better experience including:

• It feels faster by giving an indication of what the content is going to look like before it has loaded.We never block the user from interacting with the
• app. The user is free to scroll and interact with the app even while the content is still being loaded.
• The page using a loading indicator is a very jarring experience as it flashes from a loading spinner to the fully loaded page. Whereas the page using skeleton screens provides a much smoother experience when the content loads.

Sweet, can I haz now?

Skeleton screens are pretty simple to make with plain HTML and a little CSS. Here is an example of a simple Skeleton Screen in Ionic-Angular.

In the above StackBlitz example, we hide the real list of users and display the skeleton list until the users have loaded using <code>*ngIf</code>. In our skeleton item we have the same DOM as our real item, an h2, h3 and p element.

<ion-list *ngIf="users">
<ion-item *ngFor="let user of users">
<h2>{{user.name}}</h2>
<h3>Email: {{user.email}}</h3>
<p>Company: {{user.company.name}}</p>
</ion-item>
</ion-list><ion-list *ngIf="!users">
<ion-item *ngFor="let fake of fakeUsers" class="fakeItem">
<h2></h2>
<h3></h3>
<p></p>
</ion-item>
</ion-list>

.fakeItem {
 h2, h3, p {
   background-color: lightgrey;
   opacity: 0.5;
   height: 1em;
   margin-top: 10px;
 }

 h2 {
   width: 35%;
 }

 h3 {
   width: 40%;
 } 

 p {
   width: 60%;
 }
}

<ion-item>
<ion-skeleton-text width="40px"></ion-skeleton-text>
</ion-item>