Ok....I understand about the non-Activity context message...it seems that the problem is when the activity is re-created after an orientation change the new activity that launches from the alarm manager times out. Below is the code I use to set up my alarm, this code only runs on a button click (the setAlarm button) or if the activity is re-created and the alarmIsSet flag is true:
//determine what date the alarm is for whichDay(); //get the offset for when the alarm is supposed to start getEpochTime(); //create an intent to handle what happens when the alarm goes off alarmIntent = new Intent(v.getContext(), AlarmReceiver.class); //set up the PendingIntent for the alarm manager alarmSender = PendingIntent.getActivity(v.getContext(), 0, alarmIntent, 0); //set up the alarm manager AlarmManager alarmManager = (AlarmManager)getSystemService(ALARM_SERVICE); alarmManager.set(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + alarmEpochOffset, alarmSender); //set the flag for use if the activity gets re-created alarmIsSet = true; //Let the user know what time the alarm was set for Toast.makeText(v.getContext(), "Alarm is set for " + alarmString, Toast.LENGTH_LONG).show(); the part about alarmIsSet = true; is a flag I set so that I can save that in the onSaveInstanceState method...then if the activity gets restarted (because of an orientation change for instance) I can check this variable and set up the alarmManager again by using the above code with some differences (like I wouldn't need to call whichDay and getEpochTime() because this is data I am also saving the state of). Also when on destroyed is called I cancel this alarm and set the intent and PendingIntent to null so that I'm creating an entirely new alarm when the activity gets re-created. I hope this helps to shed some light on what is happening. The only thing I've been able to determine through debugging is that the AlarmReceiver Activity that is set in the intent times out if the orientation has changed and the Alarm activity has been re-created. If the orientation has not ever changed the Alarm Receiver class runs normally with no problems. Thanks for the info about the tab activity...I didn't think that the top level activity was the one being destroyed and re-started on an orientation change if I'm in one of the other tabs...but that seems to be the case so I'm not worried about that anymore. On Feb 22, 3:44 pm, Dianne Hackborn <[email protected]> wrote: > If the message says it was called from a non-activity context, then that is > what happened. You really haven't give a lot of information about what you > are doing, so I can only guess, but a few things: > > - This message will be shown if you are creating a PendingIntent to start an > activity which is given to the alarm manager, and does not have > FLAG_ACTIVITY_NEW_TASK set. This would have nothing to do with a particular > activity instance being recreated. > > - The message about starting from a non-Activity context does not mean it > won't do something... in fact, it is the opposite, as it says it is adding > the flag for you, and so it is going to do what you asked just with the flag > set. > > - Everything you describe about tab behavior (all activities being > recreated, because closing the entire top-level activity) is exactly how > those are expected to work. > > Actually, I realize I can't really help much, because I really can't see > what your problem is besides "it doesn't do anything when it should have." > What kind of intent are you registering with the alarm manager? What is > happening in your app that makes the alarm go off? Have you tried just > stepping through this code in the debugger to see why it is not running? > > On Tue, Feb 22, 2011 at 11:52 AM, Danielle Murkerson <[email protected] > > > > > wrote: > > Yes I have searched for things like this...I don't usually post a question > > until I've exhausted all other avenues of information...I have in fact > > searched for this and not a single relevant piece of information has > > surfaced...if you weren't going to add anything helpful, why did you even > > bother to reply? > > > On Tue, Feb 22, 2011 at 2:22 PM, Indicator Veritatis > > <[email protected]>wrote: > > >> OK, I admit, I didn't do THAT thorough a search myself, but this issue > >> of Alarms and orientation changes has been discussed so often before > >> in this group, I can't help but think that the answer lies somewhere > >> in the search results for "alarm orientation change". > > >> I will leave it to you to decide which of these best answers your > >> question(s). In the meantime, what I suggest to you is: I am not sure > >> why you think using a TabHost will cause separate activities to be > >> considered as one. A TabHost if, after all, just a container for a > >> tabbed VIEW. Which Activities correspond to which Views depends > >> entirely on you, depending on which choice you made of the two > >> described in the Tab Tutorial, where it says: > > >> "You can implement your tab content in one of two ways: use the tabs > >> to swap Views within the same Activity, or use the tabs to change > >> between entirely separate activities. " > > >> But since they say that right after mentioning the need for TabHost, > >> it should be pretty clear: the mere use of TabHost does not force that > >> choice. > > >> On Feb 22, 8:54 am, DanielleM <[email protected]> wrote: > >> > Hello all: > > >> > So, I'm trying to write my activities in such a way as to save their > >> > state if they ever get killed and restarted, and I've come across an > >> > interesting dilemma when working with the AlarmManager. > > >> > So the way my alarm Activity works is: > > >> > 1. Set time button: launches time picker dialog that is set to the > >> > current time (based on Calendar). Whatever time is chosen here becomes > >> > the time the user wants the alarm to go off. > > >> > 2. Radio buttons: let the user choose an audio file (in my case a > >> > stream) that they want to play when the alarm goes off > > >> > 3. Set Alarm button: calculates which day the alarm is for based on > >> > what time was chosen (will either be later today or tomorrow) and then > >> > calculates the offset in epoch time for the alarm manager. Next it > >> > creates the intent and pending intent for use with the Alarm Manager. > >> > Then it sets a flag (true) that the alarm was set and uses a Toast > >> > message to tell the user the alarm is set and for what time (this > >> > sounds like a lot and may need to go in a background task) > > >> > 4. Cancel alarm button: cancels the alarm obviously :) > > >> > So in my onSaveInstanceState method I'm saving all of the integers and > >> > strings that I used for my calculations and the flag of whether or not > >> > the alarm has been set. Then in the onCreate method I check to see if > >> > the saved bundle is null, if not I get all my data back out. > > >> > Then, I check to see if the alarmIsSet flag is true...if so, I go > >> > ahead and re-create the intent and Pending intent and use the alarm > >> > manager to set the alarm with my saved values....the only way the > >> > alarmIsSet flag will be true is if the Set Alarm button was clicked > >> > before the activity was destroyed and re-created...otherwise it will > >> > always be false. > > >> > So, on to my problem. If I set the time and set the alarm and then let > >> > it sit...it works totally fine....It launches my activity that handles > >> > the alarm (basically just plays one of the streams with a stop alarm > >> > button). > > >> > However, if I set up my time and click set alarm and then change the > >> > orientation, or if i set the time, change the orientation and then set > >> > the alarm...when it gets time for the alarm to go off it doesn't do > >> > anything. Then I found the following messages in the LogCat: > > >> > startActivity called from non-Activity context, forcing Intent > >> > FLAG_ACTIVITY_NEW_TASK for Intent (name of my intent) > >> > Activity pause timeout for HistoryRecord > >> > Launch timeout has expired, giving up wake lock > > >> > I don't understand how the first message can be possible...if the > >> > activity is getting recreated after the orientation change, and the > >> > intents are either created or re-created, how can it be a non- > >> > activity? > > >> > Now I plan to actually stop orientation changes from re-starting my > >> > activities, but I wanted to be able to save the state in case the > >> > activity gets killed by an incoming phone call or something else...so > >> > I'm using the orientation change as a way to test my save state code. > > >> > My app uses a tab layout with a tabhost...and I've noticed that it > >> > doesn't matter what tab I'm on when I change the orientation, but all > >> > of the activities are getting re-created...Also the back button will > >> > close the app instead of going back to a previous tab (if there is > >> > one) when you click it. > > >> > Correct me if I'm wrong, but this leads me to believe that even though > >> > all my tabs open separate activities, they are all considered one > >> > activity because of the tab host. Unless the back button will back > >> > track through tasks in which case this behavior is correct since all > >> > my activities are all part of the same task. > > >> > Anyway...any help that can be provided is much appreciated. > > >> > Thanks, > >> > DanielleM > > >> -- > >> 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 > > > -- > > 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 > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. -- 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
