Hello I have couple of activities in my app and I want to be able to move between them without to worry that my variable values will get restart every time. I tried to use share permanences but it create my a lot of bugs in the app because they wont go beck to default.
AFAIK your variable values will not be affected As long as you don't finish your activity or explicitly reset/change variables values.If you meant to keep variable values you must use some storage machanism. (File / SharedPreference etc)
Vogella has written very good post on Persistence
http://www.vogella.com/articles/AndroidFileBasedPersistence/article.html#overview_fileAPI
You could begin with things like understanding what a "variable" is. Then gradually move to concepts like classes, attributes and methods. When you get those, try and learn developing for Android - things like life cycle of an application will be of interest to you. After some time you will be able to ask the right questions.
Without all these steps you will not be able to get any help, unless you get someone to rewrite your application.
I've got a question more about a strategy to use in order to implement the following requirement.
I need to develop a functionality where a user can perform some actions in the application like posting photos, commenting on photos etc. Every of this actions should leave a log somewhere and after entering one of the screens in my app, all the logs should be visible chronologically (the latest first). I've used a TreeSet sorted by item date and it works pretty fine. The problem is to keep this data persistently so that there's a never ending history of logs. I'm reluctant to migrate my code to SQLite unless it's necessary.. I like quite a lot my TreeSet structure thanks to its methods I managed to keep the logic simple. The problem starts when I'm to save this object across different launches of my app....
Has any one any idea how to solve it? Maybe TreeSet is a wrong decision though?
Putting the Logs in SQLite isn't a bad idea. Your other options is to put them in a file, and keep writing to it. You could then write a class to handle sorting it which shouldn't be too bad. The added benefit of using SQLite would be that sorting by Date would be a breeze. But then then exporting it would require the extra work, while having it already in a file makes it easy. So its really just a preference.
I'm very new to coding and have searched everywhere but havent been able to figure this one out.
Im trying to create a Lap Time Leader Board for various tracks in a video game guide. The user needs to be able to Click on the track name and then inside of the new layout "Create" a new time...that needs to allow him to imput the Car and the time it did on this track, then it needs to either sort itself or be manually sortable so that the times are in order from fastest to slowest. While i can build the layout easily i get stumped there.
How can i make it so that when the user clicks "Create New Time" the code gives him the spaces for time and car model.
How can i make sure it saves the correct info with SharedPreferences since each time will need to be saved differently (i think this has to do with the name and then ++ but i could be wrong)
How can i make it sort itself or be sortable for the user.
Can someone show me some sample code that does this? I dont know much of anything about SQL and would prefer not to use it if i can avoid it.
Im sorry this is such a noob set of questions but this after trying the notepad tutorial on AD and numerous video and book tutorials i havent found what i need to make this a reality.
You can always use a the Dialog class to create a pop up dialog to allow the user to input the information you are looking for. Sorry that you wish to not use SQL
Shared Preferences isn't such a good idea because you will have to do a lot more work to code your desired affect. A datatbase with simple Relations(tables) will suit your needs as opposed to Shared Preferences where you'd have to get creative to have the same data structure. Such as an ArrayList of BasicNameValuePairs, that could be a head ache. Database is the way to go, you can do everything you need if it's properly set up.
Sorting is quite easy in Java as you could always use the Collections class and implement the Comparable interface to compare your lap times to each other and sort them by total time. For a display such as that you would want to look into a TableLayout in Android XML. Don't worry so much about that, the Eclipse IDE will let you easily create and populate it. This would involve loading your laptimes from your database into a List and sorting them by time. It's a bit tricky but easy once you understand the Comparable interface and Collections if you need it.
If you need more insight post a comment, just wanted to share some ideas on how I would approach it.
I was wondering if instead of having to create a new class for each activity is it possible to create mulitiple activities within one class?
So define various layout xml for various activities within one class, instead of having to create new classes for each activity.
Thanks
No, you should put each activity in seperate class. Take a look at this question. Someone is wondering just the same thing as you.
Ricky,
Yes, you may have multiple "Activities" defined inside a single class. But there are a lot of obstacles and issues with doing so. Before I answer this question, two things must be understood:
What you are asking goes against the Android guidelines for development, and those guidelines are enforced in as many ways as they can be during the compilation process, so nothing I say here is insured to work across any or all API versions of the Android SDK.
Different development environments do their own checks and compile in slightly different ways. I will be speaking from the Eclipse side of development.
Techniques listed here are for education, but introduce a lot of issues. For self education and theory, it is a wonderful practice to explore. However, the goal of this answer is to educate you as to why the guideline should be followed rather than sidestepped.
Requirements for an Activity
The first thing to understand is that Android has specific points that must be met for an Activity to be run. It must: a) be declared in the manifest; b) have an intent-filter describing how it is to be used; c) be a public class; d) be a top-level class.
Multiple Activities, Same Parent Class
This means that you may create an Activity inside of another class (an inner Activity, so to speak), but it must be declared static and public. This limits your Activity in a huge number of ways. Calls to methods or members that are instance-related (not static) to the parent class are not possible. So you lose a lot of time and code hacking around this.
Second, it affects your Android XML declaration for your Activity. This is where the real trouble comes in, because while it can be done, it is very specific and there is not any supporting documentation to make that happen. But that's okay, you wanted to know if you could make ONE class for your Activities.
Multiple Activities, Same Class
Well, Android determines which Activity to run based on its Intent. You could declare the same class multiple times, but with different Names and Intent-filters. If this is the case, then you would have to determine what to do based on the Intent and the extras included. This would be done in your onCreate() method.
Doing things in this manner would mean that you would have to code for two Activities in every place that you would normally deal with one. This would make it much harder to track down bugs to support your product. It would also make every routine operation take longer as you would have to decide which method to perform. For instance, if you overrode onDraw(), you would have to know which Activity you were drawing. Its ultimately just a big schmorgasborg (sp? does anyone know how to spell that word?) of "what do I do?!"
The Real Question
Why would you want to do this anyway?
1. If the answer is to save yourself time navigating your own project, believe me... That won't really happen. Your code will be harder to read, interpret and debug.
If the answer is that you want to save file space, I would reconsider your project's priorities.
If the answer is that you want to share functionality, consider extending Activity and then extending your new sub class. How do you think they made the ListActivity or TabActivity to begin with?
If you want to save state, you can place state in SharedPreferences or your Application object (if you have extended it).
As you can see, no matter your needs, there are many other ways to go about it in a way that doesn't cause you or anyone else a hassle.
Hope this helps,
FuzzicalLogic
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I was a JaveEE developer. Recently I joined an Android development team. The structure of Android confused me. The MVC design pattern doesn't seem to suit for Android development. So what is the design pattern principle for Android development? I mean is there any hint about how to write a clean, easy reading and effective Android code.
Android's architecture annoyed me at first, but I beginning to see a method to their madness. It's poorly explained by the android documentation. My biggest gripe has always been that it's hard to have a centralized data model with objects that your Activities share just like a normal application. Android seemed to want me to be a nomad because I could only share primitives between my Activities. And dropping junk in a database is NOT a model because it contains no behavior. So as most people my business logic all ends up in my activity making it hard to share business logic in other activities.
I've come to find out I was missing some key puzzle pieces. Android is MVC. However, it's coupled to the View fairly heavily.
Activity == Controller
Model == Subclass of Application
Anything that subclasses View == View
Interestingly you can create a subclass of Application and declare this in your Manifest file, and Android will create a single instance of this object that lives the length of your application no matter what Activity is destroyed or created. That means you can build a centralized data model there that all Activities have access to.
The way I see this is something like a primitive Spring container that you can initialize objects and resolve dependencies between them. That way you can decouple the model portion of your application away from the Activity themselves. And just have the Activity make calls on the model, and hand callbacks to receive the results so it can update the UI.
The problems with Android is that it mixes controller and view pretty heavily. For example, subclasses like TabActivity, ListActivity imply a certain view being used. So swapping out a view is pretty involved. Also the Controller makes very specific assumptions about what the view is even if you use Activity. He contains direct references to UI objects like TextView, etc. And it registers for low level events like clicks, keyboard, etc.
It would be better if Activity could register for more high level events like "Login", "Update Account Balance", etc which the view would dispatch in response to a series of clicks, keyboard, touch events. That way the controller works at the level you might describe features instead of design features.
I think we'll reach this type of design eventually as we better understand come up with better tools and techniques. It seems like Android might have the extensibility to make this happen, but it's up to community to chart it.
The actions, views and activies in Android are the baked in way of working with the Android UI and are an implementation of a model-view-viewmodel pattern, which is structurally similar (in the same family as) model view controller.
To the best of my knoweledge, there is no way to break out of this model. It can probably be done, but you would likely lose all the benefit that the existing model has, and have to rewrite your own UI layer to make it work.
You can find MVC in the followings:
You define your user interface in various XML files by resolution/hardware etc.
You define your resources in various XML files by locale etc.
You store data in SQLite or your custom data in /assets/ folder, read more about resources and assets
You extend clases like ListActivity, TabActivity and make use of the XML file by inflaters
You can create as many classes as you wish for your model, and have your own packages, that will act as a structure
A lot of Utils have been already written for you. DatabaseUtils, Html,
There is no single MVC Pattern you could obey to. MVC just states more or less that you shouldn't mingle data and view, so that e.g. views are responsible for holding data or classes which are processing data are directly affecting the view.
But nevertheless, the way Android deals with classes and resources, you're sometimes even forced to follow the MVC pattern. More complicated in my opinion are the activites which are responsible sometimes for the view but nevertheless act as an controller in the same time.
If you define your views and layouts in the xml files, load your resources from the res folder, and if you avoid more or less to mingle this things in your code, then you're anyway following a MVC pattern.
Android development is primarily GUI development, which like Swing/AWT in Java consists of lots of anonymous inner classes reacting to GUI events. Its one of the things that has really kept me away from doing a lot with Swing....but I have an Android phone, so I'm going to grit my teeth and just get over it, as many an Apple fanboy has said about the antenna problems. ;)
Android makes the typical decision of making the Controller and the View a single class. This encourages putting too much in the same place. An Activity corresponds to a screen, each View to a region of a screen (sometimes the whole screen), each Controller to the user gestures from that region of the screen, and Models are just Models, sometimes backed by services from Environment or some other crazy little set of utility functions. I use the Activity to coordinate one or more MVC trios. This helps deal with Android's choice to just throw everything in the same place.
I can test the vast majority of an Android app without running the simulator. Big win.
Sorry for my English.
Android has a very good modularity (Activities, Fragments, Views, Services, etc.). So there is no need in MVC.
Of course there is the separation of taking input (Activities, Fragments), logic, view (xml or java) and data (databases, files, preferences). But this is not MVC. You shouldn't try to use MVC, it will only complicate your architecture.
Rather than keeping something in global scope, Android motivates you to keep objects as deep as possible in their scopes (class members, local variables), and pass objects to/from activities, or to fragments, using Intents/Bundles. This is also because of memory limitation.
The system may destroy your activity if the foreground activity
requires more resources so the system must shut down background
processes to recover memory.
So it's not safe to store not-constant (mutable) objects as global (static) objects. Usually you use static for immutable constants.
In simple terms, you separate your application into screens (Activities). Then each screen - into fragments (Fragments). To perform a sequence of actions on the screen you can also separate them using Fragments (example).
So you have very small blocks in your application, each of which you can easily test and reuse.
My impression is that android programming model has lots of similarity with MS WPF.
XML layout definitions, code that is always bound to one of these definitions...
So, if you are asking about design patterns because you want to improve your current or in development android projects, maybe you should look at WPF practices and patterns for improved architecture, like MVVM.
Check out these links:
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
there is small project that is already trying similar thing:
http://code.google.com/p/android-binding/
cheers