As an alternative, why not store the ArrayList<Student> in the Application object, and have getArrayList<Student> and setArrayList<Student> methods. The Fragment can access the ArrayList<Student> and update ArrayList<Student> with these methods. Since the Application object is a singelton, there will only be one valid copy of ArrayList<Student>.
Mark On Fri, Dec 4, 2015 at 1:20 AM, Doug <beafd...@gmail.com> wrote: > > > On Thursday, December 3, 2015 at 8:03:24 PM UTC-8, TreKing wrote: >> >> >> On Thu, Nov 26, 2015 at 12:35 AM, Vinayak Mestri <mestri.v...@gmail.com> >> wrote: >> >>> I want to do like above code i.e student is reference variable so if i >>> change any values of student arraylist will reflect to actual object in >>> activity >> >> >> 1 - Look at the documentation for Fragment which shows the static >> constructor pattern that is typically used to construct a fragment with >> parameters. >> http://developer.android.com/reference/android/app/Fragment.html >> Your model object would implement the Parcelable interface to be passed >> along as data. >> >> 2 - You can then let the Activity know when changes are made via >> callbacks: >> >> http://developer.android.com/guide/components/fragments.html#CommunicatingWithActivity >> >> You generally don't want the exact same data object in the activity and >> fragment. >> > > You generally *do* want the exact same data object if the object is large > and would take significant time and memory to serialize and deserialize in > a fully duplicated form. This is especially OK if your source object is > immutable and therefore threadsafe and immune to tampering for read > operations. > > >> If you really really do, you could alternative expose it as a public >> method in the Activity then instead of passing it to the fragment, access >> your activity in the fragment (onAttach or onActivityCreated or something) >> and get the list data, which would be the actual list both objects would >> share. >> > > Also, if serialization is not a well-performing option, sending the > fragment an indicator on how to find the collection would be fine. > Sometimes people use an event bus to publish stored data object to > dependents. Sometimes receiving from a singleton is good enough as long as > it's not adding too much weight to the app. Sometimes querying a content > provider (backed by sqlite database) for very large collections is > appropriate. > > Doug > > -- > You received this message because you are subscribed to the Google Groups > "Android Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to android-developers+unsubscr...@googlegroups.com. > To post to this group, send email to android-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/android-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/android-developers/a903fbfa-9b30-4941-a94f-4831c310686c%40googlegroups.com > <https://groups.google.com/d/msgid/android-developers/a903fbfa-9b30-4941-a94f-4831c310686c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at http://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/CAEqej2M%2BeRAmB%3Dt751F7qGPw8Mx9ewZMAdsMDpJdiDpGF4haJg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
