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.
Related
I developed an app for the iPhone that I would like to make for Android. However, because I was self taught with Xcode, I approached the project incorrectly. My app in it's basics loads a certain picture from a List View when the user selects the certain button associated with the picture they want. I had no programming experience when I started, so I just linked by drag and dropping roughly 300 buttons to 300 different scenes which displayed 300 different pictures in Xcode. Yes, it was very time consuming... My question is how should I approach my project to do the same function in Android Studio, but minimizing the amount of activities. I have the idea that it would be more beneficial to use code to have one List View activity that incorporates many buttons, that when pressed, will display the particular picture. Any recommendations for tutorials or videos as a place to start as I learn my way around Android Studio? Or am is it hopeless and I will have to have another roughly 300 Activities in Android Studio.
You can use fragment for acheving your purpose.
A Fragment is a piece of an activity which enable more modular
activity design. It will not be wrong if we say, a fragment is a kind
of sub-activity
Fragment you can think of it like a sub activity, which sits with in
an activity and which contributes its own UI to the activity screen.
Fragments are always part of an activity. With out an activity, a
fragment will not exist. So your fragment life cycle will always be
affected by activity life cycle. An activity can contain more than one
fragment. Similarly a fragment can be re used in multiple activities
Below links will help you to know more about fragment and how it's implemented in an android application
https://stackoverflow.com/a/13757241/4247543
https://www.raywenderlich.com/117838/introduction-to-android-fragments-tutorial
https://www.tutorialspoint.com/android/android_fragments.htm
https://developer.android.com/guide/components/fragments.html
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.
referring at the diagram below:
http://developer.android.com/guide/components/fragments.html
Could someone please please explain why Google suggests to use 2 separate activities on a Phone and a single activity on a Tablet?
If I have code in activity A to manage Fragment B (for a Tablet) why should I repeat the same code in Activity B for a phone?
It seems that for a Phone I can still use 1 activity as well (only activity A) and replace fragments, this could reduce redundant code?
Thanks.
The reason is, essentially, that phones are small. Really small. Tiny, in fact.
Take the classic scenario of an email application. The two fragments in that scenario would be the Message List (Fragment A) and Message Content (Fragment B). On a tablet, where you've got space, you can combine them into a single activity, concurrently on screen, comfortably. On a phone, however, you need to carefully manage your screen real estate, so you should split them into the choose-a-message phase (Activity A showing Fragment A) and the read-a-message phase (Activity B showing Fragment B).
By developing them as fragments, similar to user controls in other platforms, you can use the same fragments in the same codebase on a tablet and a phone, composing the activity from existing fragments.
I get what you mean..
You could use a fragment container and replace the fragments, define interface for selection callback. Google just does it this way maybe its clearer for those who come from the activities world i guess.
Rejinderi's solution should work. I think that either that implementation or the one from Google's example can be a reasonable choice. It depends on what you are trying to achieve.
Personally, I prefer Google's example for the following reasons:
Separate activities means you use the activity back stack. In some (most?) cases, the fragment back stack is fine, but the default transition is different. You may prefer one over the other for UX reasons.
If you want to capture an intent, it may be unclear why ActivityA is capturing JobB.
In my experience, the logic for handling FragmentB without FragmentA is (a bit) different, and breaking it into it's own activity helps separate that logic, and makes everything more readable.
Menu options may also change. Again I find the separation of logic more clear.
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)
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