There is nothing much you can design in these regards because Android comes with its own strong concept of MVC. The Application class is usually not interesting at all so you shouldn't create a derivative class based on it.
The main class that is interesting for you is Activity (or FragmentActivity). Make yourself familiar with Activities, the app and activity life cycle and how to use Intent objects. To sum it up: *V*iew in Android are usually XML layout files that define sets of view objects arranged in layouts. These can be loaded in your Activity with the setContentView method *C*ontroller is typically your Activity and *M*odel is any data source or data object you can think of in Java. Android has a special SQLiteDatabase component for creating your app-specific SQLite databases. Then you have SharedPreferences that usually store application preferences. Another very important Android data source are so-called ContentProviders. Inter-activity communication (passing on information from one activity "screen" to the other) should be done with Intent objects. These are the same objects that are responsible for starting an activity and they can store all different kinds of key-value pairs as extra information for setting up an Activity. In some cases you can also use the singleton pattern to store globally accessible data objects or state information. However, you cannot rely that your app process is running all the time so you need to be careful here (you can easily lose these objects). Fragments are a late attempt at modularizing "View-Controller"-components for re-using them on bigger screens. You can think of a fragment as an "old-school" activity that used to run on phones. Phone have smaller displays than tablets. For making proper use of tablet screens you can arrange two or more fragments next to each other. That's similar to having multiple activities running simultaneously. It's generally a wise idea to build your apps based on fragments. However, it may make things more complicated for a beginner than it needs to be and it depends on what you're trying to achieve. On Tuesday, January 22, 2013 4:53:49 PM UTC-6, dashman wrote: > > I'm starting to write an app that'll have several separate screens - maybe > displayed > on the page at the same time (using Fragments) - maybe not. > > They all share a global app state. That is, if one screen modifies the > state, I want it > notified autmatically to the other screens. In the olden days it used to > be > called MVC design. i want my app logic to be centralized with all the > views sharing > a single instance and be notified when someting changes. > > > To implement this, Application() sub-class seems to fit the bill. > > 1. If one screen changes a global variable - how to do notify the other > pages of the > change. > > 2.In android my understanding is that there can be one 1 activity active > on the screen. > There's just 1 FragmentActivity active - displaying multple Fragments > right? > > In my case I would all the Fragments to share the same getApplication() > object - but > be able to notify all the fragments on state change. > > > Any suggestions how how to optimally design the app - appreciated. > > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
