I'm programming a web version for our Android app, which is similar to Instagram. I chose this to create the feed:
<div *ngFor="let post of postList"> ... </div>
Inside that div tag is the HTML of a single post, like the image, the caption etc.
My question is if that is a good choice of architecture. In particular, I'm concerned if this works if the user keeps scrolling to the bottom and the array postList becomes arbitrarily big.
If I understand it correctly, the HTML code of the site will grow arbitrarily big too (for each new post, one clone of that div is appended, right?).
But doesn't that cause performance issues at scale? Coming from Android I know that when you use ListView you will get exactly those performance issues, so you use RecylcerView instead, which recycles views, so no matter how big the array is, you only have a "small" amount of views being used due to the recycling.
How to handle this in web dev? Am I good to go with my solution from above?
Another option you could try if you do not want pagination but want the list to be performant, would be cdkVirtualFor from angular material. With little setup this can turn a large list into something that performs very well.
https://material.angular.io/cdk/scrolling/overview
In short, that will be a problem if you're not limiting the number of results returned. I would recommend researching pagination for limiting query results
Related
I am freelancing to solve crash of an android app. It happens on startup, and I know it is because the activity_main.xml. It has too many views, too many nesting levels. Apart from that (wich I will try to reduce)
what are other strategies to improve layout performance in Android?
The user interface cannot be changed or simplified.
For example:
- for repeated elements (50 - 100), does using 'include' makes it faster?
- the same for defining properties in styles instead of in every item.
I have been recently working on improving performance of app and renderd a fast smooth UI let me share you my experience :
The vision of performance in terms of UI is:
Lower the latency of screen draws
Create fast, consistent frame rates to avoid jank/lag.
And there are some thumb rules for layouts .
Minimum view hierarchy.
minimum background drawbles
minimizing overdraw of window :
minimizing overdraw of Views
using drawble left instead of image and textview aligned horizontally.
using lists/recyclerview very often when repetitive view
and Many more . let me share some links which are really helpful
https://medium.com/#elifbon/android-application-performance-step-1-rendering-ba820653ad3#.pp7hpnv07
https://www.safaribooksonline.com/library/view/high-performance-android/9781491913994/ch04.html
https://riggaroo.co.za/optimizing-layouts-in-android-reducing-overdraw/
https://www.hackerearth.com/notes/rendering-performance-in-android-overdraw/
Letme know if it's helpful. Cheers
You can try following from https://developer.android.com,
Optimizing Layout
Inspect Your Layout
Revise Your Layout
Use Lint
AS well as
Improving Layout Performance
Optimizing Layout Hierarchies
Re-using Layouts with
Loading Views On Demand
Re-using Layouts with
I have answered a related question before and my advice is still applicable in this topic.
Handling loads:
Lazy Loading - Load only those piece of information that is really needed by now. Example : A Movie app: Load only those latest movies rather than those old movies unless the user told you to do so. The idea here is that decided only on which is necessary to load first and load other else later on. The lesser the load the greater the performance is while without sacrificing a good content.
Caching - If you keep on downloading things from your server chances are it might take too long to load and your splash screen will be visible for longer period of time or some of your UI might freeze specially when you do it in the Main thread. With caching you will need to fetch fewer data from the network since you've downloaded some of them already.
Things to consider in creating views.
Avoid a super deep nested views.
Avoid a deep nested weights.
For image loading use some popular library like Picasso, Glide etc.
does using 'include' makes it faster?
A bit, Reusing layouts is particularly powerful as it allows you create reusable complex layouts. For example, a yes/no button panel, or custom progress bar with description text. It also means that any elements of your application that are common across multiple layouts can be extracted, managed separately, then included in each layout. So while you can create individual UI components by writing a custom View, you can do it even more easily by re-using a layout file.
Source : Official docs
Addendum
When things are still wrong and the Android framework doesn't provide what you really need; the last approach is to create your own view via extending View or ViewGroup. Creating your own view/layout requires time and much effort but you gain more controls since it is your own view/layout implementation, let say you have the power to change the world.
I'm writing one of those reader applications. I would like to know if you have opinions and arguments for and against using WebView and Canvas (with drawText()) to achieve it.
What are the requirements:
format text according to a few html tags: <p>, <strong>, <h3>, <br/>, <a>,
display images within the text (they are in <img> tags),
display the text in two columns on tablet devices,
paging the text (Google currents style)
The ones in bold are absolutely required. The latter are strongly desired, but I can drop them.
So as far as my knowledge goes:
WebView will be great when it comes to displaying the html formatted text. I also don't have to take care of loading images, tey will be loaded automatically with <img> tags (will they, even if I use loadData() instead of loadUrl()?). The problems begin if I try to page the text. Is there a possibility to count the size of the text in a WebView and reflow it into multiple pages (using ViewPager)?
Canvas is great when it comes to counting the size of the text, putting it into columns and pages. But I will have to handle all the HTML tags myself, format the text myself. What is even worse, I will have to extract images' urls, handle the downloading and putting them back to the text (reflowing the whole text every time they load). Am I right?
Can you point some other advantages and disadvantages of using them? Which would you choose? Or maybe something else? Or is there some lib which does at least some of the work for me?
Why not use the Textview combined with spanned text and viewpagers for the paging.
First let me say that I'm very new to android development (although I have a good understanding of the basics of java), and I am building a magazine reader app for a campus publication I work for.
I want to display each article using a ViewPager widget. I'm going to build a java program which enables the magazine editor to post articles in .txt format onto a server, along with images associated with each, and have the android app periodically download these articles to a local folder.
I'm a little confused about how to construct the views for each ViewPager from the text files. Somehow my logic needs to determine the size of the screen running the app, in order to know how many words can fit on each screen.
Is this right, or am I fundamentally misunderstanding ViewPager somehow? If so, how might I structure the program to configure the views dynamically based on the txt + images given to it?
From what I understand, each page will contain as much of the article as possible, and when the user selects the article they will be able to see the entire thing. Something like this, but so it fills up the entire screen?
If this is the case, you have two options here:
Just ellipsize the textview so that it ends with a "..." at the end. Probably the preferred solution.
Resize the TextView to fit all your text (Auto Scale TextView Text to Fit within Bounds).
EDIT:
Here's a different interpretation of your question.
From what I understand, you're trying to have something like an eBook reader with an undefined number of pages; kind of what Flipboard does:
Basically, once all the text fills in the entire area you want to have it continue to the next page.
The easiest way to do this, if you do not need native performance, would be to just use a WebView, split the text across several columns, and have only one column be visible at a time.
However, it is certainly possible to calculate how tall the entire text would be and then split it up accordingly; i.e. Pagination in Android TextView
It seems similar questions have been asked and addressed: Splitting a TextView into multiple TextViews relative to screen height (see the accepted answer).
I'm currently working on an android application and I recently came across something which mentioned that an activity should aim to have less than 80 views.
I have a couple tablelayouts with some textviews in each one. Would it be more efficient/possible to have one textview and use html tables to try and achieve the same look I have with the tablelayouts?
It would cut down on the number of views, but would it be worth the time to rework the layout?
To get a Spannable-object (which can be displayed in a TextView) form an HTML snipped, you can use the HTML-class from the Android framework, as illustrated here: How to display HTML in TextView?
However, the docs for this class also state that:
This class processes HTML strings into displayable styled text. Not
all HTML tags are supported.
A nice list of supported tags can be found in this answer and this Blog-Post (Spoiler: <table> is not supported).
Theoretically, having more than 80 views on one Activity is a lot. In pratice, it turns out that this can be handled by many phones with ease.
I created an application that collected Geo-Data and displayed all taken locations in a table (which would have more than 900 items). Even with the full table it scrolls smoothly (on my Motorola Xoom and my HTC Desire HD).
If you should encounter any problems with long lists/tables on certain devices, there is always the option of lazy loading.
It should be a general goal to show the most important/precise data at the top (so the user does not need to scroll at all).
So, you would show the lets say 30 best hits and when the user has scrolled down to number 20 (or so), you asynchronously load the next 30 entries. That way, you get a never ending list (given that the data is endless).
I'm building an e-Book reader for android. The content of an ebook is often divided into html files (epub) with one or may chapters in them.
I'm planning to build an e-book reader who divides the content of those files into different "pages". The problem is to know how many much text "fits" on one page and to calculate the correct amount of pages since that depends on a number of different factors, such as: font-size, word size, paragraphs, images, page-breaks, headlines etc.
Idealy i would have my text justified and selectable, and since that's not possible with normal TextView or EditText i must use a non-scrollable WebView.
So to sum it up, how can i "measure" how much text that fits on one "page" on my WebView? Or is there a different better approach to solve this? I saw that the Paint class as support for measure text and breakText.
Thanks!
Note : This answer does not use the webview as your display surface.
You can use the Canvas to draw each page. The canvas gives you it's height & width using which you can draw each line on the canvas using drawText based on the width & height available.
Basically you can calculate how many letters can fit in a line , take that many words , taking care you don't split any words and keep drawing the text.
If you break up the tasks to use different workers for each paragraph you can also probably make it fast.
Maybe you can do it like this
Text is being added and rendered inside WebView
In WebView, you can use Javascript to inspect the current state of DOM tree and extract measurements like width and height of individual elements
Javascript communicates back the size of the page back to WebView creator thru some callback
When Javascript detects that the page size threshold is exceeded it sends a signal for a page break needed
Android HTML5 Kindle does page breaking with Javascript so it is definitely possible.
Take a look at the source of FitText or perhaps here. Both figure how much text can fit in a given space. You may be able to borrow ideas from them and adapt for your purposes.