I'm trying to create a slide up effect for one of my Android Applications' Activity, similar to the Gmail app's compose Activity enter animation/transition, without the previous Activities' exit animation though. As per my research, there are two ways to achieve this:
overridePendingTransition(R.anim.slide_in_bottom, R.anim.stay) after startActivity() in Activity A and overridePendingTransition(R.anim.stay, R.anim.slide_out_bottom) after finish() in Activity B. Problem with this approach: I need to set listeners for the enter animation/transition in Activity B in order to perform further animations and I do not want to use some kind of guessed delay in onCreate(). Other than that, this approach works flawlessly.
Using the "new" (not really anymore) Activity Transitions API to perform a android.transition.Slide for both the enter and exit transitions of Activity B with the slide edge set to bottom. Problem with this approach: This weird seperation / individual transitioning of views is introduced when using this approach. (Not pasting any code here as it's not necessary, I'm using the Slide from a transitionSet in xml or the default constructor in code)
So my question is, is there a way to have an actual listener for approach 1 I don't know of or is there a way to eliminate that weird separation with approach 2 and if yes, how?
Put the views that should be animated together in a "Transition Group".
You can create a listener for approach #1 using Otto. Basically, that is an event bus that provides a mechanism that you can use to communicate with different parts of your application.
Related
Before I started working with transitions in Android, I was under the impression that transitions was possible from one activity to another. In other words, when you launch an activity from another activity, you could provide a transition with animation.
After just learning about transitions, this does not appear possible. The documentation indicates that transitions occur within the same activity. In other words, transitions just let you rearrange the view for the current activity.
So is it correct that transitions are limited to just a specific activity, or is it possible to transition to another activity? I can imagine the benefits of transitioning to a different activity, the most important being that when multiple developers are working on a project, each can work on their own activities without having to combine functionality into a single activity in order to create animated transitions.
I think this is what you're looking for
"activity transition in android"
cheers!
P.S:Check this other link if you wanna have a multipleviewswitcher :) http://www.malmstein.com/blog/2014/07/09/your-forms-dont-need-to-be-ugly-part-3/
I'm looking for the the best way to reproduce, in an Android app, the behavior of the iPhone UiNavigationController within an UITabBarController.
I'm working on this Android app where I have a TabActivity and 4 tabs. I've already gone through a lot of posts regarding the use of activities and tabs and how it's not a good idea to use activities for everything, which seems fair enough. I decided to use one Activity on each tab anyway, since it makes sense in my application.
However, in one of those activities I have a deep navigation tree with more than one branch and up to 12 different views the user can go through.
The problem is: Android controls the navigation through activities inside an app, if you click the back button it will go to the previous one, but if I'm navigating through views, using one Activity, and I click back, it just finishes it. So how can I have a smooth navigation behavior between views in an Activity?
I had implemented this using a TabActivity with FragmentActivity as each tab. Utilizing Fragments API you can organize the code just like you would be using 12 different activities, still using only 1 for each tab in fact. Fragment's framework will handle back key press for you to show previous fragment instead of closing the entire activity.
There are some problems with such approach, for example, there's no MapFragment, but the workarounds can be found here on SOF.
You will need Android Support Package if your minimum SDK version is lower than 3.0.
Well I know very little about UiNavigationViewController, but I guess you want something to navigate between different Views. As you are using TabActivity, every tab should load into a separate Activity.
But since you want to branch it out, using that many Activities is not a perfect solution, neither the ActivityGroup too. The better solution, as per my opinion(I have run into similar problem once) is to have the main or root tabs loads into separate Activity, but for their branches, use the ViewFlipper, which flips the Views. So the whole Layout(Subclass of View) can be flipped.
You may run into some problem while flipping more than two Views (as what people say, though I never had any problem). So in that case you can use layout.setVisibility(View.GONE) to hide the layout and just change it with View.VISIBLE for next view.
And about the concerns of back button, you need to store the last used View or Activity into a variable, and in the override of onBackPressed(), just need to call them.
There might be better solution than this, not that I can remember, but yeah it's the easiest solution I can come up with.
Im making a music player/library app in wich I would like a frame/toolbar on top of all other activities as a header. This frame/toolbar will show information about the current playing track and have some controlls like play, next and stop etc. and be a separate selfsufficiennt activity. Is this possible and if so, how?
You can create an ActivityGroup. This is how TabHost is implemented. So your ActivityGroup would fill the whole window and implement the toolbar. Then you could swap out Activities in the bottom part.
Currently I don't think that making a static top bar it's own activity in the life-cycle idea. However, what you can do is have every activity have the top bar and just re-create the bindings needed for each activity. It gives the idea that a section is static.
Now this breaks down if you start doing animations between the screens. Another solution is to just have a single activity and swap out the views. This allows for animations between screens be custom and only the parts that change need to create the connections they need. The trade off there is that you'll lose any kind of state saving and history that you gain by using an activity orientated approach.
I think you can do something like this on Honeycomb tablets as the fragments idea could be implemented like that but I've never explored it much.
I have a very simple 2 screen android app.
Is there any downside to simply switching out the layouts via setContentView or should i be using intents?Don't want to bugger up my app if something is wrong with this.
Another thing to consider is that activities form a stack. If you want to be able to go back to the previous activity via the 'back' button, then you need to use activity. But if it is something simple like a 'loading' screen when your app starts and you don't have to go back to it again, setting content view would be a much better idea.
Well as stated on Android Dev http://developer.android.com/reference/android/content/Intent.html
An Intent provides a facility for
performing late runtime binding
between the code in different
applications. Its most significant use
is in the launching of activities,
where it can be thought of as the glue
between activities. It is basically a
passive data structure holding an
abstract description of an action to
be performed.
Therefore if your two screens are 2 different applications I would say you want to simply use setContentView.
it will simplify your code when you want to pass info from one to the other views
There is nothing wrong with having two views in a single activity. This approach is more light-weight, as you don't need to go through the phase of stopping one activity and then starting another one. However, it will make your activity code bulkier. Consider now if you are going to need more functionality or more views in the future and if the answer is yes, then it would be better to create separate activities.
If the view is light-weight (a bunch of text boxes), then it should not matter. On the other hand, if the two screens are largely independent and heavy, you could use two different activities. The primary advantages with this approach are:
If there is an error in the second screen (an activity in this case), your application will fall back to the first screen whereas in the case of using the view, the whole application crashes
Better readability
Easier to add more functionality in the future
Which you think is the best way of doing a wizard like application (user can navigate between screens with a next and back button, and each screen has to save some state data) in Android platform.
I mainly can think in two approaches:
Having one activity+view for each screen and then i make the screen switch by calling each activity. What make this nice is that i can use the system back button as my back handler and i don't have to take care of that myself, aslo each activity will save it's own state.
Having one activity and many views, and what i switch views in each screen change, this helps me re-use more code, but makes saving states a mess.
What do you think? Which is the best way of doing this on Android?
This library is no longer being developed.
Use Android Navigation Component with combination of ViewModels to build a wizard flow.
I've developed a lightweight Android library, which is built on top of Android's ViewPager that can be used for creating wizard like activities. Check it out: WizarDroid.
I suggest going with 2 as it fits the goal of activities and views. Saving state in this case is easy - if you use the MVC pattern, you can simply have a model object that is passed along to the views. Each view will have portions of the model that it can read/write. No matter where you are, the model should always have the current state. If you get disposed, just save the model. Restore works automatically since you already read from the model when you show each page.
I've gone with the first approach as it seems more natural. Another app uses ViewFlipper for switching views but that's far from anything like wizard.
9 years ago this was obviously a very different kettle of fish - but I think the best way to do this now is with Fragments.
Have a Fragment for each 'page' in the wizard, letting it handle its own lifecycle and state.
Change page from within each Fragment with Fragment.getFragmentManager() - this returns the FragmentManager from the parent Activity, allowing the Fragment to replace itself.
I think 2 is better. Put each "page" in a view and then just alternate between showing and hiding them. Makes it trivial to do nice transitions. What state are you thinking of maintaining? The only one that doesn't work automatically would be focus and I think you probably want to reset that every time you switch pages. It is also trivial to catch back if you think that is the right behavior for your app.
With 1 you can reuse almost all of your code (just define your own WizardBase class) but I think activities are much slower to launch (and require more memory) than switching between views.