[Q] Android app auto starts again when device rotated - Android Software Development

Hello all,
I've written a simple audio player app and testing it in Samsung Galaxy S.
It is a simple app with can create playlist and some buttons to play the mp3 file.
However, there's a funny bug in it.
After starting the app, whenever I rotate the phone, the running app will launch another instance of the app. If I rotate again, another instance (3rd) would be started. So u can hear 3 copies of the same audio being played simultaneously.
What could be wrong with it?
Is there some code which can prevent program re-entry?
Thanks.

It's not a bug, that's the way andorid OS works. You need to account for this in OnCreate for your activity. I assume you are spawning off the actual playing of the MP3 in a thread or service. You need to check if the service is already running in OnCreate and attach, else spawn a new one.

Hello Gene,
How do I check if an activity is already running?
I could not find the answer on the android developer page (the topic on application fundamentals).
And no, I'm not converting it to a service yet as this is my first app.
Haven't explore service yet.
Thanks.

I read on another article, a simple way to prevent this is to add overwrite the onConfigurationChanged function
@Override
public void onConfigurationChanged(Configuration newConfig) {
//ignore orientation change
super.onConfigurationChanged(newConfig);
}
and modify the androidmanifest.xml
<activity android:name="selectCategories" android:configChanges="orientation|keyboardHidden"></activity>
But it still launch multiple instance of the app.
Thanks.

This is a good question and should be in an FAQ somewhere.
As already mentioned, changing the display orientation basically restarts your app. Read the Android dev page on Activity lifecycle for more info.
A short answer for your question is: the Bundle parameter for onCreate() will be null when your app is first run. When your app is paused and restarted, that Bundle will be non-null. You can store data in that Bundle by overriding onSaveInstanceState(), then check for that data in onCreate(). It's a good idea to learn how to do this (save/read app data on pause/restart). Once you start testing apps by rotating the display at various times, you'll find a lot of them FC at unexpected places.

This is indeed a topic that keeps surprising people who are new to android (ahem, like me 4-5 months ago ).
The solutions above are perfect, however in certain situations there's another trick that might make your life much easier. I suspect it won't help you in this case, but it might help others who tackle the problem and see this thread.
Certain applications, mainly games, should be fixed in a single orientation. I.E. you won't be playing angry birds on portrait - that game is locked to landscape, as it should be. In order to lock your activity in a certain orientation you add this attribute to the manifest under the Activity tag. So a standard activity might look something like that, combined with the ignore tag from the previous posts:
Code:
<activity android:screenOrientation="landscape" android:configChanges="orientation|keyboardHidden"
android:name="whatever">
The great thing about this combination is that your activity will not restart at all when the phone is rotated. Of course, for a standard activity you'd usually want to support both landscape and portrait, but if you need your app to be in a fixed orientation this is the way to go - no weird FCs or annoying bugs

Hi,
How do I check the bundle?
And also, what to do if the bundle is not null? Just return?
Thanks.
regards
r_p_ang said:
This is a good question and should be in an FAQ somewhere.
As already mentioned, changing the display orientation basically restarts your app. Read the Android dev page on Activity lifecycle for more info.
A short answer for your question is: the Bundle parameter for onCreate() will be null when your app is first run. When your app is paused and restarted, that Bundle will be non-null. You can store data in that Bundle by overriding onSaveInstanceState(), then check for that data in onCreate(). It's a good idea to learn how to do this (save/read app data on pause/restart). Once you start testing apps by rotating the display at various times, you'll find a lot of them FC at unexpected places.
Click to expand...
Click to collapse

Related

[Q] Each view a new activity?

