I'm creating an app that takes the user through a fairly long, linear, process of data capturing. Each activity leads to a new one for a new topic for which the data needs to be entered. The problem is that some of the activities have many or large bitmaps, or many imageButtons. When the user goes to the next activity, the current one is placed one the backstack and the memory does not get cleaned up.
I am considering calling 'finish()' when the user goes to the next activity and then overriding 'onBackPressed()' to recreate the previous activity if the user needs to go back and change a value there. Is there any better suggestions than to do this?
The solution you consider is certainly on the right track.
My only addition to that (recreating the activities when you need to go back to them) is that you don't necessarily need many activities.
From what I understand you need many layouts, each with its relevant resources. What I'd do is:
create your Stage data class, holing a layout, bitmap id's, etc
create a List<Stage> with the full story
create one activity that knows how to display a stage from the list, and traverse to other stages. Here you can override the back button to act as stage traversal.
Check out The Transitions Framework to see how you can animate views when traversing between the above stages. If you use the same id for at least some of your views - they will move around independently, while other views will fade out or in.
Related
I want to create the look shown in below image. Basically the user should go through all screens until he reaches the final screen.
I want to know if it is better to create a slider for this which can have all screens in it or to have a new activity for every page. I want to add all the inputs from these fields in the database in one single row (entry) instead of each item as one entry. I am using Firebase database to do so. Please let me know what would be a good option to do so.
You can use activity option but in this case you have choose one two options: passing all previous values to the next activity and keeping data in a holder whose scope is longer than activity scope. The former option is better actually for this purpose but it is not recommended because it causes a key mess in your activities. I think the best approach is to use fragments for each screen and keeping the data in the parent activity.
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.
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
Okay, I know there is a lot of discussion according to this topic, but I couldn't find any answer.
My problem is the following:
I have an Activity with NavigationDrawer, so the Fragments are added from code. The first fragment is a ListFragment, witch reads data from an SQLite DB stored in the SD card. The data loading is kind of slow, because I load the nearest n place based on location. So I don't want to load the list every time.
Now, if the user clicks an item, a second Activity shows the details. The first strange stuff is the first activity is destroyed almost every time a leave it, witch is awful, but still I could save the state.
The discussions that I rad so far indicated that the Activity should retain the last displayed Activity, and it kind of does, because if I change the content of the first activity from the Drawer before navigation the correct Fragment is created.
The problem is that even if the ListFragment is being re-used its contents will be missing (since I create a new View in the onCreateView() because of custom layout). I guess I should use the Bundle provided as a parameter in onCreateView(), but I just couldn't figure it out.
So summed up: what is the proper way of saving the items of a ListFragment, even if its parent activity is destroyed?
It turned out that I had a developer option turned on that killed all Activities that I navigate from. I didn't know that because I use my phone in Hungarian (guess it'll change from now), and for some reason they felt like they had to translate the word "Activity", making the whole option description not understandable. Sorry about that, now my first Activity is kept in the memory, so the whole issue is not present...
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.