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.
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 need to design introduction walk-through screens when my app launches. It can be done by simple ViewPager or horizontal scroll view (?) but the additional requirements which are hindering me from using these are
A lot of animations on each screen
Animations will be bound to scroll position (i.e., current stage on an animation will be determined by how much user has scrolled, and it should roll back animation if user scrolls back without finish gesture)
Some items need to animate across different screens (e.g., There is a box on first screen, when user scrolls to the next screen, the box becomes larger without moving and a graph (a part of second screen) also comes into display under it)
I dont know if I explained the scenario well enough so please ask for clarification in comments. I need just a direction to control/approach/library.
Thanks
I'd recommend this library : ShowCase
In this way, you can make interactive tutorial and walkthrough your app.
You can also take this library and add some functionality.
Use viewpager, for each fragment you can use different animation inside that fragment, each fragment is independent from other views/fragments
You can use horizontal scroll view but it will take extra time and difficult to code
Seems like a ViewPager has everything you need.
I am developing an application which should display a number of tiles on the first page. Tiles are generated dynamically from json, each should allocate itself according to size specified in json and should take as much screen as required. Each tile represents short summary of information. The requirement is that when tile is pressed user is redirected to another page which provides more detailed info (like a form) which takes the whole page. User then should be able to go back to previous page and choose another tile if needed or go back to the first one. I don't know in advance how many tiles there will be and what are their components, so everything is dynamic. There is also a possibility that small tiles(with different info) can be required to be drawn on detailed view.
At the moment I am on the stage where all small tiles are displayed on the first page and I need to find the best way to display detailed view and allow user to navigate easily and quickly. Each tile extends RelativeLayout because of absolute positioning of components inside. I am considering switching tiles from Layout to Fragments because they seem to be providing flexibility required and many articles and tutorials I search refer to them. In this case when user presses the tile fragment, all existing tiles would be replaced with required detail fragment. Pressing back button would replace detail fragment with previous smaller ones on the screen (would it be display all of them or only one?).
Another option I am considering is to leave layouts and on tile press redirect user to a separate Activity with detail view. In this case navigating back seems to be destroying activity and it will need to be redrawn again if user wants to come back to it (redraw is not desirable).
My question is what is better for performance. Each tile as well as detail view might have some images in it and full page will take time to load. But figuring out how to handle this with Fragments programmatically might take a while and the last thing I want to find is that Fragments are not suitable. Maybe you have other ideas for scenario described? Any good tutorials/articles where Fragments are created and managed programmatically completely(no XML).
I am relatively new to Android and completely lost now.
Edit:
Thanks everyone for your advice. I can't choose the best answer at this point. I have to do some more research and learning now. Will do that later.
Fragment should be the best way to go. because filling details in a fragment dynamically is easy. will help check some codes i have written that could solve this
Fragments are a new style in Android for creating GUIs, they should not be compared with simple Activity + xml layout's in performance terms. Fragments were created to make it easier to build complicated GUIs, on both phones and tablets. You can create low performance GUI using both methods.
From your description I suppose its best to create two fragments, and wire them in Master Detail pattern. Master will be your json list with short summaries, and detail will be your additional data fragment. You can still put both fragments in separate activities, and show detail fragment from master one (master actitity will get hidden) - this makes sense on small screen devices. But you can show both fragments on one screen on tablets. See 'Master Detail Flow Template', http://developer.android.com/tools/projects/templates.html.
So fragments gives you a lot of flexibility to modify your UI, without huge code rewrites.
Some new widgets like ViewPager will work only with fragments, so if you want to use it you better invest time in learning them.
From what you have described above you do not need Fragments to do this. On your main page you can use a GridView to display your tiles. You could create two other Activities. One called TileActivity which will open each time a tile is pressed. Then you could create a PopulateActivity which would populate the TileActivity with the relevant information depending on which Tile was pressed. In terms of performance instead of closing the TileActivity to go back to the main page you could use Intent Flags so that the TileActivity isn't closed it is just added to the stack and then restarted instead of recreated each time its called.
I'd like to make a view in my Android app that flips between multiple views on a swipe/fling. I'd like it to behave more or less like the Android Launcher behaves when flipping between views. In particular,
It should flip views on swipe.
Generally a swipe will flip between one view and the next. It should not fling across all of the views.
If you swipe slowly, you should see the views dragging as you're swiping, eg. the way the Launcher does it.
I tried using a ViewFlipper with a GestureOverlayView as per Romain Guy's blog post here, but there's no indicator to the user as they're swiping. This makes discoverability difficult, which is presumably why Launcher does it the way they do.
I tried using a Gallery object, but when I swipe from left to right, there's a certain amount of momentum that flings the users through all the views rather than just taking them to the next view.
Is there a good way to accomplish what I'm trying to do?
I know this is an old question but ViewPager is created for this exact same purpose. ViewPager is part of android compatibility package and more can be found at http://android-developers.blogspot.com/2011/08/horizontal-view-swiping-with-viewpager.html
Take a look at HorizontalPager. It's actually based on RealViewSwitcher, which in turn is based on the Android homescreen's code, and supports snap-to paging with drag feedback, as well as nested vertically-scrolling subviews. Gesture support for fast swipes isn't all it should be, but this may get you part of the way there (and I'd welcome contributions back).
EDIT: As of 2012 you're much better off using Google's ViewPager - it's in the compat library.
Check out SwipeView within this project https://github.com/fry15/uk.co.jasonfry.android.tools It does exactly what you want it to do and is super simple to implement.
#CommonsGuy extended ViewFlipper to do it.
https://github.com/commonsguy/cwac-viewswiper
Ihaven't used this one yet so im not sure if it moves with your finger like the launcher if not your going to have to make an OnTochListener to do it for you in me.ACTION_MOVE you will update the view to change its position. I'll post some sample code when I get home if you don't get another answer.
In the Honeycomb sample gallery app, there's a layout that uses a two-fragment setup: one on the left of the screen showing titles, and one on the right showing the selected content. The titles fragment can be hidden with an animation.
During the hiding animation, the app asks the framework to recalculate the layout on every single frame. This way the content-fragment can take up the empty space that the titles-fragment leaves behind while it moves off-screen. This produces a great, dynamic effect, but is terribly inefficient I think.
I have fairly complex layouts, and I'd rather not ask the system to re-layout on every single frame. But I'd like a smooth transition animation like in the sample. Are there any alternative solutions to this problem?
P.s.: Just to be clear, I'm not asking how to do basic fragment-transaction animations. I know those, and AFAIK, those animations can't produce the behaviour found in that sample gallery app (another example would be the Honeycomb Gmail app, it has similar transitions that I'd like to achieve).
You can provide custom animations to the fragment system that do whatever you want. You can move the fragments around, fade them, etc. If these animations do not explicitly or implicitly cause layout (by changing properties that trigger a layout), then you should not get a layout on each animation frame. There maybe still be a layout call at the beginning/end as the fragments are added/removed, but the layout/invalidation process during the animation is up to your animations and what they do.