I have a problem with cordova 4.2 while using Xcode 7.0.1,when I run my application on IOS9 ,loading JS files taking around 25 seconds which is very bad comparing to android.
I tried to detect the problem by putting flag ,the loading is stuck with getting the handlebars (Since I am using Ember js).
I tried to minify the hbs with no improving.
function onDeviceReady() {
Helpers.getScript('app/app.js');
Helpers.getScript('app/helpers.js');
Helpers.getScript('app/init.js');
Helpers.getScript('app/router.js');
}
Thanks in advance
Okay. If all you are doing is loading files, then there is no need to delay loading those files. The only time you want to delay loading a file *is* if you have some active code in those files.
To be clear, there are some libraries that load and become active as soon as they are loaded. Those libraries would set variables or access the system in some way. These types of libraries need to be loaded AFTER the deviceready event. Otherwise, you are free to load libraries as soon as you can, and even before the deviceready event.
On your App, I cannot say why it is delaying to start. You say 20+ seconds, and I can only think it might be the delayed library loading.
NOTE: not all apps are built the same. This means that on Android, there are libraries that come with the system, and there are libraries that Cordova adds. It might, (might be) that you are loading a larger APP on an iOS system, and that might be the delay.
In any case, let me know what you have tries, and what worked and what did not.
Related
I'm using the standard PhoneGap plugin for writing to local files via HTML5. In the background my app is downloading data from a server and then saving it to disk as it comes in. Typical file sizes are around 20Mb.
If the user is scrolling the screen or some other UI action when writing is going on, my app will freeze for a second or two on an iPad 2 running iOS7. The file writing operation is wrapped in a setTimeout call (so it doesn't block the main thread) but this doesn't seem to help.
The XCode console reports this while file writing is going on (the lag feels like it happens for about a second or 2 and not the 200ms implied here):
THREAD WARNING: ['File'] took '93.378906' ms. Plugin should use a background thread.
THREAD WARNING: ['File'] took '125.793945' ms. Plugin should use a background thread.
What can I do to avoid the lag? How can I diagnose where the lag is happening?
Wrapping up the file writing operations with setTimeout does not prevent the main thread from getting blocked, where did you get that? It just delays the execution of the wrapped function, which in your case doesn't help you at all.
Nevertheless, I don't even think this is your real problem, because the file plugin's write operation is already wrapped up for execution in a background thread, which tells you the linked line from the iOS plugin source code.
My guess is there is some other stuff happening, that blocks your UI thread. Which functions from the plugin are you calling exactly? Try to debug/profile the whole process, when the UI lag occurrs, for example in Safari Remote Debugger.
If that doesn't help you, you should post more specific code which could give some hints about what is happening and what the problem could be.
I have been trying to figure this out for the last three days and as of yet have not figured out a solution. I'm creating an app for android and iOS in which the iOS version works as it should but the android version is not downloading the content that I need it to in order to actually load the next next page.
The issue is that I make a call to download a zip using FileTransfer plugin v0.4.4 the javascript side works fine and I have done a step through on the native source and it's coming through but it is not returning a callback for either success, error or onprogress which means that the scripts that need to run in the callback never get fired. I've looked and the data folder that it's being saved to and the file is being downloaded it is just the callbacks that are not working.Whats even stranger is that sometimes it will work but if I reinstall the app it will 9/10 times start failing again.
I've tried reverting to v0.4.2 of the plugin which from research sometimes solved the issue but in my case it has not. Has anyone else encountered this problem at all? or as any idea how to fix it.
Thanks in advance
I'm having some troubles using CrossriderAPI with turbolinks, my scenario is this:
1. Going on my http://website.local/
2. running a check to see if Crossrider extension is ready:
CrossriderAPI.isAppReady('xxxxx', function(r) { if (r) (console.log('ready')) })
3. yes of course, is it.
4. Navigating through the website (using turbolinks)
5. well, troubles start by here. turbolinks change the DOM to each request, but when I retry to check if Crossrider extension is ready, and I'm investigating why, what i receive is false. It seems not see anymore our extension.
I'm debugging this code to see if I get out from this problem.
has anyone succeeded with this? Any help or advice would be great!
Antonio
I am not familiar with Turbolinks, but in general based on their GitHub readme that states that "you can't rely on DOMContentLoaded or jQuery.ready() to trigger your code", I would think that it severely impedes extensions that rely on these events as they run when the page loads.
Specifically in this instance, since Turbolinks replaces the body content, it disrupts the CrossriderAPI library that utilizes the DOM content for its operation. Hence, without considerable reworking of the code, I don't think that Turbolinks can co-exist with the CrossriderAPI and can disrupt with extension functionality.
My JQM application needs to display only content that never changes. That's why I've written a static website which is about (HTML file <= 500kb).
I am using the multipage architecture. No own JavaScript is used.
The application works well on newer smartphones, but lags on older smartphones. Are there any ways to optimize the performance of JQM?
(Split into different files is not wanted..)
Consider a case that you're developing your website to make it work with Opera Mini as well, and then you'll have to make your website rely less on JavaScript.
If your website is actually a Mobile Webapp which substitutes a dedicated native app for smartphones that can't run it, you might want to make all your modules AMD-ready so that not all of your code gets downloaded at once.
And since you mention that:
I've written a static website which is about (HTML file <= 500kb).
I believe loading all that markup is not wise, if your target "old smartphones" have browsers which can handle Ajax, you can load page content selectively and maintain webapp state via hash-tagging the URLs.
Obviously, there's no magic wand to fix the problem your facing except for some modifications that I've suggested. You may want to check Google's Closure Compiler and some tips from Yahoo. :)
I am working on a solution that loads SharePoint pages in a copy of IE. When the page finishes loading an event is triggered that executes some code in the application that wraps IE.
Now this all works fine and well, until JavaScript is turned off in the browser, a requirement for this solution (Don't ask). Naturally I don't expect the out of the box SharePoint user interface to be fully functional without JavaScript enabled, but although the web page is rendered correctly IE's progress bar never finishes the loading process. As a result my code is never triggered.
Try it for yourself.
Open Internet Explorer.
Disable JavaScript access for the Internet zone.
Navigate to a public SharePoint site such as this one.
Watch in amazement how the progress bar never finishes.
Does anyone have any idea about what is going on or if there are any workarounds?
Answering my own question.
After extensive testing there doesn't appear to be a solution to this problem.
I think the issue that you are having is related to the specific SharePoint site. They are more than likely loading something else in the background that is not part of the base install of SharePoint.
We have some internal sites running on SharePoint and I am able to get the progress bar to completely load with JavaScript disabled on all of them and they are standard installs.
I don't really have an answer as to what the other site might be loading to cause this, but my guess is that it is something that is not necessarily related to SharePoint.