I'm devoloping a simple android app that has two activity ( let's call activity1 and activity2 ).
Activity2 contain a viewpager that has 50 pages. Because i want to increase performance when switching page of viewpager so i set offscreenlimit up to 15 page ( because my app mostly use activity 2 ).
For that reason when i switch from activity1 to activity2 ( when start app i will begin with activity1 and then switch to activity2 ) i take quite a lot of time and make my app isn't smooth as i expected.
To solve this problem i has been thinking about preload activity2 when i'm working on activity1 but it's seem android doesn't support preload activity. Another solution i think about is preload viewpager. but i don't know how to send loaded viewpager between activity
Can someone help me out ?
Android ViewPager automatically caches limited number of pages and not load all of them at once. It will create required pages on demand. By default it caches 3 views (one you can see, and the left one and right one of current one). But for optimizing the performance, I suggest you to use things like using views with small sized bitmaps (if you have any). I mean do not use large images for background or if you can use single-color backgrounds instead of bitmap-backgrounds. This one will really improve performance of your viewpager.
Related
I need to have an admob banner on top my Flutter app visible at all times AND not have to care about it being visible after I shuffle my app's pages.
I don't want to touch it, reload on page change, recreate it and so on - waste of time.
So far it's been over a year that I've made it work with two MaterialApps nested inside one another - one parent with SafeArea (banner goes in there) and the second one is where the app actually "lives" and goes about navigating its pages with cool transition effects and so on.
Before telling me how wrong it is - it WORKS. In production app serving thousands of people daily. Zero problems so far.
However, I'd like to know, with all the recent Flutter updates and stuff, maybe there's finally a more elegant solution to this?
I'm using the newest version of Xcode and Swift.
I was googling around to make my KWWebView even faster and found the following:
webConfiguration.suppressesIncrementalRendering = true
Documentation says the following:
A Boolean value indicating whether the web view suppresses content
rendering until it is fully loaded into memory.
But what does this mean? Does it mean, the html doesn't not get rendered and shown as long as not all resources like images and javascript files are completely loaded by the WKWebView?
As stated in the documentation it's a flag to tell the webview engine to wait or not till things are set and ready. whether to scan the document (html+related resources) to check for what to be redrawn periodically, or just await the full stuff to be loaded and ready.
WebEngine:
Rendering is a progressive process that depends on the assets (js, Css, images..) that will compose the page. It is important to understand that Turning this feature on or off will simply turn the algorithm of rendering on/off for loaded content.
How to make my page faster?
A lot of factors, rendering algorithm (engine's), how heavy your scripts are(bundle, memory allocation,event pass through and handling, etc..), the size of the images, how well structured your CSS is, and its hierarchical selector orgnisation(css parsing and application).
The order of which the assets are loaded( included) in the page.
You can always check the profiling of your page in (devtools for example) on a modern browser to see how things go, what size of memory it allocates, the bundle size, time for scripting, how the page is designed to consume/utilise device resources.
To make the long story short:
Generally speaking there are THREE main phases with a total of five steps through which your page has to go while living in the browser:
PHASE A: MEMORY/CALCULATION (CPU)
1- Scripting:
PHASE B:( PROCESSING CPU mainly)
2- Styling
3- Layout
PHASE C: (GPU POWER!)
4- Paint
5- Composition
When the browser decides to to update it has to go through these, either a full pass or a partial pass will make a lot of difference. consider the following example
if you have a div, and you decided to create an animation that moves it from the left edge of the screen to the right edge, you see developers doing two approaches:
THOSE WHO JUST WRITE CODE:
change the left value of the div style over time. ( simple right?)
THOSE WHO KNOW THE STUFF:
do a transfom by using translateX or translate3D.
both ways will work, the first will eat up your CPU, while the second will run at a very high FPS.
WHY ?
The first approach plays with sacred left value, that means the browser will have to re-calculate the new left (STEP1) > check style (STEP2) > THEN do a new LAYOUT (STEP 3) > Do a Paint ( step 4) > THEN enter Composition phase (STEP 5)
this will cost a full pass 5 stages that is totally unnecessary!!
The other approach on the other hand, will not require anything but a composition (one step #5) because the matrix manipulation in the GPU (pretty strong ability!) can handle displacements implied by using the translate3d or translateX!! you will see people talking about including a translate3d prop on your CSS elements to push performance (huh!) but the real reason is the above explained. so knowing what happens under the hood can save you.
supperess rendering is about waiting to load everything before starting to show things up, or simply try to handle things as they load..
//The point
I gradually load many objects (UIWebView) to the memory and after a while it crashes. Please Help
//Details
I have a UIScrollView with horizontal paging, wherein each page (with a separate view controller) contains a UIWebView with disabled user interaction. At first only webview #0 on page 0 gets loaded and as I advance through the pages the app gradually sends requests to load specific data. Downloaded data stay in memory.
After I load about 20 Webviews from internet source, my app freezes and crashes. If I use a dummy html string stored on the device, this happens after I load about 50 webview. But the problem persists.
I fixed much of the leaks and am only left with Mallocs. Since the problem does not occur with low quantities of UIWebviews Loaded I assume that I have to change my code to say 3 webviews and reuse them. But I don't know if that'd fix the issue. I have developed several apps before which don't crash and this is a unique case.
I store pointers to webviews and some other elements inside every Webview (such as labels) in arrays. The arrays get incremented in count with every new page loaded.
I use xcode 4.3 and a jailbroken iphone 4 to develop. I turned off requiring signatures in my xcode as a result of which the app gets copied onto my phone yet fails to attach to process. I cannot debug on my phone. My app works well in simulator but crashes a while after I launch it on the phone by tapping the icon.
From what I am able to describe as so, what do you think might be the problem?
Thanks
Yes, certainly having too many UIWebViews will cause a crash due to low memory. I'm not sure what your reason is for having multiple UIWebViews, but I would follow through with your idea to reuse a smaller amount of them instead of creating several.
Based on your device not crashing when you use a small amount, I would say that the problem lies in the use of too many UIWebViews and not in a compatibility problem with your jailbroken device, for example.
WebKit is notorious for its memory hogging. It mallocs large blocks of memory and fails before giving you the opportunity to release other resources. One UIWebView is bad enough. I've had this problem in apps with as few a 5 UIWebViews, let alone 50.
There are a couple of things you can try. One, if the web pages aren't too complicated, you could use a replacement view such as DTCoreText to render them. If you have to have webviews, you could cache the various HTML contents and re-render using one UIWebView.
You only need to use three UIWebView's for paging. Lets say the user is on page 2 (page 1 is the left page and page 3 is to the right). When the uses swipes to page 3, you could just display the web view currently on page 1 on page 3. You need to re-load the proper html when the user swipes between the pages.
With some caching of the web content, speed shouldn't be a problem once the stuff is downloaded.
I have used to loading a default image in my appication. So i have set to,
Sleep(3); in my delegate.m class.
But sometimes it will take more than 6 to 7 minutes. So i want to display the image 3 seconds only and then it goes to my appilcation based on my requirements.
Which one is best way to do that?
Sleep(3) or [NSThread sleepForTimeInterval:3.0] or something else;
And i must display the image 3 seconds only. Please explain me.
(Note: And I declared setter and getter methods only in my deleagte class.)
Please explain me.
As Rob noted, Apple strongly recommends against a splash screen unless it hides some necessary behind the scenes process (like loading game graphics.) It is so strongly discouraged that some people have claimed that their apps have been rejected for using an unnecessary splash screen.
The default.png doesn't exist to create a splash screen. Instead it exist to allow you to create the illusion that your initial view loads faster than it does. You supposed to use it to provide an image of your initial view so that the enduser can begin to cognitively orient themselves to the interface. By the time they have oriented themselves to the interface and moved their finger to touch the interface, it is live.
Why? Because iPhone apps are supposed be quick in, quick out. People don't sit down to use them at a desk like a desktop. People use then on the go. Sometimes they use them in the middle of a conversation.
I tell my clients to test out the usability of their apps (except for games) while walking, riding an exercise bike etc as well as in the middle of a face-to-face and phone conversation. In those circumstances, a three second pause is a big deal and very noticeable especially if the app is a practical app. Imagine if every time you opened the Contact app you had to pause three seconds to see an Apple splash screen. You would get peeved in a hurry.
The key thing here is that an unnecessary splash screen doesn't add any value for the user. It is a selfish act on the part of the software publisher to eat the end users time so that the publisher can build brand recognition for the sole benefit of the publisher. Wasting three seconds of the users time every time they use the app adds up in a hurry. (In my experience, it also makes the user perceive that the overall app is slow and clunky.)
However, if you do want to shoot yourself in the foot or if you have a client hell bent on a splash screen, you do it like this:
The splash screen appears until the first view loads so you delay the loading of the first view. In the app delegates applicationDidFinishLaunching: method, remove all the code that loads the first view into the window. Replace it with a NSTimer. Put the code to load the first view in the timer's fire method.
With that setup the app will display the default.png as it launches, when it gets to applicationDidFinishLaunching:it will appear to pause from the end users perspective because no view will appear to replace the default.png.
You should note that the standard launch time for an app is 3-5 seconds. So you may not have to do anything to show the splash screen for 3 seconds. It might happen automatically.
Apple strictly recommends against this (using sleep in this way), especially in the scenario of showing a splash screen.
The best thing to do is create a view that looks like your Default.png file, then have that be the first NIB.. you could then set an NSTimer to transition (with animation if you want) to your main view/window/controller.
I'm making an application for the iPhone. Essentially it'll be a guide of sorts, and all the generated information will be in one long window. Each block of information can have a 'link' in it to generate another block of connected information (for example a block about Wallace could link to a block about Gromit) that would appear at the top.
For example, at the start 1 block of data:
Wallace: Owner of Gromit
would become 2 blocks (on clicking Gromit):
Gromit: Wallace's Dog
Wallace:Owner of Gromit
Each block would also have the ability to be added to favorites list by clicking an icon. The text would need to be laid out with HTML and each block may be of a different length. A search on a different could also add a block to the top.
I'm OK with objects in 'easy' languages like PHP, but am basically new to iPhone and Cocoa, and I want to start off with the right approach here. A Table and cells looks like the correct approach, but is there any advantage of doing it as a long list (like I might do on a web version) or are there any restrictions in the way cells can hold/layout information that will cause me trouble down the line.
I believe this approach is popular for dictionaries.
I'm committed to doing it the way with a single scroll for a couple of reasons. The main one is that I want the user to be able to scroll instantly back to entries they've looked at before. i.e. the single view essentially represents a history of the data they've looked at. (if it's a lot stuff can drop off the end). Each entry will be very short but there will be a lot in total. So if the user has looked at
Wallace
Gromit
The Wrong Trousers
Cheese
Penguin
And they are not looking at Wallace, a quick half second scroll takes them back to 'penguin'.
Hierarchy is the way to go on the iPhone.
Remember that the iPhone has a small screen and that users can only see a very small amount of information at anyone time. (One interface expert compared it to driving while peering down a two inch pipe with one eye.) Users can easily get lost scrolling up and down a very long list even if it has index. (That's assuming your information can be easily indexed in a form that users will instantly recognize.) It's usually easier for users to click through several views with the data in each view getting more and more specific with each level. In addition, so many apps use this hierarchal system that your users will be used to it and expect it.
System wise, its easier for the iPhone to display just one level of hierarchy at a time so your app feels more responsive. The hardware doesn't to maintain all the data in memory but just the data it needs to immediately display.
If I understand you data model correctly, you would be best off with a hierarchy of two tables and a detail view. The first table would have an list of letters A-Z. The second table would be list of all records starting with that letter. The third would be a detail view showing links to that record. So, to see the example in the OP, a user would select W-->Wallace-->(Detail) Gromit.
Edit01:
I think you should do a test scroll of either a very long web page or UIScrollView and see how it affects performance and usability. I would caution you that layouts that seem perfectly usable and fast on laptop or desktop hardware become unusable and slow on mobiles with their weaker processors and much smaller screens. It's much more difficult to do " a quick half second scroll" back to a specific point on a long page on a mobile than on a larger screen.
You do have the option of creating a outline-like table view that inserts new indented cells as needed. I still think hierarchy is the quickest and most usable layout on a mobile.