I am new to developing for android. I have a question regarding some best practices. My app is like a dashboard from which multiple different "sub-activities" can be started and done.
I am wondering what is the best way to structure the app. One way is to have different layouts and load and unload them appropriately. The other is to start new activities using intents. At least this is what i have gathered from what i have read.
What in your opinion is the best way to go.
Thanks
I've found in my applications that each Activity is generally responsible for a single UI view.
So rather than loading and unloading different layouts, which can potentially get quite messy, it is better to separate each sub-activity into its own Activity class and use explicit intents (intents that name the target activity explicitly rather than relying on an intent filter) to move between them.
The decision you have to make is whether or not your activities should be tightly or loosely coupled. Loading and unloading the activity is typically appropriate from within your own app. Using intents is appropriate when you need to open an activity that you may or may not know the specifics of. For example, you would open another activity from your main menu (assuming you have one) directly. Then later, let's say you need to open up an address with a map, you would use an intent, because you don't really know the SPECIFIC activity to open. Secondly, using intents are best for when there are multiple activities that could do the same function, such as opening a URL in a browser.
So in summary:
Open Directly (Loading a new view or using Intent specifying the Component Name)
Tightly coupled
Know specifics of the Activity to load
Open Indirectly (Intent specifying the category of Activities that can handle it)
Don't necessarily know the specifics of the Activity beyond that it can perform some action that has been advertised.
There are multiple Activities that can perform the desired action, and you want the user to be able to choose for themselves which Activity to use.
While Intents may be a little extra work, I'd recommend using them, if you don't directly need to pass large blocks of data back and forth between the two.
If you just need to pass information TO each of the sub-programs, then you can easily do that with putExtra(String key, Bundle values);
By using intents, you spend a little time now in order to have a lot of flexibility later. You can start intents from different points, so you'd not need to write new code if one of your sub-applications wanted to start a different one, or you wanted a certain filetype opened with a file manager to open one of your sub-programs.
Related
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 :(
I'm starting to work with Android, and as far as I have read, the main structure of an app is a group of more or less independent Activities where one is the main, and from there you launch one or another.
My problem is that some of those activities spend some time when they are created to generate some data, that is lost when the activity ends because of the paradigm of Android.
Also, I want to have some overall control of some parts of my program. For example, I activate a sensorListener in one activity, and I want to keep it working after I end that activity (by pressing "back" or launching another activity).
Is it possible to have some common structure to all the activities where I can place reusable data?
Also, I whould like my app to do something periodically , no matter what activity is working at the moment.
Do you know if there is a "well designed" way to program this overall data structure and periodic tasks?
You can use your "Application" class to have an entrypoint. This class won't get dealocated, you can save references in there, however, this is not a good style of programming but I have seen it a lot. If it's possible, a better way is to use threads, e.g. "AsyncTask" class. Here you can perform your operations and populate the activity on the fly.
As L7 pointed out you may use "service" as a long running background process for your sensor, this is also the recommended way of android.
I'm going through the tutorials for android and something about intent/activity interaction is confusing me. In Javascript whenever there is an ajax call we define how the results should be handled along with the ajax call and we can use different callbacks for different ajax calls throughout the application lifecycle. In android starting an activity with an intent and handling the passed back results are decoupled, at least that's how it's done in the tutorial and there is only a single point of entry for how the results are handled so it's hard to perform on the fly handling of results without messing with the main entry point. I can easily imagine some complex logic that could make the switching inside the main entry point into a horrible mess. Is this a fundamental android architectural thing or is there another way to do things with actual callbacks instead of switch statements in a single entry point?
It is true that you are limited to a single location for receiving responses that an activity has finished. It would be nice if you could define a callback function for each, but that is not how it works.
In my experience though, you seldom have so many different destinations from a single activity that it is hard to manage. Generally each page only leads to one or two other pages that you might care about getting results from.
You can do something like the following to cleanly separate your logic for each case:
void onActivityResult(int requestCode, ....) {
switch(requestCode) {
case Activity1:
onActivity1Result(...);
break;
case Activity2:
onActivity2Result(...);
break;
}
}
Intents and Activities are designed to allow developers to develop re-usable, loosely coupled components.
I understand that, when working internal between two activities that you are creating, the mechanisms can seem unnecessarily restrictive. The restrictiveness is part of the open nature of the platform. The same mechanism that you use to start an activity you own could start an Activity created by another developer or by the OS itself.
That being said, there are a plethora of options for passing information between activities. It really depends what you are trying to accomplish. I try to think of activities just that, activities from the users perspective. I'm going to list some mechanisms for passing data and, if you'd like to further describe your application or need, I'll try to help you narrow the options down:
Intent.putExtra
startActivityForResult (I'm assuming you know this one)
SharedPreferences
Service
ContentProvider
Also note that you do not have to start a new activity for a background process without its own screen such as an Ajax call - you can use AsyncTask instead which allows for a javascript style callback.
I have a Weather app with four Activities. The main/launcher activity is 'invisible' using...
android:theme="#android:style/Theme.Translucent.NoTitleBar"`
...and is simply used to do a few checks (whether this is a new install, whether a network connection is available etc) before firing off one of the other Activities. The other Activities are UI-oriented - two simply display weather data pulled from a website and the third to provide a location 'picker' so the user can choose which area to show the weather for.
However, all four activities make use of a WeatherHelper object which basically does everything from checking for available SD card storage to maintaining preferences and pulling/formatting website pages.
So, my question(s)...what is the best way to have one instance of WeatherHelper which can be used by multiple activities and where/how are best to create it in my case?
I've been an OO programmer for a lot of years but I'm very new to Android and the design concepts - I've read a lot on the Android Developers site over the past weeks but I've stalled trying to decide on this.
Any ideas gratefully received.
I would store shared information in you Application object. Subclass this and add any extra initialization and data there. You can get your application using getApplication() from your activity, which you can cast to your specialized version and access the shared data.
I would also avoid launching the special startup activity if possible and do the work in your Application's onCreate() override.
Well, your question has been answered, but it seems like it would be much simpler to instantiate your WeatherHelper object in the onCreate() of the Activity that has the launcher intent, and make the WeatherHelper static.
Is there a significant difference in time needed for sending data over a service or by using an intent?
Are there general advices when to use service and when to use intents?
These are two completely different things. The question isn't which is faster, but what you are trying to do.
If you want to transfer data from one activity to another, you pass it through the intent. If this is not sufficient for you (too much data for example), you can take other approaches but they will not involve a Service. For example, you may have a singleton holding your shared data, which both activities access... but be extremely careful about your process being killed at various points which causes the singleton to go away (and using a Service for this won't let you get away with not dealing with such a situation).
A Service is to do some work in the background even if the user isn't directly interacting with the app. Especially if we are talking about stuff within one .apk (and thus typically one process), there are very few other reasons to use a Service.
It depends of what you need.
Intent is preferable if you can. You will be able to send primitives from an activity to an other, and using startActivityForResult() you'll get an intent back to the caller Activity.
Service is for data processing in the background and can be very CPU/Memory consuming. With a Service, you have to create an interface between your Activity and the Service, so you can call basic methods of the Service directly from the Activity, you can control the service from the Activity.
This is really not the same purpose. Read documentation about Intents and the information you can Bundle in it, that's probably what you need.
When you want to pass data from your current activity to a new activity, the best is to pass a Bundle along with your Intent. It is used to pass on "acquired" user data.
Services run in the background while another activity is still in the foreground. "Background" doesn't mean that it doesn't display - most services have a graphic visualisation of some sort - it means that it isn't part of the activities stack. For example, your Activity may be sending a text message and your Service may be a soft keyboard. Services can communicate with activities - in this instance, your keyboard of course needs to send the characters to the text message Activity - but it often involves using a rather complex interface. It is used for collecting and passing on "live" user data to an Activity.
Many methods to pass data between activities. See here for tips on a way to choose.