I'm struggling to implement the expand feature of the card view described by the Material Design for Android.
In their design guidelines they show off different layouts for the Card component, but one example shows a card transition to fullscreen onClick.
This is the transition shown on their website:
I've tried out implementing a feature like this, but it would require much more work than what their guideline examples are suggesting... How does Material Design accomplish this? Is there a built-in feature for this, should I just manually translate and fit the card to fit the screen, or should I use an entirely new fragment or activity for the full-card-view?
Here are the Design guidelines, which contain that example, but nothing is said about the transition, neither on the documented Develop page, which is minimal really.
TL;DR
In the case of the gif image you've attached above, the RecyclerView and the detailed CardView should have their own separate Fragments which are operated in one single Activity.
Jump to the links at the end for the animation part.
Detail
Why so? Well, we had three choices:
Keep both Views in one Activity and overlap the detailed CardView on top of RecyclerView on click event. (This one is stupid, and not a good practice)
Create separate Activities for both Views (Recycler & fullscreen-Card)
The one I mentioned above.
RecyclerView and Detailed View shown as two separate Fragments
Now the reason for not choosing the 2nd option was because it is more performance intensive as compared to the 3rd one. We may not notice this in a small scale app but it certainly makes an impact when the app scales. Plus, creating fragments is more effective as we are sharing common views and variables in between the Views. So the best choice is number three. Note that this isn't a universal case and the usage will differ according to your requirement.
Using Fragments can be overwhelming at first but it keeps the code more organised when you get a hang of it. You should try to keep your app divided into few broadly divided activities and within those should be as many fragments as you want.
Here's a few links that helped me implement the exact same thing you're looking for.
MDC: Material Motion
Implementing Motion with MM
Building Transitions with MM
Hands-on experience in Codelab
All three of them helped me gain a better understanding on how the whole Material Motion framework works and how to implement it in my program.
Related
I want to customize the FullWidthDetailsOverviewRowPresenter in the Leanback DetailFragment.
Three things I want to accomplish are:
Getting the Actions from top to below of the overview.
Reducing the height of the overview so that it the related movies can be seen without scrolling down.
The background image and the space it occupies at the top of the overview should be gone. The screen should start like the one above.
The end result should be like this:
I already know how to modify inside the overview. How should I modify outside of it?
Because you are moving around the key views of this screen, it sounds like you might have to ditch the current implementation altogether and create your own custom view from scratch. By moving the buttons to the bottom and the detail image (seems like you're moving it to the right side of the description text), you're making it less and less justifiable to even subclass DetailFragment. The developers of Leanback were probably intentional about limiting customizing the interfaces too much as they want a consistent experience for different apps.
I would create a new layout file and load it up on your subclass of DetailsFragment (or DetailsPresenter), depending on your architecture.
You might find inspiration in this tuenti tv sample and part two of Marcus Gabilheri's customization series
Create Row List Fragment
In 1st Row create a Rowpresenter that fits your design with buttons
In other row/s add ListRowPreesenter
So I recently have been reading into transitions and animations on the developer site:
Animation
http://developer.android.com/training/animation/index.html
Scenes and transitions
http://developer.android.com/training/transitions/index.html
I do not see the big differences between these and think they are relatively the same.
I know transitions are more of switching between views and animations are more for adding a wow factor by for example making a button pop up when holding your finger on it, However I believe there is much more to it then just these.
I am looking for a detailed answer if possible on the differences between the two and when you should be using each?
I came across this article the other day trying to find the best practices for doing animations while using data binding. The author explained 2 approaches, in which he uses animation (with BindingAdapter, see approach No.1) and transition (with onRebindCallback, see approach No.2) respectively. I think the summary/comparison he wrote at the end answers your question at a high-level, too. I personally think the most important points are that animations provide more fine-grained control while transitions are reusable (even if your view slightly changes).
Advantages of the BindingAdapter mechanism:
Fine-grained control — only the views you want to animate will animate
Less overhead than transitions (performance)
Very flexible — you can create whatever animation you want
Advantages of the OnRebindCallback mechanism:
Simple to use
Don’t have to use custom attributes (or override default behavior)
Can animate many things with the same code (see Transition subclasses)
I want to implement something like this. On tapping on a card, it should expand to show more details. I don't want any code but just some guide on how to go about implementing it. The transition should be smooth as in Google apps.
The way to recreate something like that, is to use shared element transitions.
Basically what this does, is connecting views between to layouts and when it switches layouts, the shared elements (views) are animated from the original position and size, to the final position and size of the other layout, creating a smooth transition between layouts.
For a more in depth explanation on shared element transitions look over here.
There is also a great Udacity course on Material Design, covering all these kind of animations and concepts in the form of short videos.
I am creating my app. I am trying to follow all google's guidelines. There is a great part of UI - Fragment. It is really great thing that makes UI smoother and prettier.
Of course it is better to split my screen into separate logic portions of UI which can be later reused in another activity, layout whatever...
Fragments are more lightweight than Activities. Animation between fragments is smoother and looks better.
All that is great. What about using one Activity per app ?
According to the Eric Burke You have to use Fragment whenever you can do this. Here is the lecture - Android App Anatomy.
Surely, using one Activity per full app can bring some benefits.
But of course there are some cons.
Let's consider simple app, it is not real app ,but just for example.
Here are three screens.
It is not exactly the same UI as in my app, just for make it easier to understand my question.
There several ways we can follow to build such UI.
Each screen is single activity with it's own layout.
Each screen is again single activity but all portions are fragments, for instance on the first screen. It will be three fragments : ViewPager, Horizontal List and Custom View. Second screen will have only one Recycler View fragment and so on.
Use on activity for all screens. In this case we also have several ways.
a) Use one container Fragment for whole screen and all widgets will be the part of one fragment layout.
b) Use one container Fragment but with nested fragments.
c) Use fragments without container and replace them all or some of them when we need to change UI, for example to change UI from first screen to the second we need to delete all fragments from the first screen and add one new fragment (list view), because we don't have the same parts of UI on these two screens.
All in all, I cannot decide for myself what and when to use, what is better according to the current guidelines, what can bring user better experience.
I am worrying about nested fragments, but if there was a bad practice, I think, google wouldn't add such feature into the framework. So may there is acceptable way.
I want to understand where it is better use Activity,Fragment or some mixture of them. There is no problem to write code for all this cases, but the main goal is to follow the best practices in building software architecture.
I will be really grateful for anyone who can help to understand this topic.
Thanks everyone who have read this to the end and those who can help me with this question.
What is the best way to go about designing an Android application that features quite a bit of formulas and conversions? I was thinking that multiple Activities with ListViews sort of like a tree with the leaves being the actual calculations. However, after reading Android design principles it's better to avoid a pure navigational structure and try to reduce the deepness of the app.
For example:
Main Menu
Conversions
Weight
Distance
Distance - Speed - Time
Calculate air speed
Calculate distance traveled
Weather
METAR
TAF
So by the 3rd or 4th screen we've reached the actual individual calculator. Does this make sense? And if it does, is there a better way of designing this (maybe using action bars or tabs)?
By using a very simple UI concept of Expandable Listviews, in which there is more than one child row for each section of the parent row, by tapping on the "Conversions", could expand into sub-rows, likewise for each section as you see fit, and treat that as a Main Menu in a sense of a word, that is, your main application screen.
The nice advantage is that the nesting of the menus in the Android way, is eliminated and can accomodate as many as you wish.
The third or forth screen sounds like it's too deep down the rabbit hole, how about instead having multiple tabs for each "type"?
For example;
[Conversions][Distances][Weather]
If you add an ActionBar to it, you could have a type of filter as the GMAIL app has (where you select the account) and use it to toggle the different "modes" so to speak.
Another approach would be to have it all in one screen, just that you switch the active layout (or perhaps Fragment) via the filter I mentioned above.
Check out the GMAIL app, and you'll see what I mean in terms of the filter. :-)