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)
Related
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.
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 was recently using the app Secret and was observing the amazing user-interface that it has. If you are opening Secret's webpage, please scroll down a little to see the UI.
Being someone who is still a novice in Android and wants to learn, I would like to ask how that UI has been designed. I could ask a lot many questions in this one post but I will limit myself to just one for now.
Whenever you click on one of those tiles, it opens up and shows the comments for that particular tile. The other tiles below and above disappear. When you click on the tile again, it smoothly animates back to its position and the tiles above and below come into view. How is this achieved?
What have I tried so far? Nothing, because it is a "where do I begin?" question.
This is probably an instance of a custom activity transition (and a particularly well polished one).
In general, you can use the overridePendingTransition() to specify an animation that must be run when the current activity is changed (a classic example is sliding in a new Activity from a direction, while the previous Activity exits in the opposite direction). However, these transitions generally do not share UI elements.
Chet Haase has done a few DevBytes (in particular this one) to "simulate" an activity transition that shares an UI element (i.e. a view) between the caller and called activities. For example, if you have a Gallery, and you click on an image to show it full-screen, you would probably want the image to "grow" smoothly until it occupies this new position. The trick to achieve this is to actually disable the standard transitions entirely and include in the Intent used to start the activity the information about the current position and dimensions of the view that you want to "share":
Intent subActivity = new Intent(this, PictureDetailsActivity.class);
subActivity.putExtra(PACKAGE + ".left", screenLocation[0]);
subActivity.putExtra(PACKAGE + ".top", screenLocation[1]);
subActivity.putExtra(PACKAGE + ".width", v.getWidth());
subActivity.putExtra(PACKAGE + ".height", v.getHeight());
startActivity(subActivity);
overridePendingTransition(0, 0);
Therefore, the new activity can extract this data, and with this information and the knowledge of where on the screen the view should end up, can build and execute an animation that simulates the desired effect.
This technique can be difficult to implement if you want a complex animation, so in Android L this was baked into the platform itself: Activity Transitions can handle this automatically and provide a few built-in animations to act on the remaining (i.e. non shared) views. For example, the explode transition seems to be very much like the one you describe.
Regarding layouts:
You might find it helpful to use hierarchy viewer, which offers a function to capture the layers of the UI and store them in a Photoshop file. This gives you a good idea how the layout of a particular app you are was created and what kind of views were used.
Regarding animations:
Checkout videos by Chet Haase and Romain Guy who discuss graphics and animations in detail.
You can start with the Android training guides.
This one is an overview of designing with media and animation, but this one uses a ViewPager to achieve the effect you want.
As I've started to adopt Fragments more and better but also as Fragments functionality is increased (Fragments in Fragments, MapFragments) I'm starting to reach a point where I need to define when I should make a new View/Action as a Fragment or as an Activity?
An Activity is defined as:
An activity is a single, focused thing that the user can do.
But a Fragments have kinda taken that definition instead as described in the docs:
For example, a news application can use one fragment to show a list of
articles on the left and another fragment to display an article on the
right—both fragments appear in one activity
This is two things the user can do in one Activity with two Fragments.
So I'd like some input/help to figure out what is the best approach to decide if I should make a new action/view as a Fragment or as an Activity?
The answer depends on you and your development practices (or those of your company). However, my opinion is this: At a minimum, if you think the functionality being developed could be used within multiple Activities, or if it could ever be used in an Activity alongside another view (as on a tablet), then you should make it a Fragment.
We've recently adopted the philosophy of creating Fragments in all cases. Our Activities are now just top level coordinators, basically the glue that brings things together. This makes for a consistent and flexible architecture. This is important to us as we have numerous engineers at a couple of locations working on code.
An Activity is defined as: "An activity is a single, focused thing that the user can do"
That is more an issue of dated documentation than anything else. Activity has that same definition... when we are on a smaller screen size (e.g., phone). As you move up to larger screens, the odds of an activity being more complex than "a single, focused thing" increases.
So I'd like some input/help to figure out what is the best approach to decide if I should make a new action/view as a Fragment or as an Activity?
Here is my general heuristic:
If you anticipate that such-and-so piece of UI might exist standalone on a phone-sized screen, but be used in tandem with something else on a tablet-sized screen, make it a fragment.
If you anticipate that such-and-so piece of UI will always exist standalone, just create a simple activity.
If you anticipate that your ability to anticipate is not that good, err on the side of making more fragments. For example, you might say, "well, help will never need to be alongside anything else" and make it be an activity. Then, if you realize that other pieces of UI might benefit from the help being side-by-side with them rather than off on its own -- so the user can read the docs and perform the actions at the same time -- you will regret not having made help be a fragment, as you will have to do some re-work.
If such-and-so piece of UI would never exist standalone -- in other words, if it is more like a single widget than a full activity -- and you anticipate using it on multiple projects, make it be a single widget, in the form of a custom View or ViewGroup.
But, as jsmith indicates, there is no universal right or wrong answer. BTW, AFAIAC, jsmith's answer is the correct one here, but I was going to be way too wordy for a comment on his answer... :-)
I've been developing in Android since 1.5 so I have been developing from quite some time Activities and recently Fragments.
Quite frequently fragments left me with a sour taste in my mouth... an example was when I needed a kind of paginated Dashboard with buttons. For that I used a ViewPager + 1 fragment per button. I had all kind of problems because before Android 4.2 fragments couldn't be nested.
Another problem was the asynchronous mode of function of the fragments that when the needed to be moved from one place to the other quite rapidly it had all kind of misbehaviours.
Don't think that all was bad... in more simple cases, the use of fragments worked quite nicely.
So, in my opinion, whenever you have an area that is self-contained, that isn't moved frequently on the views, that can be reused in several screens and also you support tablets (or my in the future), use it.
If you need nested fragments, views that are re-arranged quite frequently, or code that will not be reused, don't.
I've created a custom navigation bar for my application. One of the things it (currently) does is allow you to switch between various activities in the application. One part I still have yet to solve fully is how to keep the navigation bar constant on the UI while the view above it switches to another activity.
This google groups thread seems to ask this very question and the solution seems to revolve around using a LocalActivityManager to add the Window decor of the new activity to a ViewGroup of your current layout. I'm curious if anyone has done this before and what their thoughts were?
In particular I'd be interested in the pros/cons of the LocalActivityManager/multiple activities approach vs one super activity which switches multiple views (rather than activities).
I would guess that Fragments would be the recommended way to accomplish this now: http://developer.android.com/guide/topics/fundamentals/fragments.html They have a lifecycle like activities but are meant to be added and removed from layouts. With the compatibility library (http://android-developers.blogspot.com/2011/03/fragments-for-all.html) you can use them all the way back to OS v1.6. As a bonus this is the way that the OS has been moving in terms of reusable UI components since v3.0, so you should be in better shape for the future.