I'm learning how to program in android and want to make a musicplayer. The problem I have now is I have no idea how to build the views for the application. For example if you start the application you have the options, all songs, artists, albums. If you then select artists you get all the albums from that artist, if you select an album you get the songs etc..
Now my problem. Do I have to make a different activity per view (all songs view, artist view, album view), because they all do almost the same, just fill a listview with some data.
Can sombody point me to a tutorial of give me a hint how to do this because I'm trying to find a solution for 2 weeks now and all 101 "noob" basic tutorial I found don't cover this.
Thanks in advance.
Nobody who can point me to the right direction?
I would create a new activity for each, but create a base class that has the listview in it. Then in each new activity, just inherit from that base class and call a method to fill in that list view with the data specific to that particular activity.
-frank
Sent from my PC36100 using XDA App
Hello!
I'm only new to android development too but I'd suggest two things. Firstly you need to make sure the music playing is being done by a service so it works in the background. Secondly, I don't think you'll need a different activity for each view. List views are populated by adapters if I remember right so maybe one view to choose the music filter and the next view will choose the correct adapter and populate the list....
Hope this helps a little.
Sent from my X10i using XDA App
@kaediil, I think I try that, I'm open for other suggestion tho.
@Keithod, the mechanics to play a song are already done, the vies are the only problem. And I tried it with adapters but how am I'm going to handle the onclick then? That would be one hell of a switch statement.
Is there a tutorial that handles these kind of problems?
If your music player created a database of the metadata, artist, album etc. Then your adapter could use the ID of the element that was clicked as the criteria for the select statement... No switch required and only one activity...
Sent from my X10i using XDA App
I now get the id3 tag from the song and build the views that way, I could dump it in a database when the application start. Let me try that.
After a couple of days I am still stuck, I prefer a tutorial or a snippet how I could fill 1 listview and when I click a specific item another listview or the same will be filled with other items.
Hope somebody can help me with this.
What went wrong with the database idea?
Sent from my X10i using XDA App
Then I still have to display it, or it's from an arraylist or database.
Try using a ViewFlipper: http://developer.android.com/intl/zh-CN/reference/android/widget/ViewFlipper.html
You don't need to have one Activity for every view, you can choose to display different info depending on the previous Screen or if the user has clicked a different button.
An example:
- An user clicks on a button that goes to PSN and recover a list of latest games played by the user with his playstation.
- You put a flag on the Bundle Extras to indicate to the next ListView activity that you want a PSN info.
- In the ListView Activity you recover info from PSN. If the user clicks on the Xbox Live button you use the same Activity to query Microsoft's website. You can even load a different XML Layout for PSN or Xbox Live in that same Activity and have 2 completely different Layouts for a single Activity:
Code:
if (xbox)
setContentView(R.layout.achievements_xbl);
else
setContentView(R.layout.trophies_psn);
Anyway, if the methods are not shared to display different info in the Activities is a good practice to have different Activities Classes, you can have one XML Layout if the List Rows are similar and use in two different Activities.
Helper Classes, to separate business code from Activities are also a great tool.

keeping a service and an activity in-sync

I'm working on a music player and I'm running my MediaPlayer object within a service so that I can run other stuff while the music is playing. For the most part this works. If I leave the activity for any reason (like hitting the "home" key), then go back, I BindService in OnCreate and this usually links me to the already running service and I can pick up where I left off. However, sometimes BindService launches a new service and the original becomes orphaned. Then I've got two songs playing on top of each other and I have to kill the whole process with a task killer to stop the orphaned service. I can't seem to figure out what set of conditions causes this so it's difficult to debug.
Any ideas?
After tons of searching, I found some informative posts over at stackoverflow.com. Seems that if you bind to a service using the default ContextWrapper, you can get a different context with a different instance of an activity. If you use the application context (from GetApplicationContext) for binding, it should always bind to the same service.
Thank you for posting the solution.

Communication between Service & Activity

Hello
I want to create an Android App. In the last days i read a lot of Android API Documentations, Tutorials and "how do do's". Now I'm really confused, because on one hand, it's nice to have so many possibility, but on the other it confuses me, whats the best way to do it. So I played a little with Activity life-cycle.
Now I'm going to start to build my first 'real' App.
This App should download initial data from a Webservice, process these data with a database, download more data related to results from a database, save these data again to database, and make it accessible in the Acitvity.
So please correct me if I'm wrong from this point on:
I assumend that a Android Service is the best way, to process these Data in a background-worker-thread.
So far so good. So I read about the Android Handler which seems to be a pipeline, so Threads can work on the Handler message queue. I can Access the Service from within my MainActivity over the ServiceConnection.onServiceConnetcted where I recieve a simple Binder which gives me access to my Service. From there i can put Messages in the Message queue from the HandlerThread. But how I can tell my Acitivity from within the Service, that it has finished Processing and send the Data to it?
I read that I don't have to use AIDL since the Service is running in the same Process. But How can I do it then? I tried to call onBind() in the Service, hoping OnServiceConnected will be triggered in the Acitvity which initially Binds these Services, but it doesn't seem to work. I also tried to "hack" the Funktionality, by spending my Service a singleton member "MyMainActivity" with corresponing static setMainActivity(MyMainActivity activity), calling it in the ServiceConnector onServiceConnected, with the same result: Runtime Error
I even don't think I understand the functionality behind these HandlerThread.
will it loop infinitly waiting for HandlerMessages while draining the Battery, or is it on a wait() status since it recieves a message?
I read the Android API about Services but for me, it seems that they only describe to Access the Service from the Activity, and not the other way round.
If I call a method of my Service within my Activity over the ServiceBinder, which has a return value, but was started in another Thread in my Service, how will my Activity know that it processes finish? 'busy waiting' on a boolean member of my Service doesn't seem to be the way to go. If I do that, like I saw in a tutorial, I don't see a reason not to do the work in the Activity Thread itself.
I read also about an AsyncTask, but this doesn't seem to be practicable for me, because I have to do different work related to JSON Objects I get.
Please you expirienced Android guys: show me the way.
You probably don't need a full-fledged service if you just need a background thread. Services can run independent of an activity and reconnect, etc. If you don't intend for the thread to be stand-alone, then just use a class that implements Runnable. Since you seem to have a handle (no pun intended) on handlers, this won't be too hard. Just post a message to your handler from your thread to let the activity know what's going on.

