I have three screens looks exactly same with different set of data loaded on them.
What design pattern shall i use for it.
Tab1,2,3 also loads different data (Loading from database).
One activity and different fragments loading data accordingly.
Three activities using same layout.
Plane simple three activities. (Or more for tabs too - not sure)
I'm not really sure what your data is, but is there a reason you can't just cache the data in say, a content provider? Then you could use one activity, one fragment and just have listeners to load different data from the provider.
Related
I am new to developing on android, finding myself somewhat confused regarding fragments and activities, and when to use the former specifically.
I want to achieve the following:
Have an activity with buttons for displaying different graphs. The selected graph should appear on screen in a panel overlaying the screen, or in fullscreen, and it should have functionality/buttons e.g. for selecting a graph timeframe.
Would creating each graph-page as fragments, routing events to the main activity be a good idea here, or should I just make a new activity for each? Or are there better options?
Cheers
I wouldn't recommend to use separate activities for this task.
The fragments are a great option for your case. You can save the state of each fragment and thus avoid recreating the graph views every time (which saves lots of CPU time if amount of data is big).
Read info about FragmentTransaciton and of course learn about working with Fragments in general. Maybe you should also try using ViewPager if you want to avoid switching fragments by yourself.
In case of using ViewPager you should use FragmentPagerAdapter (this one saves fragments for you) and you will just switch between them from your MainActivity. In each of the fragments you will implement your own graph with its own (or shared) layout file.
This version of the pager is best for use when there are a handful of typically more static fragments to be paged through, such as a set of tabs. The fragment of each page the user visits will be kept in memory, though its view hierarchy may be destroyed when not visible.
I am using tabbed activity and have three layouts and I wonder how its done when I want to get the data from all the tabbed activities are not in the view.
They all have different layouts so I cant use "findViewById" to retrive the data thats not in the view.
I thought I was smart and maybe i chould use "findViewById(android.R.id.content)".
Some background info first. I require my app to show a feed of posts, implemented as cards. The data within the posts/cards is retrieved from my site's REST API. My app has 3 different tabs, each containing a different feed of posts/cards (but still the same layout).
Currently, I have an activity_main and the 3 fragments made for each tab (fragment_1, fragment_2, fragment_3). To my understanding, a Fragment is a layout that can be re-used on different Activities. Is this correct?
Additionally, where should I implement the layout/design for the cards? Should it be directly within the separate Fragments (even though the layout of the cards will be the same across all 3 tabs)?
After implementing the card layout, how would I populate the cards given the requested REST API json data? In other words, how would I loop through each result and insert the data into the card and display it on the screen?
Sorry for the noob questions.
Currently, I have an activity_main and the 3 fragments made for each
tab (fragment_1, fragment_2, fragment_3). To my understanding, a
Fragment is a layout that can be re-used on different Activities. Is
this correct?
Yes.
Additionally, where should I implement the layout/design for the
cards? Should it be directly within the separate Fragments (even
though the layout of the cards will be the same across all 3 tabs)?
Have a single fragment. Create 3 instances of this fragment and inflate the same layout/design if the layout of the cards will be the same across all 3 tabs.
After implementing the card layout, how would I populate the cards
given the requested REST API json data? In other words, how would I
loop through each result and insert the data into the card and display
it on the screen?
Pass a unique identifier that identifies the feeds (for this fragment) to the fragment as a bundle when you create a new instance and set them as the fragments argument. You can then retrieve this information to retrieve data relevant for this fragment.
To display the data, use a ListView/RecyclerView along with a suitable adapter to connect your data to your view.
I hope this answers your question.
OK. Lets try this. Yes, you are right, Fragments are basically layouts that can be used in different Activities. As it says on Android Developers site:
A Fragment represents a behavior or a portion of user interface in an
Activity. You can combine multiple fragments in a single activity to
build a multi-pane UI and reuse a fragment in multiple activities.
Having that said, since it is the same layout for all three tabs, you can use only one Fragment and populate it with different data. So if you want to change anything, you would do it only within that one fragment.
For the cards I am guessing that you will be using a custom ListView adapter. And that you should (must) implement outside the Fragments.
And regarding the last question, there are many libraries that make consuming ReST webservices much easier. For example Retrofit.
I am designing an app based around having a large amount of fragments containing information.
I was just wondering (since I plan on upwards of 100+ fragments). If there is an easier way/less cluttered way to do this?
I have 3 at the moment and that means I have 3 different fragment classes, as well as 3 different fragment layouts?
I am very inexperienced with fragments so I am not sure which direction is best.
I want every single fragment to share the exact same structure. The only difference will obviously be different text and images inside them
Then you should not have 100+ fragment classes, or even 3 fragment classes. You should have one fragment class, with its associated layout(s). You are welcome to have many instances of that class, with "different text and images inside them".
I have a question about whether to use View or Fragment with ViewPager.
Background:
I have an Activity A that contains a ListView. Each ListView item opens Activity B. Activity B shows different content depending on which ListView item is tapped in Activity A.
Activity B's content is shown inside a ListView.
Question:
Now, instead of going back and forth between Activity A and B to switch contents, I have a requirement to implement horizontal view swiping to switch contents all within Activity B.
One solution I found (tried it and it works) is to create many instances of Activity B's ListView and use it with ViewPager + PagerAdapter.
Another potential solution found on the doc (haven't tried it) is to bring that ListView into a Fragment, create many instances of the fragment and use it with ViewPager + FragmentPagerAdapter or FragmentStatePagerAdapter.
My question is, what's the benefit of using each approach? Should I go through all the trouble of bringing the ListView into Fragment or just simply use ListView with ViewPager?
Thanks
A Fragment is a useful approach, I think, when you want to tie some UI business logic to a particular View (or group of). As you know, that individual Fragment has its own lifecycle callbacks and so forth, just as an Activity would.
Rather than having a single Activity host many ListViews through a single PagerAdapter, it may be cleaner to use the Fragment approach because the Fragment only needs to deal with the logic behind driving a single ListView.
This is a very similar situation to one I've just been facing. I'm showing various vertically scrolling forms (consisting of lots of input fields) within a ViewPager. In my case I have gone for the Fragment approach because in my case, it's possible that the ViewPager will actually need to display a completely different kind of view on certain pages. For example, on the first few pages, user input forms might be displayed. But on the final page, a graph will be displayed. A whole separate set of logic is required to drive that graph. To drive those input forms and one graph from a single Activity would get a bit messy, and I would probably need to contain the business logic in several delegate classes or something. So for me, Fragments were the obvious choice in the end. I have my InputFormFragment and a GraphFragment, and they each contain only the applicable logic for the Views that they supply.
Another thing to consider is that in the near future you too may want to display a different kind of View in your ViewPager. Or, you might want to have another UI layout altogether, perhaps one that doesn't use the ViewPager but displays them all side-to-side (e.g. a layout used on a large tablet in landscape mode). With Fragments, things are just far more modular and you could factor the code to do this quicker. If on the other hand you achieved your objective by using a single Activity that contains a simple PagerAdapter and all the logic for the ListViews within, you might find it takes more work in the future to support new kinds of Views or special tablet layouts.
One thing I will say is having implemented Fragments in a ViewPager myself through FragmentPagerAdapter and FragmentStatePagerAdapter, things can get a bit awkward if you have any special requirements; managing Fragments can be tricky sometimes. For example, for my UI I needed to be able to programmatically add and remove the ViewPager containing the Fragments. I also needed to ensure that the adapter in use didn't destroy Fragments once they had been shown, because I needed to collect data from all Fragments simultaneously at a certain point. Furthermore, I had to extend and modify FragmentPagerAdatper to make sure that the Fragments go through their onDestroy() properly and are removed from the FragmentManager when the ViewPager was removed.
Fragments enable a very modular way of constructing UIs for various screen sizes and orientations, and are excellent in how they allow you to encapsulate business logic and lifecycles for individual UI elements. However if your scenario really is just as simple as several ListViews in a ViewPager and you know that you will never need the modularity, then the overhead of Fragments could be an overkill.