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.
Related
In the course of creating an android library, I've learned I need to be able to open an activity from a generic library object and have the activity pass back data to the the library object. Normally, I would simply use startActivityForResult and call it a day, but in this case the library object will be using the client application's context. As such, any result would be sent to the client application and not to the library object.
So the flow would be something like this: Client instantiates our library object -> the library object determines it needs to present its own activity and does so -> library's activity returns data to the library object which can continue processing
I've tried a couple of different solutions but none seem to produce the desired results.
fragments - the issue I ran into here is that the fragment is tied to an activity which means it would need to somehow be tied to the client's activity in order for our object to get what it needs. So for our purposes this doesn't make sense to use.
Temporary splash screen - this is the route we're currently leaning towards since a basic splash screen would allow us to leverage our object on an activity we owned which could then call the activities it may need along the way and then return a response to the client's app in the activityForResult. The drawback of this design is that we were hoping to leverage a set of events which the client could code to when we fire them off. However this can be worked around if needed.
Also looked into leveraging the sharedPreferences but the issue there would be that when we returned to the client's activity we'd somehow need to "kick" the library to continue working. We don't want our clients to have to make multiple calls into our library. And spinning off a background thread to "poll" feels like very bad practice in this situation.
So what I'm looking for is whether the 2nd approach is really the only way to solve this or if there is another way in android development which I'm currently unaware of?
If you refer to any documentation about logging events (Facebook,GoogleAnalytics etc), or may be other different sdk things, you can see activation helper methods that take place in lifecycle of concrete activity.
Ex:
The best way, I guess, to put such methods in BaseActivity. But sometimes it's not possible coz of project issues, where I can't use BaseActivity.
Is there any another way to handle all these things together in one place, (like interfaces or something)?
Thanks!
The reason why you put it in each activity is because you want to know how much time a user is spending on each screen and track it. In your case if you want to simplify things add it in the application
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 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.
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.