I'm working on an Android app, which when the user taps on an icon, a Layout defined (for now) in the main layout slides up with some information.
The problem is that I have icons of different types, so when one clicks on one type of icon or another, the information in the pop up should be different (there are different objects with different structures behind those icons).
What possibilities do I have? The programmatic way just does not seem elegant enough. Are there any templating frameworks in Android? Please provide some examples, too.
You could sub-class your icons (that means the types that are shown with each icon), like having each one it's own fragment sub-class, an then you can use a different layout on fragment.
Here is more info about Fragments
Related
This is the image explaining the usage of fragments. The first image shows two fragments and two activities.
Lame doubt. Why use two activities when the sole concept of using fragments is err.. using fragments instead of switching activities.
Depending on your goals you can do it either way.
The method shown in the guide can be implemented entirely in XML layout files so it is a better method to teach to a new user of fragments.
The method you suggest requires the developer to manage fragment transactions in code, which is not too difficult, but why do it if your app does not have any special behavior that requires the extra work.
Also, since the animated transitions between fragments look different than activity transitions, your method will reveal the use of fragments at the user level. The method in the guide uses fragments as a modular programming technique that is transparent to the user.
You end up with an app that uses available space on all device types, but on a small device it acts just like a classic app that users already understand.
The idea is that when you have extra room (such as on a tablet), you can display the content from what would have been two activities side-by-side rather than as two separate activities.
Think about a mail application. On a phone, you fn really only fit the list of mail on a screen, and you click on one to open the content of that mail on another screen.
If you did that on a tablet, there's a huge amount of wasted space; you can display the list of mail on the left side of the screen, and the selected mail's contents on the right side.
Because the list UI is the same in both examples, and the mail-display UI is the same in both as well, you can reuse that UI by including them as fragments. The logic for those UIs is also self-contained in the corresponding Fragment classes.
This allows the user to see more content with fewer activity switches.
I'm working on one dialog. It should have two listviews either two spinners either one spinner and one listview. The list on items in the second depends on the choice in the first one. And now I have dilemma concerning graphical user interface.
When I put two elements (ex. spinner and listview) in one dialog window it's looks awful and it's difficult for using. How to solve that? What would you recommend? If I use two different dialog windows, it will be difficult to switch between two lists, as I imagine that the user can change few times the selected option in the first list until he/she decides what to select from the second list.
Any suggestion? Perhaps you saw some nice solution in one of apps in the market?
you can either show it in two different dialogs without disturbing the UX
or
Why not try something like This or This
There are a lot of widgets out there (both from android itself and custom ones) that would solve your needs for showing the info. However I think that your problem is not the 2 lists but the dialog.
For a better user experience I recommend using an appearing/sliding-in layout or a prompt screen. An appearing layout is the one that appears below your "change this" title. It's not so disturbing as you can keep using the whole screen, you can add animations, you can customize it a lot to fit your app design... If your space is limited, you can always show a hidden layout containing your views. this method is a little more disturbing so fits better if you are starting a separate action, not filling information as the underlying views.
I am new to android development, and we have a very specific requirement.
We need to change the content/layout/flow of the app on the fly. For e.g. we have a layout which consists of some images, textarea and textboxes. There might be a request coming to change the textarea to a textbox.
We thought about this and are thinking to provide the apk with a json/xml which will contain all these changes.
My question is will it be possible to re-draw the objects again dynamically and change the content?
Yes this is possible. You can dynamically design what has to be displayed in your Activity UI screen. If you feel there are only 2 or 3 different UI screens that would be repeatedly used, then you can have XMLs for these screens and you can just change their labels in OnCreate() of Activity class before rendering. LayoutInflater class would be helpful here.
When you design a Android Application with Activities and Fragments your XML layout definition is always static. If you want a true dynamic layout structure you should use a Web View with a HTML content pointing some URL.
As Rahul says, another approach is to manage the "default cases". For me that is the standard way to design an Android Application.
The dynamic content (values) can be done with a simple http call to server you can get values for your views.
The navigation could be handled by switching Intents, but, definitively you have to associate these intents to UI elements like buttons in the most cases, and ¿How you can do that if your layout is changing over time?.
I think, that the WebView could be a very easy solution for your problem.
I'm currently developing a little application that uses a login screen and a main screen. I'd been watching how another developers had been made the screen switch, some developers adds and remove fragments on run time, anothers have an Activity for each view (in my case that will be a MainActivity with the main_activity layout, and the LoginActivity with the login_activity layout). And I don't know wich is the way to go. I think that have a fragment for each view will be the solution with more sense, but I want to listen some opinions before continue.
There might be others who disagree with me, but in my opinion, Fragments are better suited when you want to keep a part of the screen static and change something in the other part (analogous to AJAX in websites).
Activities should be used for individual views in those cases where there is only one thing happening on the application front-end.
On the other hand if you have a Gmail like layout (with static links to Inbox, Sent, etc. on the left hand side and a dynamic list of mails on the right hand side of the screen), Fragments is the answer.
But since you have two different screens for layout and main, in my opinion, it would be neat if you used different Activities for the layouts and used Intents to navigate around.
For two completely different Activitys such as Login and Main I think you want to use two different Layouts and two separate Activitys and no need for fragments. However, you may want to use fragments inside any of them as #swayam suggested depending on what you want to do inside of them. You need to look at the docs and decide which is better suited for your needs. No one can really decide that for you.
Activity
Fragments
I have a navigation bar with buttons which I would like to share between multiple activities:
Currently, when I start the same activity (for example, click on LOST.DIR) the whole screen changes, including the navigation bar (new list of folders appears).
I would like to keep the navigation bar static (to persist between same activity types and not to change or re appear after starting a new activity).
Is this possible?
It sounds like you want to use one activity and fragments.
But, if you really must use multiple activities. Another approach would be to use an actionbar, (actionbarsherlock is great for this) and have the menu switch between your different activities. The menu drop down can either be a list of icons on the action bar or a drop down spinner located in the top right of the actionbar. This actionbar will be static throughout your activities and consist of the same list of categories (i.e. the ones of your navigation bar).
Not straight away. Activities are exactly the opposite of what you want: they are independent pieces of interface.
You can use Fragments, or embed your activities in a master activity. TabHost does this, for example.
One approach for total control is to write your own custom class which takes a LinearLayout as a constructor argument and handles the visibility, click dispatching (via delegates), images etc of each button.
Add methods to do all of the above and whatever other functionality you need.
Create a layout.xml and it in each of your Activity layouts.
Instantiate your button bar class in each Activity and pass it the reference to it's layout that you get with findViewById on your content view.
As others have said, there are existing solutions and you might ask "why invent a new wheel". I have just such a class I use in many of my projects and it was a lot of work to do version one but now I have a class which I can totally control, add to, fix and customise with ease.
Something like this:
bar.setButtonClickHandler(Button.Favourites, favouritesButtonClickHandler);
bar.setButtonVisibility(Button.Edit, View.INVISIBLE);
etc
I've used a LinearLayout but if I have have the need to use something else, it's a simple matter to overload the constructors to accept, for example, a RelativeLayout argument.