I have a browse tab which searches for results and each result pushes to a page like illustrated below.
Then After I push to the result page there is an event button which when clicked opens an event page circled in blue like illustrated below.
After the event’s button is clicked we go to the event page fine.
But When I go back to the browse tab and click the searched result a second time, and click the event’s button it opens the event page twice.
If i go back using the back button navigating to the browse page and click the search result a third time, then click on the event it loads the event’s page three times.
So the amount of times i open the result’s page determines the amount of times the result page’s event page duplicates.
Here is a gif of the duplication after I have opened then closed the search result’s page twice and have opened it a third time.
Any suggestions on what do do to stop the page duplication?.
Solution
The problem was not with the navcontroller push. Since “navCtrl.push(page)” was inside jquery click function which fired more than once, all I had to do was make sure it did not fire more than once.
using .off() acts like a reset and .on() begins firing once
And wrap the entire jquery code in $(function(){}) .
$(function(){
$(document).off('click').on('click', '.viewevent', function () {
navCtrl.push(VieweventPage);
});
});
Can you explain why you aren’t just letting Angular handle user interaction? It seems like adding jQuery to the mix is just asking for needless trouble.
I use sanitized INNERHTML to load dynamic content from the server and this will not respond to (click) or any such angular events because the page preloads everything excluding the dom content I will load in later.
To combat this I use $(document).on(‘click’,’.viewevent’) from jquery import to handle the click interaction on any dom object with the class “viewevent” whether preloaded or dynamically added in later.
This is part of why I pretend innerHTML simply doesn’t exist. I guess if you’re happy with what you have, that’s really all that matters for you, but for anybody else stumbling across this thread, I would urge you to consider this approach instead.
IMHO, HTML is a terrible format for server/client communication in mobile apps. It is far too broad, vague, and squishy. In the vast majority of cases, a domain-specific representation in JSON is going to be considerably tighter, and despite being more extra work initially to set up, will result in much smoother testing and maintenance down the road.
