I would like to ask you guys/girls, if somebody have any idea how i can achieve a two activity transition in honeycomb, where the the not used activity will be visible a quarter of the original size and the other activity will be place to the center. Also i need to mention i used activities smaller then the screen resolution with dialog theme to get them to the center.
I looked into the ViewAnimator, ViewSwitcher, ViewFlipper, but i`m not sure if can do that. (Sure need to override this classes)
Somebody have any idea ?
You cannot have two activities "active" at the same time so showing any proportion of one activity and another and interacting with both is not possible, if you don't care about interacting with both simultaneously you might look at the SlidingDrawer class, a lot of people have customized that.
It is possible to kind of fake what you are asking by using two layouts and changing their proportions/position at runtime, for instance you could have a layout that takes up the entire screen, then on some event it could be re-positioned/sized and a hidden layout shown.
That is if I am understanding your question correctly.
Update
Also have you looked at fragments?
Related
I am building app right now. I am trying to follow all design patterns and google suggestions for building responsive apps.
Firstly, my app will contain navigation drawer.Of course my app will have several activities. So I have searched the best way to have navigation drawer on all activities, I found that the most correct way is to use some BaseActivity class which will have navigation drawer in its layout and framelaout for storing each activity representation(container for fragment). It can hold fragment, but the problem is that only one fragment.
So I have faced this problem. I am going to design following activity
So as in the picture I wanna to have image slider at the top , and some other layout parts under this slider for example grid layout, list or something other.
I think it would be better to separate image slider and other part, for example when my scree will be in landscape orientation it should be replaced but something other.
Futhermore others activites also gonna to have several independent parts for example list and anything other widget.
But as far as my activities should extend BaseActivity class, they would have only one place(container) for storing fragment.
I have tried to think about ways to solve this problem , and I have only one idea is to create several fram layouts in base activity(equal to max fragments used on child activities) and setting them visible and invisible depending on needs, but this approach pretended to be only way of hidding problem.
I don't know what is the most correct way to implement such type of application, so I need help or advices from more experienced developers to build my app correctly and bring user good experience.
I hope you can help me.
Thanks.
To start with, the container in your BaseActivity does not have to necessarily be a FrameLayout. For example it could easily be a LinearLayout with android:orientation="vertical", so that all fragments you add in it will stack one below the other.
Also each fragment can has other nested fragments in itself (although that's generally not the best practice, as usually it indicates some bad UX decisions).
Both those said, I think you just use the first point I made here. Now if you choose this one, I'd expect the question how to handle tablets and other big screens? Best way to handle them is to create a new landscape layout for your BaseActivity, where the fragments container might be different, for example a RelativeLayout, a LinearLayout with orientation="horizontal" and so on.
Good luck!
In an app I am working on, I'd like to have a bar with some controls always present at the bottom of the screen. It should overlay every activity in the app but also be able to disappear and reappear. To do this I've considered some options, such as simply using a linear layout and setting the visibility in every activity or using a fragment somehow. Probably those would work but I feel there must be a better solution. So my question is: what is the best way of doing this?
There are two ways you could do this. You could just use Fragments, and make your overlay be a fragment.
The other way would be to sublcass Activity with an AcitivityWithOverlay, which handles the overlay appearing and disappearing then have all of your activities inherit that. If I did it this way, I'd make my overlay a singleton so I wasn't creating extra versions all over the place that did the same thing.
I'm building an app where you can edit a detailspage. Right now I set the visibility to GONE and to VISIBLE because all the Views (for showing and for editing) are in the same xml file.
That makes more than 80 views, so I got a Lint message that this causes bad performance.
My Question is cann I use ViewFlipper (and is it possible to use two xmls for this) or do I better make use of two Fragments?
(fyi: I am also planning a animation between showing and editing, if that changes what I better do)
thx in Advance
You do not need either: a ViewFlipper or two fragments introduce unnecessary complications. I would separate showing and editing on different layouts (one XML file for each), and construct a different activity with each layout. When the user clicks on "edit" start the new activity (with an intent) and go to the edit screen. Then after saving the data just finish() the activity.
That is what we do, and it works great! Sometimes the "easy" solution is the best one, as in this case.
As to the animation part, there are already great answers here on Stack Overflow, such as here or here.
In case you want to keep the ActionBar while you animate between show and edit, two fragments would seem like the way to go. You can also have two layouts and inflate them independently, so that you don't accumulate so many views in one layout. Keep in mind however that (unless you create the ActionBar and fragments yourself) you will be limiting yourself to Honeycomb 3.0 and beyond.
I've recently started developing Android Apps, and whilst the model is making more sense the more I look at it, I cannot do something (nor find any reference material on it) which to me seems quite simple.
I have an activity which has five buttons along the bottom, and a blank View taking up the rest of the screen. I want, upon clicking these buttons, for an activity to be opened in (and confined to) this view. I can get a new activity running without incident, but this opens in a new screen.
If anyone can show me an easy way to launch a (sub/child?) activity within a view which is defined in the parent activity's layout xml file - equally, it could be created in the parent activity - you'd really be doing me a favor!
I'd recommend taking a look at TabHost. The tabhost is an Activity itself, and the sub-views are all Actvities as well.
Here is a good tutorial that'll get you going very quickly. There is a more work to create (optional) icons for the tabs (also describe in the tutorial).
Hope this helps.
Edit* You mentioned buttons being at the bottom of the screen. Take a look at this SO Question
You can achieve that by using an ActivityGroup... here is a simple example which shows how to do it using a TabActivity:
http://web.archive.org/web/20100816175634/http://blog.henriklarsentoft.com/2010/07/android-tabactivity-nested-activities/
Of course, you will have to change the code since you are not using TabActivities. Just take a look at the getLocalActivityManager and getDecorView methods that is what you will be using.
Sorry, I know that this topic has been covered a bit. I've read the related posts and am still a bit confused. I am working on an app that while the prototype will have 3 main screens, it will eventually have dozens. Each screen will present either dynmically changing status or take user input. To visualize, it is required to be laid out similar to how MS Word or a typical PC is. It has a status bar at the top and a navigation bar at the bottom that is common to all screens (slight tweaks for some screens, like different icons) in the middle is what I would call a view pane that needs to be updated with a applicable layout.
The status, nav bar, and each screen are defined in their own layout xml file. For my first swag at it I just used a ViewFlipper and loaded the 3 screen layouts into it. However that means that currently I have one main Activity which will not be maintainable as I continue to add screens.
It feels right to me that each screen layout should have an associated Activity class that understands how to control that screen. I need to figure out how to load that into the center pane dynamically. However I thought I read in another post that using multiple Activities can be a CPU and RAM drain.
Currently I tried making one of the screens it's own Activity and kick that off from the main Activity by creating an Intent and than calling startActivity. However that causes the new screen Activity to reside on top of the main Activity. The interesting thing is that then pressing the back button dismissed that activity and returns me to the main.
So far I haven't figured out how to setup having a different Activity control what happens in the center pane.
If I continue down the multiple Activity path, should my main Activity be inheriting from ActivityGroup?
Are using View classes more applicable in this case?
I know this has been a long post. I'd appreciate any advice.
Thanks!
CB
As you noticed, Android will implicitly track a stack of started activities in a task, and the 'back' button ends the top one, reactivating the next one down. I would advise you to think about which kinds of things the user might expect the back button to do, and make it so that activities are separated along those lines.
I haven't played with ActivityGroup so I can't advise you there. If you go with completely separate activities, you can have them all use the same "shell" content view with the common nav/status bar. Have a superclass or utility class handle populating and managing that from there. Then use a a LayoutInflater (you can call getLayoutInflater()) to fill in the middle with your Activity-specific view.
If you want one of the activities to have multiple screens, you might still end up with a ViewFlipper in the center slot. Again, you want to have an Activity transition wherever you want the user to be able to go "back"; that also means you may NOT want to have a change of activities in cases where screens are closely related or part of the same logical thing-being-done. (You can override the back button's behavior, but unless you have a good reason to, it's best to just arrange the app so that Android's basic setup helps your app's UI rather than working at cross purposes.)
If you want to use activities in the fashion you talked about, you might look into using a tab activity. It actually works in the way you want, you just need to hide the tab widget and put your navigation bar there instead. Or, you could go a little deeper and make you own similar tab-like ActivityGroup like Walter mentioned if you have more time.
You could use a view pager with fragments to accomplish the flip between the different views but still allow your activity to have full control over it. The activity can control the menus while the fragment controls your viewing area. This way your back button will properly dismiss the activity containing all pages related to the activity instead of walking down the stack.