I am currently developing an app with many HTML pages to render.
The problem is that Android took about 500ms to start a WebView in my Activity.
i.e.:
I clicked some Button to trigger an WebView to render, in a new Activity.
Android opened another Activity, took about 100ms
Android opened a WebView control, took about 300~500ms.
This WebView starts to load the URL as usual and render the web content.
My question is: how to reduce the bootstrap time for opening a new WebView? ( the step2, but not step 3)
As a comparison, IOS bootstraps the WebView immediately, i.e.: 10ms
Disable all the animation and transition in your app as it makes it slower.
Try not to render too many requests in your controller and pass objects between them instead.
If you are going to show and hide elements according to the result from the database result make all the elements hidden first and then apply visibility then
Use services(directives , etc...) and minimize the code in your controller (they aren't supposed to hold too many code in them )
Related
I'm currently working on making hybrid-app.
(Using jquery mobile.)
I have some problems on rendering webview in the application.
There are lists and detail pages with html. when the transition happens, the screen displays white screen, a previous page for a seconds, white screen and then displays detail page. And it goes to the same when I click a back button.
is this a cache problem or hardware accelerate?
I separated css file from one whole one while the application was on service. And there was css rendering problem until i did "clear date" on mobile not "clear cache". CSS didn't seem like working at all on the page.
Is this a issue of jquery mobile? or is this also the cache problem? then why didn't it work when i did "clear cache" but "clear data"?
And what will happen if i put this?:
context.deleteDatabase("webview.db");
context.deleteDatabase("webviewCache.db");
will all data saved be deleted? like, settings people using now?
Two topics I noticed in the context of page transitions and jqm:
A) rendering of a page takes some time and have impact on the transition. If you generate/update your detailed page, wait until everything has finished before the page transition starts (can be achieved with setTimeout(..., 10)
B) unfortunately, all pages in jqm are scrolling together and are not independent from each other. I noticed that before a page transition starts, the current page is scrolled to the top. Afterwards the new page appears. Looks ugly... Unfortunately several css settings must be modified to change this behaviour.
Hope this helps,
Andreas
I have a WebView I'm loading in an activity in order to have it preloaded so that it pops up immediately in a different Activity (launched from the first).
The problem is that in order to instantiate a WebView, I have to pass in a Context, in this case it's the first mentioned above.
So it works great, and the second Activity shows the WebView just fine. The problem is that if I click a <select> dropdown in the WebView, its selector dialog shows up UNDER the WebView. It feels like the select doesn't work at all until you hit the back button and briefly see the selection dialog just before you return to the parent activity.
It seems as though when I append the WebView to the layout in the second activity, it's modals get attached to that activity's window, but the WebView itself is attached to the parent activity's window, so it shows in a higher point in the hierarchy.
How can I possibly change the Context of the WebView after it's been instantiated?
This is a very difficult problem to solve -- I have to create the WebViews before the activity is started, but I also need the selection dialogs to work.
Please if anyone can give me some insights here I'd greatly appreciate it.
This is for an SDK project, so I will not have access to the parent activity. Also, saveState isn't working, because the bulk of what is shown in the WebView is generated by JavaScript, and the full DOM stack doesn't transfer.
You can try to create the WebView with a MutableContextWrapper:
MutableContextWrapper mMutableContext=new MutableContextWrapper(context);
WebView mWebView=new WebView(mMutableContext);
and later on you could do
mMutableContext.setBaseContext(newcontext);
But ...
WebView is a very complex component that will probably be using the passed context to create other objects like Handlers. WebView probably uses those handlers to post stuff to the original UI thread, so at the end you'll probably have a View with a mix of contexts, you know, a double memory leak (if it ever works properly)
Webview spans at least 1 thread "webcore" that is where the action happens and is also in constant communication with the original UI thread with ... handlers? through the original context? who knows!
There are even 2 different webview engines: Kitkat is chromium-based while jelly bean and previous versions use AOSP/WebView. So you have an additional breaking point.
The reasons you state are not strong enough imho. WebView is not that slow. If the app you load is, try to optimize it. There are a lot of things you can do for that, like loading the HTML & graphics from internal assets.
In my App (it's browser) I have the same problem. I don't like to load WebView every time when user back to App. And I've solved this problem partially. I've overridden onBackPressed() on my HomeActivity and use moveTaskToBack(true) instead of super.onBackPressed(). So when user use system back on HomeActivity it does't destroy Activity and all views. It just minimize the App. Visually it's the same behavior but if user try to run App by launch icon, all views already loaded. I know it's temporary solution and all views can be destroyed by system any time but it gives quite good result. And covers a lot of cases for me.
I am attempting to make an Android app that will be paired with an iPhone app - both of which will use WebViews for 90% of their content. Creating a new WebView on both platforms takes a non-zero amount of time - for the iPhone I've had some success creating a WebView before the user taps anything, then adding it to the navigation stack when they do.
I'm trying to do the same with Android but the 'Activity' concept is holding me back. It appears that my WebView has to be part of an Activity, and I cannot render the view without that Activity being the one currently shown on screen. Is this the case? If so, is there no ability to preload a WebView and then insert it into an Activity?
Try looking at the Service concept more than Activity for running background tasks. Webview can be run in a service and that service can be loaded onCreate()
Little bit of background/ similar questions
http://developer.android.com/guide/components/services.html
Android: Using WebView outside an Activity context (The negative comments on the top answer shouldn't affect your question)
Of course. You can add the webview to your layout with the visibility set to View.GONE and make it visible whenever you want.
I'm working on an app that is using WebView. Unfortunately, when user clicks a link, when the page is loading, the whole WebView area "blinks" until its loading is complete. There's also 1 more problem with it - I'm using a JavaScript that reverses colors of the page at the end of its loading - so until it's fully-loaded, the colors are normal, so again - blinking.
So, what I wannna do is "stop" rendering of the WebView, until the page is completely loaded - then, resume the rendering, so it won't blink. How to do that?
Note: I don't want to modify the webpage to achieve what I want. I have to modify WebView behavior.
And one more note, because it's maybe not clear: by "stop rendering" I mean "display currently rendered page continually until the new one is fully loaded" :)
First make your layout background color white then make the WebView invisible.
after this use AsyncTask then put your webview loading in doInBackground and when it's finished in onPostExecute make your webview visible.
so the user will see the white layout first then the visible webview after fully loaded in postexcute
sorry if my english not good
You could implement a custom WebView, and override it's invalidate() method to do nothing until the page is fully loaded.
I'm developing a mobile app in jQueryMobile and PhoneGap. Often, due to the nature of jQM or because it's about loading data, a page will need some last-minute adjustments before it is shown. For example, form fields need to be filled in with dynamically retrieved data, or the contents of list items need to be given a slightly different style in order to fit better.
I am currently doing all these adjustments using the pageBeforeShow event handler. But I wonder if I shouldn't have been using the pageBeforeChange event handler. The jQM docs do not really make it clear how these two events relate to each other, i.e. which is fired first.
What I know
I do know the following
pageBeforeShow and pageShow are triggered after all of jQM's markup (e.g. making list items look pretty) has been applied.
pageBeforeShow and pageShow are bound to a specific page, whereas pageChange is called whenever a change of page occurs (so if you want to make specifi changes to one page before the user gets there, you need to test the event.toPage property)
Why I'm asking
And this is the background why I want to know if page(Before)Change is a better candidate.
jQuery Mobile page transitions are awkward on many devices. The big issue on Android devices is that page changes are jumpy: regardless of the transition type (fade, pop, etc), the page being left by the user will pop back into view briefly after the new page has more or less finished in the browser.
In my experience, this occurs mostly when other animations are running or are started while the page transition takes place. Basically, the Android browser doesn't seem to want to apply transitions to elements that are not actually in view, and it will flip back and forth between jQM pages as a result.
I've already developed a workaround where I delay any markup and form adjustments for a page by about 1000ms, which prevents the flashing but does mean that the user may be seeing these adjustments happen on screen after the page has come into view.
This analysis makes me think that pageBeforeChange might be a better candidate for attaching any markup and form adjustments. But it will be a big rewrite of the code, and I don't know what unforeseen stuff I will be getting into. Anyone have any experience with these events?
I'm not sure pagebeforechange would be the best place to do this. I don't see pagebeforechange as a page-level event, but more of a site-level event. I use it mainly if I want to take over navigation or to build dynamic pages.
I use pageinit when I want to attach event handlers to a page. I use pagebeforeshow when I want to change the contents or look of a page before it is shown.
Hope this helps.