It’s pretty much unavoidable that we’re going to need to pass data around our app at some point. Why? Because apps are made up of a whole bunch of views and user interactions and…stuff, none of which tend to exist in isolation. Whether we’re talking about data pulled in via a REST API, collected from a user input, generated client-side, or whatever else, it is often the case that we’ll need to use it in more than one place to create the types of rich experiences users have come to expect from mobile. At the same time, resources like data usage and battery life are limited on mobile, so we want to keep things like network requests and computation to a minimum whenever possible. Keep it DRY (don’t repeat yourself), as the old saying goes.<\/p>\n
In today’s blog post, we’ll take a look at two ways to do this in an Ionic 2 app: Angular services and Ionic nav params.
\n<\/p>\n
Let’s start with the slightly more complicated but more robust option of building an Angular service. Services allow us to create a shared instance of a class that we can inject into any component of our app via the Angular 2 dependency injection system.<\/p>\n
Here’s a quick example involving ice cream, since sharing ice cream is awesome.<\/p>\n
First, the skeleton of a service. All we need is to import Angular’s If you want to generate this boilerplate automatically, try using the Syntactically, the only thing that makes this different from an Angular component is the use of the Next, let’s add some logic to the service:<\/p>\n Pretty simple. We have a member variable that tells us if the user has had ice cream already, and a Now, all we need to do is use the Valuable And Important data the service provides to our component about whether or not the user has already gotten their fair (and very generous, I assure you) allotment of ice cream:<\/p>\n Notice how the component can access any public member of the service. In this case, we use the To do this, we keep the import statement for the Our service is neat, but I’ll admit it could be a little bit of overkill for something as simple as ice cream. On to nav params!<\/p>\n Nav params is a feature of navigation in Ionic that allows us to pass a JSON object from one page to the next. Using our ice cream app, let’s imagine for a moment that we are going to navigate to our All we need to do to use nav params is pass a JSON object as the second argument of To get this in our Then create an instance of it in our constructor and call Mobile app development, like life, is full of choices. Services and nav params are both good ways of moving data around our app, but how do we pick? In a real-world scenario, you are almost definitely going to use both options in your app, but on a case-by-case basis in your application logic, the first thing to think about might be where the data is going. If we are navigating from one view to the next with either Ionic’s The next thing to consider is persistence. Will the data be needed in the future, or does it need to be used in more than one view of our app? If this is the case, a service is probably more appropriate. Since services create shared instances that can be injected into any component, they can ensure immutability and\/or consistency. In short, we can easily ensure that the data will be the same everywhere it is used, since every component will be consuming the same data source.<\/p>\n But let’s get our priorities straight. The important thing is that the ice cream is safe and accounted for.<\/p>\n","protected":false},"excerpt":{"rendered":" It’s pretty much unavoidable that we’re going to need to pass data around our app at some point. Why? Because apps are made up of a whole bunch of views and user interactions and…stuff, none of which tend to exist in isolation. Whether we’re talking about data pulled in via a REST API, collected from […]<\/p>\n","protected":false},"author":40,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"publish_to_discourse":"","publish_post_category":"","wpdc_auto_publish_overridden":"","wpdc_topic_tags":"","wpdc_pin_topic":"","wpdc_pin_until":"","discourse_post_id":"","discourse_permalink":"","wpdc_publishing_response":"","wpdc_publishing_error":"","_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[2,3,13,25],"class_list":["post-1445","post","type-post","status-publish","format-standard","hentry","category-all","tag-angularjs","tag-ionic","tag-ionic-2","tag-tutorials"],"acf":[],"yoast_head":"\nInjectable<\/code> and a basic class declaration:<\/p>\nimport { Injectable } from '@angular\/core';\n\n@Injectable()\nexport class IceCreamService {\n\n constructor() {}\n\n}\n<\/code><\/pre>\ngenerate<\/code> command in the Ionic CLI, which will create the above plus a little extra for you in src\/providers\/icecreamservice.ts<\/code>:<\/p>\nionic generate provider icecreamservice<\/code><\/p>\n@Injectable()<\/code> rather than the @Component<\/code> decorator above the export<\/code> statement. This tells the Angular compiler that this class is available for use in Angular’s dependency injection system.<\/p>\nexport class IceCreamService {\n\n hadIceCream: boolean = false;\n\n constructor() {}\n\n getIceCream() {\n this.hadIceCream = true;\n return 'mmmm... ice cream'; \n }\n\n}\n<\/code><\/pre>\ngetIceCream()<\/code> function. Next, let’s use it in a component by doing three things:<\/p>\n\n
import { Component } from '@angular\/core';\nimport { NavController } from 'ionic-angular';\n\n\/\/ import the class from the service\nimport { IceCreamService } from '..\/..\/providers\/icecreamservice';\n\n\/\/ the class name of the service is the provider\n@Component({\n templateUrl: 'build\/pages\/home\/home.html',\n providers: [IceCreamService]\n})\nexport class IceCreamPage {\n \/\/ create an instance of the service\n constructor(public iceCreamService: IceCreamService, public navCtrl: NavController) {\n\n }\n}\n<\/code><\/pre>\nexport class IceCreamPage {\n message: string = "Ice cream. It's Good and You Want It.";\n constructor(public iceCreamService: IceCreamService, public navCtrl: NavController) {}\n\n getIceCream() {\n if (!this.iceCreamService.hadIceCream) {\n this.message = this.iceCreamService.getIceCream();\n } else {\n this.message = 'Stop hogging all the ice cream =(';\n }\n }\n}\n<\/code><\/pre>\nhadIceCream<\/code> variable in the conditional, as well as the getIceCream()<\/code> function, and since we injected the service at the component level, it will share a single provider instance with all it’s child components. That’s pretty neat, but better yet, let’s change it so any component in our Ionic app will also have full and consistent access to a single instance of the provider.<\/p>\nIceCreamService<\/code>, but remove providers: [IceCreamService]<\/code> from the component definition in our IceCreamPage<\/code>. Then we import the service and add the provider to the core AppModule<\/code> of our app in src\/app\/app.module.ts<\/code>:<\/p>\n...\nimport { IceCreamService } from '..\/providers\/icecreamservice';\n\n@NgModule({\n\n...\n\n providers: [IceCreamService]\n})\nexport class AppModule {}\n<\/code><\/pre>\nUsing Ionic Nav Params<\/h3>\n
IceCreamPage<\/code> from a different view by using:<\/p>\nthis.navCtrl.push(IceCreamPage)<\/code><\/p>\npush()<\/code>:<\/p>\nthis.navCtrl.push(IceCreamPage, {status: true})<\/code><\/p>\nIceCreamPage<\/code>, we import Ionic’s NavParams<\/code> component:<\/p>\nimport { NavController, NavParams } from 'ionic-angular';<\/code><\/p>\nget(key)<\/code> to retrieve the value from the nav params object. In this case, we call get('status')<\/code>:<\/p>\nconstructor(public navCtrl: NavController, public navParams: NavParams) { \n if (!this.navParams.get('status')) {\n this.message = 'Have some ice cream =)';\n } else {\n this.message = 'Stop hogging all the ice cream =(';\n }\n}\n<\/code><\/pre>\nDecisions, Decisions<\/h3>\n
NavController.push()<\/code> or NavController.pop()<\/code>, then nav params could be a good choice. It’s lightweight and easy to implement. Conceptually, it also makes it very easy to reason about how data is flowing between views in our app, since we are passing it off directly.<\/p>\n