A general question about object

Ionic Framework ionic-v3
1

I’m pretty sure that this is a typescript or debugging question, may be it’s silly… I’m new to js or ts, I just started with them when I started with ionic.
In my app I open a browser InApp (ionic native inapp), the URL is a non-interactive page, it only display data, depending by a parameter coming by the app. Later the user can open it again with different (or equal) parameter, but however the user have to close the browser after read.
Using the console for debug, I see that browser page remain opened (or, at least, I can see them in devtools page of Chrome, listed under my device as blank pages.
So I subscribed the event close of browser and when the event raises I set it to undefined. Few lines:

        this.browserPage = this.iab.create(url, '_self', options)
        this.browserPage.on('exit').subscribe((data) => {
            this.browserPage = undefined;
        });

Nothing change.
Is only a debugging effect? Have I to destroy the object or it is irrelevant on Android (and IOS)?
To close the browser is enough, or I’m forgetting anything?

2

Can’t help you with your actual question, but: Why do you care that the page stays open in the background as you describe?

3

It’s part of question, actually. Have I to destroy the objects when I need them no more? My app creates a new object each time the user wants to read data for a different target, there is no limit, theoretically.
Do they waste memory or can I avoid worrying about it?

4

I agree with you, it’s a bit hard to grab it when your from a different coding backgound (like C, ROR or Php for Me). Still, the concept is a derivative of old JS, that gave birth to both Java, and TypeScript. TypeScript (which rely mostly on old javasscript in browser, but more object-oriented, has the same “family”).

Hence whether you like it or not, an object can’t be declared as an easy variable and both way around. Maybe in a future version of EMAP/TypeScript, this will change, but in JavaScript an Object has a special purpose; that’s why it can’t be both an Object and a Value declared at the same time.

In the Context of Ionic (based upon AngularJS), this make tons of sense, in order to avoid confusion between what will potentially change, and what will stay as functions or pre-built values, as any variable or let is bound to async due to being a dependency of Angular.

This is also why, you often have to unwrap an Object to actually get its contents, by means of observables or promises. Personnally I find it odd, but that’s the way the language is built.

Hope it gives you a clearer picture,

5

JavaScript did not give birth to Java. The two languages have totally different lineages, and if anything, JavaScript was developed as a marketing response to Java.

JavaScript employs reference-counted garbage collection. That means that while you don’t have to explicitly destroy things, if you keep references to them lying around (such as within your this.browserPage property), they won’t be reaped properly. Your assignment to undefined (or the equivalent delete this.browserPage) will make the object available to be automatically reaped, providing there are no other dangling references to it anywhere else.

1 Like
6

Thanks rapropos. So it’s better, in my mind, to declare the object undefined, as I do subscribing the browser close event.
But why I continue to see the object reference in chrome developer console until I close the app? I didn’t set any property.
Is the subscriber itself then maintaining the object alive?

1 Like
7

That would seem likely. subscribe() returns a Subscription, which you can save and call its unsubscribe() method before you trash your explicit browserPage reference.

8

I tried at first. But the object doesn’t have unsubcribe… I’d got the error: ‘object doesn’t have unsubscribe method’

let exit = this.browserPage.on('exit')

exit has subscribe method, but doesn’t accept unsubscribe. I tried something of this type:

let exit = this.browserPage.on('exit');
exit.subscribe(() {
    this.browersPage = undefined;
    exit.unsubscribe()
});

But I got the error; and also Visual Studio Code doesn’t suggest me unsuscribe…

p.

9

I guess it’s not a true Observable then, just something else that happens to have a subscribe() method.

10

Actually the documentation at
http://ionicframework.com/docs/native/in-app-browser/ said:

on(event)
A method that allows you to listen to events happening in the browser.

Param	Type	
event	string
Returns: Observable<InAppBrowserEvent>
Returns back an observable that will listen to the event on subscribe,
and will stop listening to the event on unsubscribe.

I think there is a bug or a doc error…

11

No, I just wasn’t reading what you wrote correctly, sorry.

You want to do this:

let onExit = this.browserPage.on('exit');
let onExitSub = onExit.subscribe(() => {
  onExitSub.unsubscribe();
  delete this.browserPage;
});

It’s the subscribe() call that returns the subscription; it’s not on the Observable itself.

1 Like
12

Thanks a lot, rapropos. I understood finally what is the observable.
But it doesn’t resolve my first question, I continue to see orphan browser in debug and the ram use of the app increases each time I open and close a browser page.
May be it’s normal, and browser close by itself…? Ram increase is not so big.
I see this

13

@rapropos I would never pose me as a defender of one against another. But it will elaborate for you. Java was existing way way, way before JavaScript, no? I said it “gave birth” to JS because I knew what is JavaScript 3 and 4 in the years of the first web agencies in the world (1997-2000), on a web context. And if not Java gave the idea to that at the beginning, I wonder who or what code :stuck_out_tongue:

14

What you originally said (“old JS, which gave birth to Java”) seems to me to be the opposite of what you are saying now.

Java was in development for several years, because it was a much more serious effort. JavaScript was built in a week and a half. Both were released to the public around the same time in 1995. Both originally had different names - Java was Oak and JavaScript was Mocha. The only reason for the similar naming was marketing; structurally the languages have very little in common.