I'm creating a mobile app that will show images to a user, abit like twitter,facebook,instagram etc. What I've noticed is that they often use infinite scrolling. I've been considering going this road but at the same time I've never really liked infinite scrolling as it feels like i'm not getting anywhere and it makes me kind of exhausted quickly. Therefore I'm considering making a paging variant of infinite scroll that instead. When the user reaches the bottom, he/she automatically gets to a new page and the scroll is at the top again. By getting back to the previous page he/she must just scroll upp and the first page will load and the scroller will start on the bottom of this page.
I know this question could be answered in many various ways and it's alot about personal preference but i still figured i put this out here to see what you guys think about this topic. I've seen some similar question but mostly regarding websites.
Question:
what do you think suits best in mobile devices(infinite or paging to load more content, keep in mind that the user isn't searching for any specific item in the list just simply scrolling) and why?
Thanks!
I think you should go for infinite scrolling, as you said user is not looking for something specific, so user would prefer scrolling until he gets bore. Just like FB posts, you scroll down to the end and it then fetches the older posts. But paging should be used just like FB for the better performance.
The idea of new page isn't much nice as when user scrolls upwards he believes that it's just continuous and wouldn't like to take on new page every time he reaches to the top or bottom.
Related
I was looking for some auto event capture for every screen and button clicks without manually putting them on every single button or Activity/Fragment and I could find few. But I am really curious to know what to going under the hood and how are they getting these info about screen views and button clicks.
Looking for some tips to create my custom auto capture events in Android App.
You just have your tracking logic in global screen renderer, or button click listener, using whatever available there (screen ids, button ids, class names) to put in your events.
However, this only works if you don't hack around and always use the same methods for rendering and navigations.
Soon enough, the product owner will ask you to make a transparent screen, or to have a screen that flows from right to left, or a screen that opens only to a 1/3 of the screen, or a pop-up, or an overlay, or a weird iframe. You'll have to have defined tracking for those separately.
And then, on top of that, the Analytics team will donate their bit of discord where they don't want to see transparent screens as new screenviews, but also track red buttons differently from green ones. And Toggles should be tracked differently too. By the way, the screen class names aren't useful for analytics, please name them manually. And also, buttons that look like links should be tracked this special way. And don't track the buttons that are just tooltips. Oh, the iframes. The iframes issue messages on activity in them, so listen to those and translate them to events please.
Now, this is an example of what it's going to be like. In real life, it's even more than that. If you have to add an exception for your universal tracking every time Analytics doesn't like it, you will end up with a mess of nested logic that is impossible to maintain. Also, every change to it will cause more bugs in unexpected places than fixes.
Still, universal tracking makes sense when you don't have dedicated analysts or a large marketing team and so you don't want to be able to answer complex business questions frequently.
In all other cases, it's better to hardcode analytics in a structured manner, maybe mapping screen ids to screen names in one neat place, then have analytics sdk wrappers to store the core logic and make use of the name mapping,
As many other Ionic developers I'm experiencing slow state changes on Android. My problem; it takes a few hundred milliseconds before the app starts to make the transition. I'm using native transitions and crosswalk, so the when the transition is being performed it's smooth.
My best guess is that the timeline looks like this:
1) Button is pressed, activating the state change.
2) App loads the new state
3) Transition being performed to the new state
Step number 2 is what seems to take a few hundred milliseconds, and I really thought this would be solved by Ionics view caching, but it didn't seem to make any difference.
My views are mostly static, so my idea is to find a way to cache the views properly, and manually trigger when the cache should be cleared.
Do you know how this can be done? Or if you have a better idea of how this can be solved, I'd really appreciate it if you could share your advice.
I've been asked to create an app for a client which could potentially be on both android and iOS (concentrating on iOS first). So I thought that Qt may be the answer. I would like to use Qt Quick to create the app but I can't seem to find a way to efficiently handle multiple pages, baring in mind that each page could be fairly heavyweight.
So far I've tried:
Pagination with loaders i.e. dynamically pulling in the needed screen. This works but there is a noticeable delay the first time a screen is loaded
Making each page a component and showing only the necessary screen. This loads all pages on startup which is too memory heavy
Making each page a component and displaying them through a ListView. Same problem as above.
There has to be a middle ground where views can essentially go to a low memory mode like in native iOS apps. Any suggestions welcome.
NOTE: The progression of the screens is not necessarily linear
My experience with QML is rather limited but from other UX experiences I would think the solution would involve re-factoring your pages to utilize the Loader item for their inner children/Components. From what I read it sounds like you are using the Loader item on each page itself.
For example, when your program starts load in your pages, it should be pretty light on memory otherwise there many still be large components that need to be dynamically loaded.
When the user provides input to go to a specific page, animate/show as you would normally which shouldn't be delayed. The page itself should then utilize a Loader item for each component that needs to be loaded (i.e. ones with large memory footprints).
While components are loading you could show a progress bar/wheel animation. Once the component has finished loading via the onLoaded signal you can hide the progress bar/wheel.
You may also want to look at the Loader item's asynchronous property to ensure any animation (i.e. the progress bar/wheel) while the component loads avoid glitches.
Finally when the page needs to be hidden simply set each Loader item's active property to false and it should release the loaded component.
Hope that helps and isn't repeating something you've already tried.
Old question, but Qt.Controls's StackView has support for pushing and popping with various animations.
As the previous answers indicate, using a Loader is also an option but it doesn't let you easily animate the change (when changing views, the old and new are not available at the same time so you can't do nice animations).
An alternative is to use Components, lazily instantiate views and animate the transitions. Check out the example in by QtWS 2015 talk, slides and code available here.
The Google Chrome Android app has some interesting header behavior. If you open a tab, do a search, and then start to scroll down, the header containing your search will disappear. You can scroll to all the way down the page, and then as soon as you start to scroll back up the header is the first thing that scrolls back into view, and then further scrolling will scroll you back up the page.
I'm sure there is a library or something somewhere that replicates this, or there is a way to implement this.
Sorry if this is a duplicate question. I've been searching for this for ~30 minutes. It's difficult to put into words.
Thanks!
This pattern is called a 'Quick Return Bar', as described in Roman Nurk's Google+ post and implemented in this code.
I have a quiz app which loads questions into a textview, answers in radiobuttons which is wrapped in a scrollview. Currently I'm using next and previous buttons which work but I'd rather use swiping to control that. How do I implement this so that I can get animations of the page being dragged kind of like the tabs in the google play music app.
I've googled around and seen viewpager used a lot, but I don't know if that's right for what I want to do. I've also considered using viewflipper but again I don't know if that's right. And I wouldn't know how to use either of those in an animated drag fashion.
There's the possibility of hundreds of questions one after another which might be a factor.
Thank you!
How do I implement this so that I can get animations of the page being dragged kind of like the tabs in the google play music app.
Use a ViewPager.
There's the possibility of hundreds of questions one after another which might be a factor.
Rewrite your app to not ask the user "hundreds of questions one after another", then. Having a single quiz that long would be annoying in any medium, IMHO.
From a coding standpoint, depending upon what else is going on in your app, memory might become an issue using ViewPager, ViewFlipper, or pretty much anything other than a single set of radio buttons whose captions you change as the user moves from question to question.