I'd like the activity stack for my app to contain multiple instances of the same activity, each working on different data. So I'd have activity A working with data a, b, c and d in my activity stack ad I'd have 4 instances of activity A that I'd call A(a), A(b), A(c) & A(d). I'd also like to arrange it so that if the user asks to work with data c again then it won't start a new activity, but rather will just bring the already running activity A(c) to the front.
Any suggestions on the best way to achieve this?
So I'd have activity A working with
data a, b, c and d in my activity
stack ad I'd have 4 instances of
activity A that I'd call A(a), A(b),
A(c) & A(d).
That will happen by default.
I'd also like to arrange it so that if
the user asks to work with data c
again then it won't start a new
activity, but rather will just bring
the already running activity A(c) to
the front.
I do not believe that is possible unless you create distinct activities for each letter.
I'm not sure you can do it the way you have it described because fiddling with the activity stack like that is not supported AFAIK.
What you could do instead is just use a tab based activity. Each tab could be another instance of activity A working on a different dataset.
I agree with Falmarri (comment), you cant "switch between activities" in the way you are describing. You can however store that data somewhere (file, database, service, global variable, ext.). Where you choose to store that data (a, b, c, d) is up to you and depends on what kinds of functionality you need your data to have.
As for how you "switch" from one to the other, that is somewhat easier than you might think. you dont actually have to "switch" from one activity to the other, you can just swap our all the data. its is perfectly legal (though not always recommended) to have your entire app exist in ONE activity, and merely switch layouts over and over.
My suggestion would be to swap out the data within one activity. you could even specify which data set you want to load initially in your intent filter.
Related
I'm writing my first android app, and it's going very well so far, but my code is getting obtuse and I'd like to reorganize it in a way that allows me to reuse portions, and add things more easily.
Based on my previous experience writing simple command line programs that call methods, this is how I THINK I should organize my code:
(some code in MainActivity)
Call a void method of the object DoStuff:
Launch Activity1 and write some values to SharedPreferences file, THEN
Launch Activity2 and write some values to SharedPreferences file, THEN
continue running code from MainActivity
Right now Activity1 and Activity2 both launch at the same time. Is there a different way I should be writing/organizing my code? I guess I'm trying to do thing with Activities that I'm used to doing with methods. But I'm aware that my thinking might be wrong on this. I hope this makes sense.
Thank you for your help!
Your understanding of Activities is wrong. Activities do have methods that you can very well use.
An Activity is basically one screen that you see in your app. It can be started, stopped, resumed, etc. You can have different screens shown in one Activity (e. g. with Fragments).
If for example you have a list of notes in one Activity, you could have the detail of one note shown in another DetailActivity.
Only in rare cases, for example if you want to check on startup what Activity to show you could have another activity that does not have a layout but only does some checks and launches another one.
In each of your activities you can have methods to execute what you want on user interaction. Of course this can also go into other classes.
I would recommend you to start with a basic Android tutorial to gain a better understanding of the concepts.
I have activities like A->B->C->D. How can I close the A activity if I have 4 activities on my stack? Also later when I open activity E i want B to be closed aswell, so I want to have C->D->E only.
There is no such as a direct way to manage activities number in stack. So far I know that stack is big as much as available memory.
Also consider LaunchMode and whether activities are in the same task or not.
So, you might implement your own Activity manager to finish un-wanted activities.
Here is briefly how I see the solution:
Create a model to store activity, its index in stack, date ..i.e. ActivityItem
Create an empty List of ActivityItem in your custom Application. To avoid memory leak, use WeakReference. create a public setter adActivity to add and manage activities
Better approach to create activity base class and reuse it as superClass wherever you want to manage count of running activities. instead of repeating same implementation for each different activity.
OnCreate in your base Activity call adActivity and pass current activity.
adActivity job is firstly clean the list of destroyed activities. thanks WeakReference. Then manually kill older activities before last 3 items in your list. It's not easy as it looks.. for example: SingleInstance and rotation will make it challenge to achieve this :-)
that is it.
Good luck,'.
When you start activity use
startActivityForResult(intent,code);//different code for all activity
and call
finishActivity(code);//which activity do you want to close?
You can call:
finish();
after:
startActivity(intent);
In every activity that you want to close, when you open another activity.
I have got 2 activities - "A" contains fragment with a list of conversations, "B" represents a conversation (shows it's messages), in B I can also send a new message.
I would like to be able to update A's list of conversations every time a message is sent in B, so when I click android's back button, A activity's view is updated.
The core of the problem for me, is that I'm not starting A through an Intent when I click the android's back button, so I don't know how to get this effect.
Thank you for your help!
When A is on the backstack, there's no guarantee that an instance of A even exists in memory. The answer to the question of how to manipulate A from B is don't.
Some correct ways of doing it:
If your model (the list of conversations) is Parcelable or Serializable, you can pass it between activities via Intent. You can pass it back from B to A if you start B for result and retrieve it from the Intent returned to A's onActivityResult.
Make the model persistent, like in a database or SharedPreferences file.
Put the model in a bound Service. This would be faster than having each activity load it from persistent storage, but you may still need to make it persistent so you don't lose it when the Service shuts down.
I have been researching this for about an hour and cannot figure out whether to use fragments within an activity or start a new fragment activity.
Some sites make it sound as if you should have 1 activity and EVERYTHING else is a fragment. Is that the more proper way now? I can't figure out when you use an Activity (or fragment activity) and when you use a fragment.
I have an app for a conference with:
-Speakers (and sub views/activities/fragments) for each speaker.
-Schedule (different sections for each day)
-General info
-Sessions (different sections for each session).
So do I have 4 activities each with their own fragments or do I just use 1 activity with fragments and nested fragments?
You could do it either way, but generally it is best to use an Activity (or FragmentActivity) for each "screen".
If the user sees your app as logically a single screen that has little panels appearing/disappearing for different kinds of data, then use one activity with a lot of fragments. If the user sees it as "going to different screens", then you probably want multiple activities.
If you go with the one-activity-many-fragments model, you may find that your activity's code gets really complicated dealing with all the possible configurations of fragments. That is a good sign that you may want to split it into multiple Activities. Similarly, if you go with the many-activities model, but find that things get complicated as you pass shared data between activities, consider merging the activities.
Converting from Activity to FragmentActivity is as simple as changing the extends and nothing else needs changing.
My conclusions:
I stopped using Activity and only use FragmentActivity as it is more flexible and more up to date and backwards compatible (Using the support library).
If the FragmentActivity has a component that is large enough to be a standalone component, or needs to be one, then I make it as Fragment.
I haven't come across something that would require a complete separate activity to be within another activity, but that should only be used if that component is large enough and completely standalone enough to need an activity for itself.
I don't fully understand your app to be able to make a specific call on which you should use, if you want my opinion, can you provide more details on what you are working on and how are those components connected.
Regards
Another consideration in choosing a more decomposed architecture (many Activities) might be the cost of destruction / creation in the Activity Lifecycle. Do you plan to use Explicit/Implicit intents to leverage existing apps? More death. So, you might have only one activity in a dispatch oriented model and clearly see your apps logic in one place, but how much state will you have to save/restore? Are there performance penalties for re-inflating or populating data resources?
I have a similar issue with this one:
Android: Multiple activity instances launched by same intent. Bring one uniquely to foreground?
I need to create a stack of activities, all created by using the same class: it is a class defining a news list, only there needs to be multiple children activities that are also news lists, but from different categories. (I do need to have these activities in a stack)
The trouble is I need to change data on each of these activities after they are shown, but I can't find a way to access each one of these activities separately, since they are all using the same class, so if I used static methods, I would change the data on all these activities at the same time. Ideally, there could be a way to use references of each activity, so that I can access methods on each one separately, but I don't think there is a way of doing this.
I might as well pass parameter IDs when starting each activity, and instantiate objects at the same time, for each activity, and using these IDs later access the respective objects' methods...
Edit to clarify: Let me use an example to what I am trying to achieve. I have an A class and I am using this same class to instantiate multiple activities, in a stack. After the creation of these activities, I need to alter data, say, on one of these activities statically, so by calling A.alterData(); , but not when the activities are created, so there is no way of doing this by starting the activities with different data.. Since there are multiple instances of this class, if I do so, this will result on altering the data on all these activities, that are using the A class. Would I be able to somehow use objects and methods to these objects to alter data on different activities that are using the same class?
any other ideas?
You could use an ActivityGroup. It basically holds a list of activities and you need to control the navigation around them. It sounds like it suits your situation. There are many examples of them that can be found through google.
How I would approach changing the data on the other screens is by using shared preferences. You can store whatever data you need in there, and then (through your activity group) when you change screen, the data is refreshed. This is faster and a little more efficient than restarting the intent every time.
Another way is to change the data in the background without the user noticing. This can be done because an Activity group loads all of the Activity it holds and they are always there in the background, running, unless the developer states otherwise.
You could grab a a hold of the appropriate instance of the class you want to change the data on and then just change it.
Does any of this make sense?
I can elaborate more if needed.
I would supply the parameters to each activity, such as:
intent.putExtra("category", categoryId);
That way you aren't managing too much global state.
About changing the data - if you are talking about refreshing the data from its original source, then you should probably be doing this in the onResume() method of the Activity. Check out the Activity Lifecycle.
This has a few benefits:
you will have access to all of the context of that Activity
you won't have to do something nasty like access another Activity's data
you won't waste time refreshing data the user isn't looking at
Even if you have to make updates to the data, there are ways to make sure each Activity "minds its own business".