I have a backbone app that I can’t figure out where this memory leak is coming from. I have a page, doing nothing (login screen). I’ve already removed every event listener and it’s basically just a view with a form… But if I do a heap snapshot on chrome and then 2 seconds later do another, it still shows detached doms.
https://www.dropbox.com/s/5f33hgbrc3b5z8y/Screenshot%202014-06-05%2008.14.20.png
I'm using the same app breakdown as seen here, and I also see they have the same problem:
http://davidsulc.github.io/marionette-gentle-introduction/#contacts
Thoughts?
Related
I have an ecommerce that is having a lot of trouble to work nicely because of cache. We started the deployment with register option on service worker and now, even after a week and having set unregister to it, there are still many costumers complaining about not having received updates.
I tried everything, even dropping my old production instance and creating a new one, to see if the browser would understand as a different app, but it did not work out. I also tried putting meta in the index.html, but no success, because index.html is also cached.
We are using Framework7 (version 1.6) in combination with React, Redux & Cordova in order to build an app that should be made available in the App & Play Store soon.
The app has about 15 different pages which primarily show textual data. Graphically speaking, the app is not very complicated.
When we start the mobile app, the application is very responsive and feels native. However, after navigating between different pages (± 30 times), or after recovering the app from an idle state we notice that the performance of the app degenerates remarkably. We have reason to believe that this has to do with the way framework7 caches the pages. When we look at the DOM structure of the web application, we see that when changing pages, the old page remains in the DOM and gets the css class cached. Also when putting breakpoints in the react components representing the pages, we see that these pages remain active. In other words, when you visit a page 20 times, 20 instances of the pages will be created and any handlers (like reacts componentwillreceiveprops method) keep getting called for each one of these instances.
We currently think these pages that are not cleaned up are causing the performance degradation, so we have been trying to configure the framework7app such that this caching behaviour is prevented.
We have been trying multiple things to prevent this cachingbehaviour:
1. we've put cacheDuration to 0, preloadPreviousPage and cache to false in the framework7App configuration.
=> this does not prevent any of the caching behaviour
2. we've put domCache of the pages to false
=> this breaks the navigation. Once you navigate to a page you already visited, the app doesn't navigate to the page anymore.
3. We have even been trying to do any cleanup ourselves, based on methods that are used internally in the framework7 library. This is one of the methods we came up with in an effort to clean up these pages:
setTimeout(() => {
var allPages = $(f7.mainView.pagesContainer).children('.page.cached');
for (var i = 0; i < allPages.length-2; i++) {
f7.pageRemoveCallback(f7.mainView, allPages[i], 'left');
f7.router._remove(allPages[i]);
f7.mainView.allowPageChange = true;
}
}, 200);
=> This does clean up the containers properly and removes the cached pages from the DOM, but whenever this code has fired once, the performance of the app deteroriates tremendously and does not get better after a while, even when the performance was still acceptable before cleaning up the cache. Could you please tell us what we are doing wrong?
Can somebody give us some insights on what we might be doing wrong and if this behaviour is normal? Thanks!
I'm trying to run a test where I have a list of ids to search in a web application and check if a property is set for each one. I modeled the search result as a Page, but every time I load a new search result the first result seems to be cached and I eventually get a stale element reference exception. How does one instantiate a new SearchResult page object for each searched id?
There is no concept of caching for pages in Geb. Page content elements can be cached though but they are not cached by default. You might be still getting StaleElementReferenceException even it things are not cached, for example when interacting with DOM elements which are removed while doing so and I suspect that this is what's happening in your case.
If your page is dynamic, i.e. the DOM is modified in an asynchronous way after an action is performed on the page then you should ensure to wait for the page to stabilise before interacting with the content. And there is no need to use WebDriver APIs directly to achieve it.
I would be able to give you better guidance if you shared code of your page class and the stacktrace you're getting.
Well, as technology progresses, issues we solved long ago crop up again.
Back in the dark ages, when PHP and ASP were considered awesome, we always had a problem with view states. If you had a page with say a dozen select combo boxes on it, your user chooses some combination and hits next, then realizes they screwed up and hit the back button on the browser, the combo boxes would be back in the default state, usually with option[0] selected. In order to prevent this, we had to write boatloads of boilerplate code that would save the state of those combo boxes to a cookie, or session variable, or something so that when the user hits the back button, we can reload the combo boxes back to the state they were in when they left.
This problem was compounded even further if you had a datagrid on the screen. Because then you would have to come up with some slick way of saving that grid somewhere to prevent from having to hit the database again.
Then came the light. Browser developers realized that most web developers were on the verge of going back to writing terminal programs in Cobol due to this issue and added UI caching to the browsers. This allowed us webdevs to not have to worry about this anymore except in odd situations.
So, life was good. Then someone came up with the bright idea of trying to replicate GWT without all the hassle and the web explodes with all these javascript frameworks. The one im dealing with specifically at the moment is AngularJS 1.2.10 with Angular-UI. I have until Friday (most likely wednesday tho) to make an initial assessment on if this technology is a viable alternative to our current standard (thats pretty much universally hated) JSF.
So, i follow some guides, pound my head against the desk a few times, and I have an angular app with 3 actual HTML pages, each HTML page with 2 views.
Before you go there, understand we can't use it unless we can do multi-page JS apps. Some of the applications that this will be worked into have been in development for a decade or more and its simply not financially practical to scrap an the entire UI and start over again. We would instead be doing things like taking these 50 struts pages and converting them to angular/rest and linking them seamlessly back into the remaining 800 struts pages of the application.
So in my exercise of playing with this, I encounter my old nemesis. Back button view state issues.
I have been playing with the UI-route system. The fact that I can deep link using the route system solves part of my problems. But, if say I have a search page like this:
view-search
combo: search type [member,nonmember]
combo: result type [detail,summary]
combo: search state {all the states]
textbox: contract number
etc etc etc
And various combinations of combo box selections and text entries comes up with a list of 1000 people. Now the user selects one of those people on the data grid and it takes you to view-detail. Well the fact that you can use routing to do something like index.html#detail/bob is cool, but if the user realizes thats the wrong bob and hits the back button, they get a blank search screen again and they have to enter everything over and worse yet, send another search to the database to rebuild the datagrid. Some of these screens have 50 or more options to choose from when searching for data so trying to put all of them into the URL routing sounds completely impractical to me.
Now in my research I found this post:
Preserve state with Angular UI-Router
And that has promise mainly because I have a view state object that I can store into a Redis database or a session EJB for cases when the user actually jumps out of angular and into the legacy Struts application, then back buttons back into the angular application, but the fact still remains that on some of these pages, that is a huge amount of boilerplate code that we would have to write in order to make it work.
I don't really mind the idea of having to manually save off the view state object and read it back in from a Redis server or something anytime a user enters or leaves an HTML page in the system. What i'm really looking for is a way to automatically generate the object that is to be saved without having to write volumes of boiler code.
Is this possible? I keep reading the ui-route documentation but it doesn't look like this is addressed, at least not that i've translated yet.
If this is possible, what controls should I be looking at?
thanks
-------------- Edit
I just thought of something. There is one central scope to each of the single page applications. (Im basically going to be building a multiple single page apps and hooking them together) So if i use a naming convention, something like this
$scope.viewstate.view-search.searchType
$scope.viewstate.view-search.resultType
$scope.viewstate.view-search.searchState
Then the viewstate object should simply be a js array and when I create a function to move to struts.do, i can simply save that array off to the Redis server as a nested map object. Then when my user back buttons back into the angular app, i can capture that using the route system and retrieve that viewstate object from Redis and insert it back into my scope, thereby rebuilding the scope for the entire single page app in one shot.
Would that work?
I believe that you have a very complicated issue of trying to keep the view states between your varying pages with the amount of data in your pages. I think that the only real effective way to do this is to write an angular service that you can then pass to your various pages. as You already know the service is a singleton that you can use in various controllers and could be utilized to maintain the view state as you described. here take a look that this link and see if it will help: http://txt.fliglio.com/2013/05/angularjs-state-management-with-ui-router/
After some thought what you suggest in your edit might work, but I would still use a service to retrieve that array of data, as it would make it easier to reinsert in to angular scope
I am exploring something similar for an Angular app that I am writing. Keeping a user login during a page refresh is easy. Displaying the state on the page after a refresh is an entirely different problem.
How long must the state be persisted? I'm evaluating two possibilities.
First, saving the state (current form values or whatever) to the database. As the page changes, incrementally save the state to the database. On a browser refresh check the database for saved values.
Second is to use local browser storage. This is 5 megs of storage. 5 megs is a lot of text. Again this data would incrementally be saved into storage. When the browser refreshed, simply load data from localStorage.
I'm new to in-app purchases, and following the tutorials, I've got the product request going, an observer, and everything. However, at the point that the modal purchase dialog comes up (while the observer thinks the transaction is in "Purchasing" state, the app freezes up.
In the logs, I'm getting a crazy EXC_BAD_ACCESS error right here:
0x35b822b4: blx 0x35f9bb18 ; symbol stub for: -[_UIHostedTextServiceSession dismissTextServiceAnimated:]
0x35b822b8: movs r0, #0 <--EXC_BAD_ACCESS (Code=1, address=0x69466469)
The interesting thing is that even though the app freezes, the purchase process continues, although with the app frozen, it will never finalize.
Based on some of the other posts I've seen, I've tried it on the simulator, multiple devices, as well as using ad hoc (TestFlight) distribution in case it was an issue with the development cert, and nothing works.
One possibility I haven't seen an answer for is that the product in question hasn't yet been approved. I assume that, since I'm connecting in sandbox mode, and since the product request process is clearly getting data back from the app store, that wasn't an issue. Is it possible that an un-approved store item is causing the problem?
If it is the case that the unapproved SKU is breaking things, I'm really confused because iTunes Connect indicates that I can't submit a SKU except with a new version of the app for review, and, well, if I can't test the store feature, I don't want to submit that new version. Anyone here have any experience with this who can tell me why everything is going kablooey?
EDIT: One other thing that might be important is that the purchase button is in a modal push (specifically a page-curl) view. I know that Twitter requests can't be called from modal views. Is there a reason a store transaction couldn't be done in this view?