I have to solve a theoretical problem and just want to get feedback about the best pattern / practice to solve this in android.
Task:
An app could have several activities / fragments showing a list of objects. If one object is present in more than one list at the same time, I want to synchronize changes to this object. So e.g. if I delete the object it should disappear in all lists.
The restricts are that
I don't know which lists are currently instantiated
Every list has it's own object instance. Data is not shared directly between lists
My solution so far would be to
define a Storage class which provides methods for data access
create a custom Application class and instantiate the Storage class with the application context (which is needed for e.g. content provider access)
the Storage class defines a Listener where each activity can register itself
if an activity modifies an object, which it has to do through the (Application) Storage, the Storage class sends an event to each activity / fragment registered so they can adopt the changes.
Does anyone know a better solution for that? And is my solution conform with the android lifecycle?
Thanks a lot for every kind of useful feedback
If you want to deal in Object then read up on implementing Services and Binding to them. You can provide all your objects with your own API methods and return values. If your data fits into a data cursor model, then you should read up on building your own ContentProvider. It has data observation built in and all the Adapters support it already.
Your solution seems pretty good. You could use an EventBus like Otto http://square.github.io/otto/ to send an event to all your activities/fragment when an object is modified.
If you insist on maintaining the separate lists in separate Activity/Fragment instances, then you will be prone to lifecycle problems (you might miss an object modification event while you're paused or something). Otto or other EventBus libraries might help.
However, I think it would be much simpler to host all those lists (and their possibly-shared objects) in a local bindable Service. Each Activity/Fragment can then simply bind/unbind to it in onCreate/onDestroy, thus guaranteeing an up-to-date view of those lists.
See http://developer.android.com/guide/components/bound-services.html
Another similar solution would be to host all those lists in a retained Fragment. Using retained Fragments would be simpler than a Service because you don't have to write all the bind/unbind code. However, retained Fragments might not work as well as a Service if you have multiple Activity components that need access to the same lists of objects.
Yet another hacky solution is to just host all those things in the Application instance itself (effectively a global variable). Then your Activity/Fragment code can just call ((MyApplication) getApplication()).getFooList() to get to those objects.
Related
I know that I can add a string or an integer by putting putextra() on my Intent but what do I do if I have to send a List?
For example, My main activity contains a list, I have a different activity that adds an item into the list and I have a third activity that needs to show the whole list
Your object can also implement Parcelable interface. Then you can use Bundle.putParcelable() method and pass your object between activities within intent.
Photostream application uses this approach and may be used as a reference http://code.google.com/p/apps-for-android/
Source: google "pass objects between activities android" :)
By making the Activity the central focus of the Android API, both in the API documentation and in most of their examples, Google has encouraged inexperienced developers to treat Activities as the sole constructs in an Android application. And, unfortunately, most of the widely available literature and over-simplified code examples available on the web perpetuate this.
However, good software design, regardless of platform or programming language, would suggest that you use the concept of a data 'model' - a class that contains the data that is important to your application, as well as methods that operate on that data. This class should be independent of any user-interface-related classes.
Activities are essentially a mash-up of Views and Controllers from the point of view of the popular Model-View-Controller (a.k.a. MVC) design pattern.
You should strive to remove the management of your data from the Activities, and put it elsewhere, in a non-Android class. Then make that class available to the Activities that need it, instead of simply passing data from Activity to Activity.
Where to put this model class? There are a number of ways to do it, including, but not limited to:
Make it a member of your Application class (subclass Application if you haven't already) - this is simple and convenient, but only reasonable for very small applications - it quickly gets out of hand
Make it stand-alone, but make all of the data members and methods static - again, simple and convenient, but only for a very small amount of data
Use a dependency injection library (e.g. Dagger), make it a Singleton, and inject into the Activities that need it.
There are lot of threads about how to make two Fragments communicate each other using an interface and event call back methods through Activity.
Is there any specific reason to do that way? or is there any downside doing this way-directly calling method of fragment-2 from fragment-1
((Fragment2) (getActivity().getFragmentManager().findFragmentById(R.id.fragment2))).methodOfFragment2();
Unfortunately the activity-interface in many tutorials doesn't give people a good model for actually making their fragments modular.
What most people end up doing is making their activity-interface some central repository for hardcoding relationships between fragements. Thus, when I first started usnig fragments and read about this "model" I too wondered at its value, since I was just introducing a layer of indirection over my fragment relations.
overtime I learned or adapted patterns, like the Broadcast/Receiver model to my fragments. Now my fragments don't communicate through the activity-inteface, but instead broadcast events on an event-frequency with payloads through a local broadcast object, and other objects interested in those events can register to receive those events and data.
In other words, my fragments have events, and they publish those events, often with payloads, and other objects can register to receive notification and data from those events. If no one's listening, nothing happens. If I write some new object that want's to receive data from the event, my other fragments and even my broadcaster don't need to be aware of any specifics of how my new object was implemented.
If you want to learn more about the broadcast Receiver model Android has its own LocalBroadcastManger, or you can write your own lightweight one, and you can find some tutorials on how to use it here:
http://developer.android.com/reference/android/support/v4/content/LocalBroadcastManager.html
how to use LocalBroadcastManager?
Because a fragment is suppose to be able to be reused. If you are calling a fragment that exists in one instance of your app and you reuse one of those fragments in another section of your app but not the other then guess what you just broke your app trying to call something that is not there.
Fragments should not know another fragment exists which is why all communication should go through an activity
I have been wondering for a while now in this question on stack overflow one solution for passing complex data in-between activities on Android is the usage of static data members.
But somehow I get the feeling that this is not the way how you should do it even thou it seems to be the easiest way.
Therefore my question what is the downside of using static members for passing complex data.
A static reference to pass data between components could be used if all of these conditions are met:
It is only accessed via 1 process
The data it contains does not hold a reference to any specific component (Activity, Fragment, Service e.t.c) except for the Application (which is a static singleton anyway)
The data does not keep a reference to anything else that may not have the same life cycle as the data
The data is too complex, or large to reasonably Serialise, Parcel or otherwise pass via Bundles, and doing so would effect the performance of the application.
It is correctly synchronised if accessed from different threads
The data is correctly managed and released when no longer required, avoiding leaking the memory needed to store it
Since these are quite restrictive conditions, a different approach (some suggested by gmale) is usually better.
The biggest drawback in my opinion is the management of the static data - it is usually difficult to tell when the data is no longer needed and when it can be released.
Using static members should be avoided. It's one of the worst ways to pass data in Android. Static objects persist beyond the application's lifecycle. So a user can back out of your app and your data lives on because the class is still loaded in the JVM. That's very bad.
Sometimes, Otto can be a good option for passing complex data around and it plays nicely with the Activity Lifecycle. Another alternative I've seen on many projects is good old fashioned listeners or callbacks. There's also intent services and local broadcast managers.
There are a lot of ways to share complex data. I would consider "static" objects a non-starter. Avoid them like the plague.
Just wondering what is a better practice to pass information between activites, adding it to a bundle or using a singleton class to store and access this data. I have used both in the past for various android side projects, but I am now working on an android project that is of much larger scale, so would prefer to do things right towards the beginning.
My application authenticates users and then will have to do various queries based on it's id. To minimize coupling between activities, I would think just adding the id to the bundle, and then letting each activity query for the information that it needs, would be the best bet; however to increase responsiveness, I was leaning towards using a singleton class to store persistent information, preventing more queries than need be.
Personally, I would create an extension of Application to store the state of your app and share data between the different activities. The Application acts as the context for your whole app and Android guarantees there will always only be one instance across your app. Hence it works similar to defining your own Singleton, but using Application will allow Android to take control of the life cycle of your shared data and basically do the memory management for you.
Here are some more details. If you go down this path, you can simply add any getter/setter (or other) method to your application extension to store/retrieve data and do operations on it. Especially the latter can become quite a pain to manage (and keep consistent) when using Bundles passed back and forth between activities. If would only use a Bundle if the data is needed in just one or two places that are neighbours in the activity flow and does not need any (complex) operations to be run on it.
The better way to go for you is to use SharedPreferences to keep userId you need to keep and reuse. Of course you can use singleton approach or even Application class, but the data will be lost after application is killed.
The only time I pass data between Activities via bunlde is if it's something that I won't need to access for a while(i.e the the resID of a resource I want to use only once in the calling activity, etc). I would also think the difference in responsiveness would be very minimal, so that shouldn't be of concern. I suggest the singleton approach
Passing bundles is a tedious job. You'll have to pass a bundle for every change in activity to make sure that the value is not lost, even if you're not using the value in the called activity.
Singleton pattern have some bad results. For example:From Main activity you call secondary activity. Phone call interrupted your work.After ending phone call Android is trying to bring secondary activity to screen. Here is my nightmare - many users complaint about exceptions - Google reported to me NULL pointers in my singleton. So you have to provide not only singleton, but all data inside singleton have to be as singleton too. This maked come very complicated :(
This is a question I've now had for a few different apps I've built, and I have yet to be satisified with any of the solutions I've come up with. I thought I'd put it out there to the community to see other solutions there might be.
Let's say you have an Activity that downloads a complex tree of data (in this case via json, but it could be anything), unmarshalls that data to a set of java objects (in this case using gson, but again, could be whatever), then spawns additional activities to view different parts of that data. There might be one activity to view Trips in your response, and another to view Flights in those trips, and maybe another to view Passengers of those flights.
My initial implementation of this app was to unmarshall all the Trips in the first activity, then pass them by value (as an extra in the intent) to the TripActivity. The TripActivity then passes individual flights to the FlightActivity, and so on.
The problem with this is that there's a noticeable pause between activities while the app serializes and deserializes the data. We're talking several seconds. The pause is quite noticeable when my tree uses Serialization or Parcelable to pass data around. Initial performance testing with using google's Parcelable instead show a roughly 30% speedup over serialization, but Parcelable is difficult to work with and doesn't seem to handle circular object references well like Serialization does, and besides it still pauses for almost as many seconds, so I've put that experiment on the backburner while I try other things.
So then I tried moving the tree of objects directly into the Application class. Each activity just gets the tree directly from the app whenever it needs it. This makes performance quite snappy, but handling corner cases like unexpected activity start/stops (either due to activity crashes or because the activity has been closed temporarily to make more memory available, or whatever other cause) seems tricky. Perhaps it's no more than implementing onSaveInstanceState(), I'm not sure, but the solution seems a bit hacky so I haven't investigated further yet.
So in search of a less cobbled-together solution, I tried creating a custom ContentProvider to store and retrieve my objects. Since ContentProviders can be configured to run in-process using multiprocess=true, I thought that would be an excellent way to avoid serialization costs while doing something more "standard" than storing data in the Application object. However, ContentProviders were clearly not intended to return arbitrary object types -- they only support types such as numbers, strings, booleans, etc. It appears I can finagle one to store arbitrary objects by using ContentResolver.getContentProviderClient().getLocalContentProvider() and accessing my custom class directly, but I'm not sure that's less hacky than storing data in the Application object.
Surely someone must have a good solution to this problem. What am I doing wrong?
In addition to fiXedd's solution, another one is to use a local service. Have the service "own" the objects, with activities calling service APIs to get whatever it needs. The service can also be responsible for fetching and parsing the data, encapsulating that bit of logic.
The Application object is the "red-headed step-child" of Android components. Members of the core Android team have come out against the practice of creating custom Application subclasses, though it is certainly supported by the API. Having engineered one ADC2 200 application that leveraged a custom Application subclass, I can say that I should have gone with a service in my case as well. Live and learn...
By using the local binding pattern, your service will automatically be created and destroyed as needed, so you don't have to worry about that. And, by definition, a local service runs in the same process/VM as your activities, so you don't have to worry about marshaling overhead like you would in the ContentProvider scenario.
The way I'm handling this in one of my apps is downloading the data then shoving it into a database. This way I don't have to carry all those objects around (which, IIRC, eat about 1kb each just for the object instantiation) and I can easily pull just the data that I need. I don't know if this will work for you, but it worked for my use-case.
Another approach would be to save the data objects to a shared preferences file. That's how we implemented one of our apps, but I didn't like that approach because it seems too slow.
It's bad coding practice, but the fastest way may be to just use a service to parse the data and save the data to a static class that you can use for the rest of the app's life.