Detect Package Launch

I am working on an application and I need to be able to have a service that can detect when applications are opened, and take action based on that.
I have looked everywhere, and have not found a way to do so. I have read documentation on broadcast receivers, intent handlers, I found nothing.
I did however, find an app that can do so. App Protector. It allows password protecting certain applications.
Can anybody please point me in the right direction?
Thanks!
this is actually a very good question. a BroadcastReciever only gets Intents directed at it, and wouldnt see Intents for other classes and Packages.
ill be very interested to know the answer
killersnowman said:
this is actually a very good question. a BroadcastReciever only gets Intents directed at it, and wouldnt see Intents for other classes and Packages.
ill be very interested to know the answer
Click to expand...
Click to collapse
Well I was looking for a BroadcastReceiver that was sent out by the system to indicate that an app was opened, but I did not come across anything.
this isnt possible.. to be able to monitor all intents would make android extremely insecure
http://groups.google.com/group/android-developers/browse_thread/thread/54ddc9d36a24d77b
but there are ways to know when an application is launched. you just have to be creative.
this will give you a list of all the applications running.
Code:
ActivityManager am = (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE);
List<ActivityManager.RunningAppProcessInfo> runningAppProcessInfo = am.getRunningAppProcesses();
however to know when an app is launched you would need a timed loop and then check between versions of the List to see if there is a new app. this would suck the juice and be inneficient
AppProtector seem to access the eventlog. maybe you could have a ContentObserver attached to the event log
http://developer.android.com/reference/android/util/EventLog.html
http://developer.android.com/reference/android/database/ContentObserver.html
killersnowman said:
this isnt possible.. to be able to monitor all intents would make android extremely insecure
http://groups.google.com/group/android-developers/browse_thread/thread/54ddc9d36a24d77b
but there are ways to know when an application is launched. you just have to be creative.
this will give you a list of all the applications running.
Code:
ActivityManager am = (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE);
List<ActivityManager.RunningAppProcessInfo> runningAppProcessInfo = am.getRunningAppProcesses();
however to know when an app is launched you would need a timed loop and then check between versions of the List to see if there is a new app. this would suck the juice and be inneficient
AppProtector seem to access the eventlog. maybe you could have a ContentObserver attached to the event log
http://developer.android.com/reference/android/util/EventLog.html
http://developer.android.com/reference/android/database/ContentObserver.html
Click to expand...
Click to collapse
Interesting.
I also found this:
Code:
String str = ((ActivityManager.RunningTaskInfo)this.am.getRunningTasks(1).get(0)).topActivity.getPackageName();
It's one of the things App Protector uses
It starts a new intent, pointing to their application, and passing the parameters of the package you tried to run
Take a look at Tasker it can defiantly do this.
rujelus22 said:
Take a look at Tasker it can defiantly do this.
Click to expand...
Click to collapse
He doesn't want it for scripting, but for use in his own program.
From something awesome

Intent filters

