I'm creating an Android app for a large screen device. From the User's perspective, I'd like to have at least two, maybe three, lists of objects that they can scroll through.
I was originally thinking of using ListView, but after reading the documentation, it seems ListView is better suited for occupying the entire screen, or activity
Can I have multiple ListViews on the same screen? If not, what would be the easiest way to accomplish this?
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 am working on mobile app that represents a gamebook.
It contains episodes and each of them is built of one or more pages of text.
For every episode I use PageView with children Columns(with nested Text and RichText) for each page. The screen orientation is locked on portraitUp and the textScaleFactor - on 1.0.
The problems I found with this approach are related with the different screen characteristics of mobile devices:
I need to determine the amount of text for every child of the PageView.
But how much text will not bottom overflow on the smaller screens?
My approach till now is to test on relatively small devices with resolution close to 360 x 640 logical pixels and to leave some extra space below text.
Additionally I could make every page of the PageView scrollable, thus preventing overflow at all, but this will produce bad UX by my opinion.
I use font size suitable for devices with the mentioned resolution.
But on considerably bigger screens it will not look pretty.
So, is there good approach to determine how much text to place on each page of the PageView and to scale the font size according to mobile device size and screen characteristics?
Also, I will appreciate if anyone suggest better way to compose such book-like mobile app with Flutter(using different set of widgets).
Thanks for your time.
#Milenb If you can add text pagination then I think it will solve your issue. You wan't need to scale down/up on the basis of screen height. If you look in to this thread then you will know how to do this.
I am developing an RSS-reader-type application. I am toying with the possibility of using a normal TableView application but showing the articles as a film-strip. I am mainly thinking for an iPad application (but possible it works on the smaller iPhone as well).
The idea is to have the cells passing/scrolling across the screen using swipe touches (but horizontal, and not vertical as with the normal TableView). They will be some-kind of miniatures of the full article, and when tapped (or with multi-touch zoom to have better control) can be enlarged to read. Then can then just be be moved on as soon as the user has seen enough of it.
Does anybody know if there is an easy way of accomplishing something like that?
The most obvious solution that springs to mind would be to use a UIScrollView, as this will provide the inertial effects, etc. for free - all you'd have to do it populate it with the relevant sub-views. (UITableView's actually use a UIScrollView.)
For more information and sample code, see Apple's UIScrollView docs.
If you want horizontal scrolling, take a look at Jeremy Tregunna’s JScrollingRow. It’s open source under a public domain licence.
I'm looking for a way to create kind-of an article reader which would have 2-3 columns of text which could occasionally wrap about some image. Just like it's done in "New York Times" or "Wall Street Journal" and other iPad applications.
Also, that text should be paged and every page should have UITableView at it's side (just like in "Wall Street Journal" app). But that looks like an easy part.
What would be the best approach to do such thing? Use UIWebView with CSS3 multi-columns (seems easiest, but will it work properly) or there is another obvious way I don't know about (and google doesn't help either)?
Edit:
One more thing, if it is possible use UIWebView with CSS3, then how about calculating required UIWebView width to "columnize" it properly? As I've experienced in the past text height calculations are painful and now we would have to deal with some wrapped images too.
If you’re doing it with CSS, then try -webkit-column-count:n, it might help. Otherwise, since iPad has iOS 3.2 which brings Core Text, that might also help.
However it seems that column-count arranges a block of text so that it is laid out with a certain number of columns, while its height can grow beyond the bounds of the screen (page).
1) I want to create a List by touch and dragging icons from a Master List.
2) Also have the ability to Delete items in this newly created List or Rearrange their order.
Is there some code sample one could look at or possible design pointers on cleanly accomplish this functionality.
I realize UITableView could accomplish this. But doing it visually in a single screenful is intuitive as it maintains the overall context of the task at hand.
Thanks
None of the API UI classes will let you do this. Both tableviews and scrollviews want the entire screen. You're going to have to write a lot of stuff from scratch.
I think you will find that a dual list design is a poor interface choice. You really don't have room on an iPhone screen to display and manipulate two list within the same view. Remember as well that you won't be able to see all of both list if they run off the screen (which is likely.)
"Intuitive" is just marketing speak for "familiar". There is nothing intuitive about a nonstandard interface. Since iPhone users don't routinely drag items between list it will not be readily apparent to them how to work the interface. You will most likely be better off with a single master table in which users can check individual cells to be added to a sub list. This is a common interface on the iPhone and therefore more "intuitive".
Before spending a lot of time on this, I suggest you do a mockup that will display on the device itself. You can simply draw mock interface in a graphics program and then display it as an image in an imageview. This will let you test if you can display enough information in dual list to be useful and whether you can hit elements in both list reliably.