In Android application, I have one request that aims to use one common Activity/screen in many screens or in overall of the application.
For example:
Screen A contains screen common C (to get better sense, it contains of list of items)
==> during the working on A, C might be modified to have add/modify/remove any items.
Now to to Screen B and in turn it contains screen C also.
==> request: C must be the same as one in A and the data is obviously the same.
One more request: it doesn't need to store the list items of C in the DB or in the preference since I thought the loading data phase can reduce the smoothly of the screen B or A at the first time.
How's your opinion about this thinking?
Anybody has some ideas about this situation? I'm really appreciate so much.
Thanks,
Tri.
Screens or Activities in Android are independent. You can't nest Activities. I could think of two solutions :
a) Save your data as an array List and pass it to B from A when B opens. Since it seems both contain a common layout as part of their own layout, include that layout using <include layout. in your xml for both A and B layouts.
b) If you plan to use fragments, make C a fragment and use it in two activites A and B ( could go for better design approaches though when using fragments)
Related
Recently learning android-architecture-samples, I found that each activity uses fragment, even if the activity doesn't really need fragments, in my opinion, this makes the activity lazy and leads to a lot of files.
For example, TaskDetailActivity sets the Toolbar, and other view work is given to the TaskDetailFragment.why use a fragment instead of the activity to achieve, you will find that the entire demo is doing this,
I don't think this is a meaningless question. There must be reason to do so.
Can anyone tell me why I wrote this, what are the benefits? Thank you!
No. You can have activity without a fragment.
So why Google and other Android developer advocates are pushing for a single-activity-multiple-fragments architecture?
It's because, this way you can have multiple screens (fragments) share the one single activity which otherwise would be so hard to manage as many number of activities as number of screens in your app. Fragments can easily be added and popped from your activity's fragment backstack so there's a flexibility of sharing resources from a same activity with multiple fragments. Also, if you don't care about differences in the different screens in terms of configuration such as orientation etc. , It's much easier to manage multiple screens in one single container.
From my experience you should create different activities for different workflows. E.g. your whole app (core features of your app) can sit in one activity however other things like sign up, login, onboarding can be activities of their own. This way you can start one single workflow by starting a new activity.
Another good example for choosing activity over a fragment when you are adding a new screen - Your new screen has completely different configuration than other screens (fragments) that are shared within your current activity. E.g. your new screen is a photo / video gallery that requires you to support both the orientations (landscape and portrait) but your other screens in your existing / current activity can only be portrait.
I hope you have a good clarity on why people are leaning toward single-activity-multiple-fragments approach.
There is no rule like that. fragments not must for activity it based on requirement.
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.
I have a working app that does not have any fragments.
But DevBytes says if you're not using fragments in you application you making a big mistake.
The API Guides says to Add multiple fragments to a screen to avoid switching activities
From that I assume we should always use fragments.
In my app I have activities A, B, C and D
A is map activity in which I show some markers and some info in the InfoWindow.
B has the same information as A but using just a ListView, so I can show more information about each item I have for the user.
C is the details of the selected item. The user can get to C either from A or from B
D is just another activity (outside of the flow)
Although I don't use fragments today, it seems reasonable to convert A and B to fragments so they can be reused if some day I decide to show A and B side by side in a tablet (even though it's could be easily done without fragments).
So my question is: should I also turn my C activity into a fragments as it's part of the flow? (even if I don't plan to reuse this activity) And if the answers is yes, should I also turn D into a fragment and have one app with one activity and 4 fragments?
Thanks for you time.
You should use fragments. If you don't, you're adding to future development time and decreasing future flexibility. You may not need to use fragments right now, but doing so will pay off in spades. Keep it simple by mimicking Google's own SimpleSinglePaneActivity. This will allow you to quickly implement the phone UI first, while making the tablet UI much simpler to implement some time in the future.
Depends on what you are trying to achieve. If you aren't updating the user interface in any way I won't recommend opting to fragments but if you want to update the UI then fragments offer some cool stuff. For example if you on a tablet want list and detail showing up simoultanously you'd have to convert A, b and C to fragments.
I have completed the sequence of activities of my app for smartphone, but to use it in tablets want to give a more typical of this type of display can display more than one activity at a time. That is, if I have the app smartphone version the activities A -> B -> C -> D, I want to run with a tablet will represent A, B -> B, C -> B, D, so that simultaneously displays two screen activities.
I have read that this component is used "Fragment" but after reading some things I'm a little busy and I do not know exactly what steps to follow, if you could briefly tell me or show me a clear example I'd appreciate.
A greeting.
Here is a very good explanation of how to display different fragments and as a result different layouts for phone and tablet. There are 2 generall aproaches (1) declare the fragments in you XML layout if you know which fragements you want to display in advance or (2) add the fragments to some container view at runtime in a layout specificly designed to accomidate a larger screen size.
If you're running only activities now you will need to convert your activities to run as fragments. This, for the most part, will mean dumping the contents of your onCreate method into the onActivityCreated method of your fragment. If you run into issues with this fast and dirty approach (I know you're busy as your question indicates) you should check when the variables or methods you use - if any are related to the underlying FragmentActivity - are created. I don't know the structure of your app so I cannot comment more than that.
This question already has answers here:
Dilemma: when to use Fragments vs Activities:
(17 answers)
Closed 4 years ago.
I often need the different parts of my applications to have their own special behavior and UI, and I don't know how fragments can help. In most cases, I think it is quicker to create 2 different activities (e.g., 1 for tablets and 1 for handsets), and to share the common behaviors and events in a third class.
So, keeping this in mind, why should I use fragments ?
Fragments are more of a UI benefit in my opinion. It's convenient for the user sometimes to see two different views of two different classes on the same screen. If, in your moment of creativity, you decide it would be nice to display your application with, say, a listView that takes up half the screen and a webView that takes up the other half - so that when you click on a list item in fragment A it passes an intent to the webView in fragment B, and suddenly you see what you just clicked without the app switching activities - then you could use a fragment. That's just an example I came up with off the top of my head.
Bottom line: Fragments are two or more activities on the screen at the same time.
The benefits I see when using fragments are:
Encapsulation of logic.
Better handle of the lifecycle of the fragment.
Reusable in other activities.
The drawbacks I see are:
More code(For example, instantiating a fragment manager, adding the fragment transaction, writing the callbacks of the fragment)
Communication between fragments and activities is harder. As #jonney said it, you would need to deal with a parcelable interface to serialize your objects you wish to pass.
So, when deciding to use a fragment, I would ask myself the following questions:
Is the lifecycle of the fragment different from the activity's lifecycle?
If the lifecycle is different, you get better handling of the lifecycle using a fragment. For example, if you want to destroy the fragment, but not the activity. Such is the case, when you have a pager adapter.
Is the fragment going to be used in several activities?
The user input events will be reusable if you use a fragment.
Is the amount of communication between the fragment and the activity small?
If you need to pass big objects to the fragment, you would need to deal with the code that serializes them. Also, if you need to communicate between fragment and activity, you would probably need to implement interfaces. This, in most cases, adds complexity to your codebase. It's not a difference maker, but a criteria to take into account.
Google advises you to ALWAYS use Fragments.
Why? It's simple:
In the simplest case, Fragments are used like containers of activities.
Why do you need this? Again, it's simple.
Android 4 (ICS) supports both Smartphones and Tablets. This means the SAME application will be running on a smartphone and a tablet and they are likely to be very different.
Tablets have big screens which will be empty or unused - unless you assign it properly.
That means- Putting two fragments on one activity like Contact List and Contact Info.
The smatphone will display contact List, and on a touch- display the contact's Info.
On a tablet, the user will still see the list and the info will be next to it.
2 fragments- on one screen....
Smart? yes... supposed to be back compatible down to Android 1.6......
#############################################################
O.K, Already Knew That? then - just try to understand the case solved:
A lot of things work that way- list & details, Menus and Sub-Menus, Info, Detailed Info and some more detailed info.
You want a way to keep it natural and smooth for a tablet which you expect to preform that way, but can't expect smartphone to display it all like the tablet did...
Get it?
for more Information, check out this.
I really think you just need to catch the concept....
Historically each screen in an Android app was implemented as a separate Activity. This creates a challenge in passing information between screens because the Android Intent mechanism does not allow passing a reference type (i.e. object) directly between Activities. Instead the object must be serialized or a globally accessible reference made available.
By making each screen a separate Fragment, this data passing headache is completely avoided. Fragments always exist within the context of a given Activity and can always access that Activity. By storing the information of interest within the Activity, the Fragment for each screen can simply access the object reference through the Activity.
https://softwareengineering.stackexchange.com/questions/244771/why-use-android-fragments
Fragment primary support more dynamic & Large UI Screen like Tablet.Because Tablet screen is much larger than normal Handset. There is more room to combine & Interchange UI Component.
Fragment allow such design without the need for such complex change in the View hierarchy.
By divide activity layout in fragment, we become able to modify activity's appearance at runtime