Ok so i used to be a very experienced actionscript user. But i recently wanted to get back into programming so im learning java now or rather trying to.
So im trying to understand the xml side of this so far and have some questions im hoping u guys can answer.
activities
So as i understand it an activity is a screen in an app. So for example the standard launcher on my phone has pages of apps on my main screens. Each one of those would be an activity? And then another activity for when i press the button to display all installed apps?
Have i understood that properly?
intent filters
This is where im getting confused. Ive googled it and read as much as i can find. As i read it, feel like someones explaining rocket science to a 5 year old.
The words component and instances is being thrown around enough that i got no clue whats even being said. What i have understood is it gives data to the activity.
So a best guess from my partwould be its telling it how the screens going to work or maybe like if theres going to be a button on it maybe. Or perhaps it means something different like just the properties sort of stuff like screen size or stuff of that nature.
As u guys can probably tell im confused beyond comprehension. I got no idea how good my grasp is of any of this. But if theres someone out there kind enough to dumb it down a bit so normal people can understand it. Id be very gratefull.
Bump
Bump
Hey,
unfortunately i cant answer your question. This is a part of android I don't understand too.
I think you should post your question again in the Question and Answer forum of XDA. http://forum.xda-developers.com/android/help maybe there is an developer who can help you.
Greetings
Thanks ill post there and see if it makes any difference
Android apps run in sandboxes. Consider a huge box partitioned into 'n' number of sections. Each partitions represent a place in android environment where app can reside. By sandboxing, app are given unique ID(UID) when they start a process. Only apps having same (UID) can access the app's resources so no malicious app can peek into the resources of other app.
If apps cannot see other resources, how could they communicate within apps? Thats where intent comes in. Intents are like post letters and android is the postman. You can either give:
1. Recipient address, here, the package name of the app for which the intent is to be sent and may include your data in the intent if there is any and the postman (android) delivers it to the right person (target app). This is also known as explicit intent because you know the target class to call
2. Intent filter - This is not as specific as the first one. Here, your app has to perform something using an external app but your app doesnt know of the other apps which could perform the action. So, this time it will go for a broadcast and say "Hey! I need to take a picture! All camera apps please come in" and the broadcast is sent by android which displays list of apps which respond to this broadcast. When the user chooses the app to perform the action, the app fires, performs the task for your app, return the data to your app in form of intent result.
To register an app to respond to this type of intent, the app specifies something called intent-filter in their manifest which says the android, in our example context "I can perform camera action". So next time intent for camera action is sent, the app is in the list of apps to perform action with. This type of intent in implicit intent as you let the android and user decide the app. You can also specify your own custom intent-filters apart from standard android ones.
vijai2011 said:
Android apps run in sandboxes. Consider a huge box partitioned into 'n' number of sections. Each partitions represent a place in android environment where app can reside. By sandboxing, app are given unique ID(UID) when they start a process. Only apps having same (UID) can access the app's resources so no malicious app can peek into the resources of other app.
If apps cannot see other resources, how could they communicate within apps? Thats where intent comes in. Intents are like post letters and android is the postman. You can either give:
1. Recipient address, here, the package name of the app for which the intent is to be sent and may include your data in the intent if there is any and the postman (android) delivers it to the right person (target app). This is also known as explicit intent because you know the target class to call
2. Intent filter - This is not as specific as the first one. Here, your app has to perform something using an external app but your app doesnt know of the other apps which could perform the action. So, this time it will go for a broadcast and say "Hey! I need to take a picture! All camera apps please come in" and the broadcast is sent by android which displays list of apps which respond to this broadcast. When the user chooses the app to perform the action, the app fires, performs the task for your app, return the data to your app in form of intent result.
To register an app to respond to this type of intent, the app specifies something called intent-filter in their manifest which says the android, in our example context "I can perform camera action". So next time intent for camera action is sent, the app is in the list of apps to perform action with. This type of intent in implicit intent as you let the android and user decide the app. You can also specify your own custom intent-filters apart from standard android ones.
Click to expand...
Click to collapse
Gave u a thanks fkr that very useful responce. Thank you. So if ive understood this right. If i want to take a picture for example the intent filter part basically calls out for an external app to perform the action. With intent filter so basically when an app asks u with that menu what app youd like to choose thats an intent filter? And implicent thats the same menu or android just chooses it for you? Im trying to picture it from the user-side
Recipient address seems straight forward. You know u need an app and what its called. So u dont even need the user to select anything.
scorpafied said:
Gave u a thanks fkr that very useful responce. Thank you. So if ive understood this right. If i want to take a picture for example the intent filter part basically calls out for an external app to perform the action. With intent filter so basically when an app asks u with that menu what app youd like to choose thats an intent filter? And implicent thats the same menu or android just chooses it for you? Im trying to picture it from the user-side
Recipient address seems straight forward. You know u need an app and what its called. So u dont even need the user to select anything.
Click to expand...
Click to collapse
Your understanding on implicit intent is correct. To make it even more short an precise,
An intent is an abstract definition of the operation to be performed by the app
Click to expand...
Click to collapse
When the target action is known, say you invoke a second activity of you app. You know the target action (the class name), that is your implicit intent. You decide what action to perform without user intervention here. Explicit usually needs user input for inter-app communication to take place.
Examples of few implicit intents:
Starting an activity
Starting a service
vijai2011 said:
Your understanding on implicit intent is correct. To make it even more short an precise,
When the target action is known, say you invoke a second activity of you app. You know the target action (the class name), that is your implicit intent. You decide what action to perform without user intervention here. Explicit usually needs user input for inter-app communication to take place.
Examples of few implicit intents:
Starting an activity
Starting a service
Click to expand...
Click to collapse
Ok cool. So recipient is when we choose the app. Intent is whwn they get a menu to choose it. And implicent is is when android chooses it for them.
Sounds simple enough. Thanks for all the help buddy
And would i be right in assuming that the actions we put in intent filters and the others in form it of stuff like when its triggered, how often and so forth?

Categories

Resources