I am creating an app which will have multiple 'grids' containing a title and image thumbnails in each grid square.
Each Grid will have different content stored in it.
I have so far created one activity that initialises an instance of GridView, and uses a custom GridAdapter. (See photo for what it currently looks like) I was planning to swipe left to create a new empty grid in which the user can upload content. There may be anywhere up to 50 grids.
I'm just learning how to implement the gesture, and how to create a new instance of the activity, but from what I've read, I am thinking I have designed it badly.
I was planning for each grid to be an Activity (each takes up the full screen).
I envisaged an Activity as being like a Class in java that you can create instances from a blueprint. I thought if I created one 'Grid' I could create a new instance of it each time. Fragments didn't seem appropriate at the time, as the android tutorials often described them as being purposed to add components to activities.
I'm starting to think though that I am using the wrong methodology here and I need to change it? Can someone guide me in the right direction? I have written all the code already - if I need to change it, do Fragments and Activities share any methods, meaning I can retain some work?
Like you mentioned, using activities for holding content in your use case where switching may be triggered using gestures will definitely be resource heavy and cumbersome. Since, you mentioned swipe gestures, I believe fragments would be much lightweight in this situation. In fact, I would suggest you even look at ViewPager which even recycles fragments for you and optimizes user experience by loading the next fragment for a smoother experience. It will also handle swipe gestures for you!
[UPDATE]
Based on your updated explanation of the user flow, I'm certain that the ViewPager would fare as a better option mainly because it allows for a much better control and user navigation. It will also take care of handling swipe gestures and memory issues that come with these types of flows. Moreover, it will even allow for a page titles and bottom tab indicators in case you need them.
It will require each of its pages to be a fragment (your ViewPager will itself reside in an Activity). Once the user clicks on a grid cell, you can show a dialog window from where user input can be captured. This setup should be optimal for you resource wise in my opinion.
Related
In my application, I have multiple dynamic lists in which the user can navigate between them.
For simplification, the app has a main screen which shows a list of items.
When the user clicks on any of the items, a new list should be shown, and again if he/she clicks on an item again, a new list should be shown.
Moreover, the user should have the ability to navigate back to the previous screen.
I considered two options for implementing this:
Using the same recyclerview and change the content when needed.
Using fragment with recyclerview and replace the fragment with a new fragment that shown a recyclerview with the new content.
My question is about the implications of each of these implementations, especially in term of efficiency and user experience, or if someone can suggest a better approach to this situation.
I know a little about fragments and recyclerview, and I think that using fragment might be preferable since it is suitable if I ever plan to make the application fit into tablets and devices with a bigger screen.
I planned to test both to understand them better. However, I still hoped to hear more opinions.
I would like to thanks in advance to anyone who will share his opinion with me.
I think Using fragment with recyclerview and replace the fragment with a new fragment that shown a recyclerview with the new content is pref rebel because if you need some ui changes also fragment will be good choice.
I will suggest you use fragments for this implementation. So that you don't write huge lines file in one class.
Also it will reduce future problems if app will upgrade and UI or functionality changes, then you will have separate code to change.
Keeping adapters and fragments separate will lead more efficient way to manage user interactions.
Also you don't need to maintain views stack, android will take care of backpress itself.
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.
sorry for asking this question again. I have read all related articles, but haven't figured out what is better to use and when.
My app is going to be online store native client.
So I have a bunch of different screens in my app.
First Screen. It will be main screen like in the most online stores. There will be image slider, last new products, sales, ad and other common stuff for store.
Second screen. There will be simple list of categories in the store, without any ad,sliders and so on. Only list (RecyclerView).
Third screen. Will represent description of product, price, photos and other.
Fourth screen. Login and sign up screen to let user login in it's account.
There would be a lot of other screens required for native store client.
I have some questions about this.
I have watched the video, where lecturer said that in their app they are using only one activity for all app except settings and payment. So it makes app smoother, responsive because fragments are more lightweight that fragments. Okey, in this case we have base Activity, it should implement all callbacks from fragments to handle data and replace screen with another fragment.
We can use event bus to make it easier to with callbacks, but there is another problem.
How my activity layout should be built, it should have one fragment container and we can replace whole screen with another fragment or activity should include several fragments. For example for each image slider, ad, last products use its own fragment?
If we will use one container, so in this case we change whole screen. Is there any benefit of using fragment in this case ?
If use several fragment per screen. We have to put them in parent framgent ? In this case we are dealing with nested fragments. In most cases it is bad practice to do so.
Or we have just to know about all fragments currently present on the screen and when we have to change all screen view remove all old fragments and add new ?
What about nested fragments? Is bad to use them, and I have to do my best to get rid of them ?
Please explain how to build app to make it responsive but also to make code pattern and best practices oriented.
Thanks everyone for the help in advance.
I tried both ways, each for long period of time! I think both ways of developing applications are completely okey! I prefer fragments mostly because app looks and feels smoother but working with fragments may add a little bit of complexity to your application especially in your first project.
Should you have only one container in activity? Yes! because it doesn't matter how complex your app is, you always have some simple pages like about us, contact us, etc. and most likely they need to be full screen size! So your main activity should only have one container.
Is using nested fragment a bad idea? No! there is nothing wrong with nested fragments, in fact using nested fragments correctly will reduce the complexity of your app, that's because your main activity doesn't have to worry about little details in fragments, there transitions, navigation, etc.
Is using multiple fragment in one screen okey? again yes! that's the beauty of fragments, you arrange them as you like. Only ask one question before using multiple fragment in a screen. Do i need fragments or i just need to combine some views together?! In second case you don't need fragment, You can build a custom view that's combine some views together. (for example two textviews and one button for logging screen). Now instead of login fragment you have logginView than you can use like any other view.
Last thing you should know is using one activity increases the chance you get memory leaks (in particular activity leak) and when you get a memory leak it will be harder to find and handle it. why? because every fragment has a reference to activity (remember method getActivity?) so if you leak any fragment you also leak the activity and since your activity contains a lot of things you leak all of them all together!! And also all views have a reference to context. So again if you leak one view by accident, you leaked everything!! So be very careful about memory leaks. here is a detailed artical about memory leaks here http://goo.gl/7YDCK7
This question already has answers here:
What is the benefit of using Fragments in Android, rather than Views?
(6 answers)
Closed 10 years ago.
What is the advantage to using Fragments over using custom Views that are reused in different layouts?
In the original blog post introducing fragments, Dianne Hackborn says that
[Fragments] make it easier for developers to write applications that can scale
across a variety of screen sizes, beyond the facilities already
available in the platform.
and she goes on to explain Fragments in the context of making a tablet layout for an app that combines the UI of two activities from the phone version of the same app.
But it seems that the same reuse could be achieved using custom Views. The main different between Fragments and Views seems to be that they have differing lifecycles...
The Fragment lifecycle is:
onAttach(), onCreate(), onCreateView(), onActivityCreated(), onStart(), onResume(), onPause(), onStop(), onDestroyView(), onDestroy(), onDetatch().
The View lifecycle is:
ctor, onFinishInflate(), onAttachedToWindow(), onMeasure(), onLayout(), onDetatchedFromWindow()
I'd like to hear from developers with experience writing large apps about what benefits (if any) they've seen in using Fragments vs custom Views to divide up the UI into reusable pieces.
The main reason is that fragments are more reusable than custom views.
Sometimes you can't create a fully encapsulated UI component relying on views alone. This is because there are things you would want to put into your view but can't because only an Activity can handle them, thus forcing tight coupling between an Activity and a View.
Here is one such example. Lets say you want to create a reusable UI component that, among many things, want to capture a photo and do something with it. Traditionally you would fire an intent that starts the camera and returns with the captured image.
Notice that your custom UI component can't fully encapsulate this functionality because it will have to rely on hosting Activity's startActivityForResult because views don't accept activity results (they can indirectly fire an intent through context).
Now if you wanted to reuse your custom UI component in different activities you would be repeating the code for Activity.startActivityForResult.
Fragment on the other hand cleanly solve this problem.
Similarly your fragment can contribute items to your options menu, something traditionally only an Activity could do. Again this could be important if the state of your custom view dictates what goes in the menu.
A fragment is way more than just a view. In fact it can even be totally without a view. It can have all sorts of stuff in it including AsyncTasks, various Listeners, file and database access and so on and so on.
Think of it as a small activity, but you can have multiple of them on the screen and work with them all including communicating with each other while they are visible.
E.g. you could have a list of shopping cart displayed in one fragment and the currently selected cart in detail in another fragment. You then e.g. change the quantity of an item in the detail view and the list view could be notified about it and update the total price in the list view. You can totally orchestrate interactions like that nicely while e.g. still having only one of them visible on a smaller screen device.
I have refactored a large business app (>15 activities) from activities to fragments to get good tablet support and I would never start a new app without fragments.
Update Feb 2016: While the above still holds true, there are complexities with fragments that caused many people to entirely avoid using them. Newer patterns such as usage of MVC approaches and more powerful views provide alternatives. As they say .. YMMV.
Some description:
Imagine Activity as a plate that hold one big cake.
Fragment would be a container that slices the same cake into pieces.
Each slice contains it own logics (listeners, etc).
And in total they are almost no different with the one big cake.
The benefit:
When you plate can't hold a big cake. (Screen is small) You can easily use a a few plates (Activity) to hold each of them WITHOUT the need to move your logics into the new activity.
Better re-usability. I have some instances where I could reuse a fragment entirely in another App. You might claim that a custom view could does that too. But refer to point 1, I could reuse it with just few lines of layout changes but for a custom view, it have to find a way to plug it into both layout and code.
It is, in some sense, a more OO ways of organising your UI logics in Android programming. When you have a feature (A new partition on the screen for example), you create a new Fragment class, with minor modification to existing activity class. However if you are programming only with activity, you will need to add logics and make big modification on tested class.
Just my 2 cents. :)
The lifecycle methods are probably your biggest hint. If you think about it, they correlate closely to the activity lifecycle (with some hooks into the activity and views). In fact, in the article you linked, Hackborn says:
In some ways you can think of a Fragment as a mini-Activity
As with many things in software design/development, there are a multitude of ways to do things. There are many different places you could put your code. Yes, you could probably put a lot into a view, but keeping different concerns separated in different classes is a good thing though. The classic pattern of this is MVC and it applies in this scenario. You don't want to bake in too much controller logic into your view. It's better to keep it in controller-like classes which are the activity and now the fragment. This is why the fragment's lifecycle is more like the activity's than the view's--it was made to facilitate this kind of organization.
I touched Fragments once and found them not very useful (see this post). From what I have read, A Fragment is really a fancy word for an Object with access to Activity Context. I like to ignore Fragments in my work, and just create these Objects myself. I have created very large, very demanding apps by passing an Activity to constructors, instead of Context. One major benefit, however, for using Fragments is that they are supported by the View layout system - so you can easily add them to Android xml (if you use it for your layouts).
Custom views are much more work than just using fragments in place of your activities. if you decide to use Activities and custom Views, you have to create your custom view, and then you have to implement the same activity lifecycle methods in your activity (a very similar lifecycle is used for fragments).
Using Fragments also allows you to separate components into their own classes (Fragments), rather than having too much logic in a single Activity. Let me ground that with an example:
Say you're implementing a magazine reader application. using fragments, you could create a fragment: ArticleList, which displays a list of articles, and another fragment: ArticleDisplay, which handles the logic for displaying content. you can then specify how these fragments should interact using the fragments tools, so that on a handset, you can use the full screen real-estate for ArticleDisplay, while on a tablet, you can display the fragments side by side.
If you were to attempt this with an Activity/custom view, you'd have the logic for both Fragments in your monolithic Activity, you'd have to write a custom view, and you'd have to debug this unwieldy monster.
Fragments are, in general, a more sophisticated and powerful way to write your applications. They can do everything an Activity can do, and more. If you don't need the extra functionality, the defaults will probably get you where you need to go, and with less work.
I've recently decided to update my app to support the new fragments feature in honeycomb 3.0.
My Application currently works on a list view that opens different activities depending on which list item is clicked.
Using an adaptation of the code in this tutorial I have created an app that consists of only two activities, but depending on which list item is clicked the second "viewer" activity launches using a different layout xml.
Unfortunately I haven't been able to figure out how to call the old methods that had all the functionality. Should I Import all of my old activities and then call the methods into the viewer activity (I may need some advice on how exactly to do this) or should I just put all the methods directly into the same viewer activity (please consider the size of these methods(which is very large by the way)).
Once everything is working with two activities upfront then it will be a pretty simple task of "fragmenting" the app as demonstrated here
Although I haven't considered that there might be a way to allow multiple fragments to occupy the same space in an activity(If this is the case then please let me know how it's done)
Thanks
As James has pointed out you will have to move the business logic from your Activities to your Fragments.
To handle events you can create a listener Interface. The CONTAINER activity/ies will implement this interface. As fragments has access to the container activity you will be able to delegate to the container Activity the "logic" for the desired events. For this events the activity will decide whether to launch a new activity, show/hide new fragments or whatever.
I had a similar question, take a look to the question and answer: here
Although I haven't considered that there might be a way to allow multiple fragments to occupy the same space in an activity(If this is the case then please let me know how it's done)
I think its possible to allow multiple fragments to occupy the same space in an activity. Again, take a look to the answer here ... I think the concept/scope of Activity has change a bit and now an Activity can contain different Fragments which every one will allow user to do a single focused thing.
I'm not sure what you mean by "call the old methods that had all the functionality". You'll want to rewrite all of your activity classes as fragments. Check out this tutorial here (it's very concise). Basically, you'll want an activity that consists of a ListFragment and a FrameLayout. Your ListFragment will update the FrameLayout by changing to the appropriate Fragment based on which row was selected.