I'm about to make an app that involves a lot of screens, its data structure is a tree with 4 levels and 84 final nodes that will contain check boxes at the end, I was thinking in using fragments but I dont want to make all that fragments, I am thinking there must be a more efficient way like to make a dynamic fragment that could load all the information (like text for the title or the check boxes) from a server or a data base, any ideas or suggestions for what could be easier and more efficient?
Related
I've read several SO posts and gone through some tutorials and now I'm trying to re-create this: http://i.imgur.com/on2xi72.png However, I'm not sure if what I propose to do is the best way to re-create this layout.
Here's what I'm proposing to do:
I'm working with this well nested JSONArray and JSONObject and vice versa API response (example data: https://jsonblob.com/5525b47ae4b0599c1fbd338b). I was thinking that I would create 3 different types of fragments to show the bullet point data. For example, one fragment would display "High Knees .. 25 yards" Another one could be a hyperlink type like in the case of "Shoulder Shrugs", and the final one would display the chart like the one at the bottom of the image. Since the API response separates data by a title like "Warmup" , "Upper Body Circuit", I was going to create a "block" activity that could contain the title and its related fragments/bullet point data. All of these "block" activities separated by the horizontal black lines would then be placed in another "full view" activity that would display stacked top to bottom. This "full view" activity would then be stored in another array because there are different dates to swipe through (if you notice at the top, it says Tuesday). Also, for each of these layers, there could be any type of variation and amount of data depending on the API call made. I hope this makes some sort of sense, haha.
Thank you for reading my post.
You can have only one activity per screen view in an android app, but can have several fragments per activity. Visual separation of your screen sections does not mean you need to have different fragments per sections in your activity. The reason you would want to use separate fragments is to be able to switch out the content of each fragment independently based on some application logic.
However, - if I understand it correctly - in your case, there is no reason why you would want to use multiple fragments per activity, as all your data is going to be changed as a whole based on the user/calendar day. Therefore, you can just use a single activity, or even better, use one fragment in your activity.
For your reference, this CodePath guide on Fragments may help you better understand fragments and how to use them. If you would like to read up on Activities more as well, you can do so on the android developer guides.
Android Studio 0.8.10
I have developed an App that has 3 fragments. I have just used 1 Activity and when I want to display a different fragment I just replace the existing fragment with the one I want to display. However, as I have 3 fragments now, and maybe more in the future, I think this will get harder to manage.
I am just wondering what is the design pattern when programming with multiple fragments, should each fragment have its own activity?
I will be scaling this to Tablets in the future, so I am not sure what impact this will have if I stick with the multiple fragments and single activity.
Many thanks for any suggestions,
should each fragment have its own activity?
Yes, but you can also use nested fragments.
I think this will get harder to manage.
you are right but
i think you must match your app with some other widget for example if you have multiple fragments that want to show one after the other use viewpager or you can use horizontalscrollview. you can create tabs and sync them by viewpager and so on.
Yeah, this can be really hard to figure out. I think a pretty good analogy, from the web application world, might be a servlet and a frame.
An Activity is like a servlet. It is one page in your app's workflow.
A Fragment, on the other hand, is like a block of content. It might appear in several different contexts and it might be served by several different servlets.
In MVC terms, the activity is largely part of the controller. A fragment, on the other hand, is more like a view include.
Much of the time, those two concepts align. A page in the workflow frequently contains exactly a single block of content. As you have, wisely, noticed, though, when you get more screen real estate (on a tablet), it is entirely possible that a single activity will display more than one fragment.
A single activity, on a tablet, might show, for instance, both a list of selectable items, and the details for the currently selected item in that list. When you have less space on the screen, though, those two things would be displayed as separate workflow items. Clicking on an item in the list invokes an entirely new activity.
The content is constant. The workflow changes.
Most modern applications will use a Fragment to display Activity content. It makes the application more flexible and easier to adapt to wildly different screens.
Lets say I want to create an Android app which shows a list consisting names of 200 people on the main activity. When users clicking on any name, they are taken to a screen showing the available info about that person. The details about each person may vary(some don't have an address, etc).
How will I tackle the issue of 201 different layout files(xml)?
I don't think it will be a good idea to make 201 activities.
If I use Fragments then I'll have to make 200 xml as well as 201 java files(for each different fragment).
If I use layout inflater or view switcher, even then I'll have to make 201 xmls.
So is there a way to strip down the number of layouts that will be required?
Are the layouts for each of the person different aside from the data e.g. address, name, etc. changing? Because if they aren't different you can use the same layout for each one of those people and just load the corresponding data of each person. If you can give me more information about how you store your data and how you display it I can give you a better answer.
No, you don't need that many files at all. In fact, all you need is your main screen containing the list of people, and then a screen containing the placeholder of the details.
When the user is clicked (presumably from some sort of listview) you can pass the details related to that user into the details activity where you can display it nicely, so reusing the same class/activity/layout.
This is a good tutorial showing you the basical mechanism of passing information between activities.
http://www.javabeat.net/how-to-transfer-data-between-activities-in-android/
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 developing an Android Tablet application with Android 3.1 SDK.
I have to implement a form in an Android Tablet. Now I'm doing on one screen with TableLayout, TableRow, TextView, Spinner, buttons, etc.
At this moment I have more than 80 views and then I get a warning about it.
The form is divided into sections and I think I can divide it into tabs but I don't know if I will have the same problem (I'm very new on Android development and now I learning how tabs work).
What do you recommend me? I will have, probably, 160 view or more.
I recommend that you split this huge form into multiple screens / steps somehow, it seems much more useable and managable to me. You could use fragments to hold the steps, and use some paging mechanism to navigate between these fragments. By switching fragments and saving their state you can keep the number of Views on the screen relatively low.
Check out the ViewPager component for this to navigate between fragments by swiping. Or you may use the plain old button based navigation (next/previous step e.g.).
If you really need to display all the form elements on one screen and want to keep the number of instantiated Views, you may be able to do this by using the virtualizing ListView, though it seems quite awkward to me. ListView constructs the rows as needed during scrolling, and you need to tell its adapter that you have X type of rows where X is the number of form-parts.
Why don't you logically break this Enormous form and using something like a Next button show the form in multiple activities. This would keep the screen clean, won't bombard the user with too much of information and finally won't give the warning of excess views on screen.