[android-developers] Scheduling a recurring Intent to fire off twice a day
After reading lots of sample code into this matter, I'm trying to
figure out the simplest way to achieve the following:
I want to be able to schedule an Intent that calls back to my Alarm
BroadcastReceiver, which in turn fires off my Service. However, I want
to set up so that it calls said Intent twice a day and to only
schedule the alarms if they haven't already been set (likewise for
canceling the alarms).
However, I am unsure if the following code is the correct way to set
and cancel alarms.
//Static function for setting the alarm
//My midday calendar object (cal1)
...
//My evening calendar object (cal2)
Intent myIntent = new Intent(context, MyAlarmReceiver.class);
PendingIntent firstCallIntent =
PendingIntent.getBroadcast(context, FIRST_CALL_ID, myIntent,
PendingIntent.FLAG_NO_CREATE);
PendingIntent secondCallIntent=
PendingIntent.getBroadcast(context, SECOND_CALL_ID, myIntent,
PendingIntent.FLAG_NO_CREATE);
if(firstCallIntent != null){
if(DEBUG){
Log.d(TAG, Setting Midday Alarm);
}
firstCallIntent = PendingIntent.getBroadcast(context,
FIRST_CALL_ID, myIntent, 0);
alarms.setInexactRepeating(AlarmManager.RTC_WAKEUP,
cal1.getTimeInMillis(), AlarmManager.INTERVAL_DAY, firstCallIntent);
}
if(secondCallIntent != null){
if(DEBUG){
Log.d(TAG, Setting Evening Alarm);
}
secondCallIntent = PendingIntent.getBroadcast(context,
SECOND_CALL_ID, myIntent, 0);
alarms.setInexactRepeating(AlarmManager.RTC_WAKEUP,
cal2.getTimeInMillis(), AlarmManager.INTERVAL_DAY, secondCallIntent);
}
//Static call to cancel the alarm.
Intent myIntent = new Intent(context, MyAlarmReceiver.class);
PendingIntent firstCallIntent =
PendingIntent.getBroadcast(context, FIRST_CALL_ID, myIntent, 0);
alarms.cancel(firstCallIntent);
firstCallIntent.cancel();
PendingIntent secondCallIntent =
PendingIntent.getBroadcast(context, SECOND_CALL_ID, myIntent, 0);
alarms.cancel(secondCallIntent);
secondCallIntent.cancel();
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Scheduling a recurring Intent to fire off twice a day
You have to assume that the functions already have an instance of
AlarmManager.
AlarmManager alarms = (AlarmManager)
context.getSystemService(Context.ALARM_SERVICE)
But yeah, I just need to know if I'm setting it up correctly.
On Jan 6, 3:02 pm, Kristopher Micinski krismicin...@gmail.com wrote:
Sorry, now see you've at least heard of the class :-), but you don't
seem to be using it in the standard way.., usually you will set an
alarm using the alarm manager.
kris
On Fri, Jan 6, 2012 at 2:01 PM, Kristopher Micinski
krismicin...@gmail.com wrote:
Have you heard of AlarmManager?
http://developer.android.com/resources/samples/ApiDemos/src/com/examp...
http://developer.android.com/reference/android/app/AlarmManager.html
Kris
On Fri, Jan 6, 2012 at 1:38 PM, Diego Tori
diegotoridoesandr...@gmail.com wrote:
After reading lots of sample code into this matter, I'm trying to
figure out the simplest way to achieve the following:
I want to be able to schedule an Intent that calls back to my Alarm
BroadcastReceiver, which in turn fires off my Service. However, I want
to set up so that it calls said Intent twice a day and to only
schedule the alarms if they haven't already been set (likewise for
canceling the alarms).
However, I am unsure if the following code is the correct way to set
and cancel alarms.
//Static function for setting the alarm
//My midday calendar object (cal1)
...
//My evening calendar object (cal2)
Intent myIntent = new Intent(context, MyAlarmReceiver.class);
PendingIntent firstCallIntent =
PendingIntent.getBroadcast(context, FIRST_CALL_ID, myIntent,
PendingIntent.FLAG_NO_CREATE);
PendingIntent secondCallIntent=
PendingIntent.getBroadcast(context, SECOND_CALL_ID, myIntent,
PendingIntent.FLAG_NO_CREATE);
if(firstCallIntent != null){
if(DEBUG){
Log.d(TAG, Setting Midday Alarm);
}
firstCallIntent = PendingIntent.getBroadcast(context,
FIRST_CALL_ID, myIntent, 0);
alarms.setInexactRepeating(AlarmManager.RTC_WAKEUP,
cal1.getTimeInMillis(), AlarmManager.INTERVAL_DAY, firstCallIntent);
}
if(secondCallIntent != null){
if(DEBUG){
Log.d(TAG, Setting Evening Alarm);
}
secondCallIntent = PendingIntent.getBroadcast(context,
SECOND_CALL_ID, myIntent, 0);
alarms.setInexactRepeating(AlarmManager.RTC_WAKEUP,
cal2.getTimeInMillis(), AlarmManager.INTERVAL_DAY, secondCallIntent);
}
//Static call to cancel the alarm.
Intent myIntent = new Intent(context, MyAlarmReceiver.class);
PendingIntent firstCallIntent =
PendingIntent.getBroadcast(context, FIRST_CALL_ID, myIntent, 0);
alarms.cancel(firstCallIntent);
firstCallIntent.cancel();
PendingIntent secondCallIntent =
PendingIntent.getBroadcast(context, SECOND_CALL_ID, myIntent, 0);
alarms.cancel(secondCallIntent);
secondCallIntent.cancel();
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Scheduling a recurring Intent to fire off twice a day
Also, the pending intents that I check with FLAG_NO_CREATE should be
checking if said intents returned null in order to set them.
On Jan 6, 3:37 pm, Diego Tori diegotoridoesandr...@gmail.com wrote:
You have to assume that the functions already have an instance of
AlarmManager.
AlarmManager alarms = (AlarmManager)
context.getSystemService(Context.ALARM_SERVICE)
But yeah, I just need to know if I'm setting it up correctly.
On Jan 6, 3:02 pm, Kristopher Micinski krismicin...@gmail.com wrote:
Sorry, now see you've at least heard of the class :-), but you don't
seem to be using it in the standard way.., usually you will set an
alarm using the alarm manager.
kris
On Fri, Jan 6, 2012 at 2:01 PM, Kristopher Micinski
krismicin...@gmail.com wrote:
Have you heard of AlarmManager?
http://developer.android.com/resources/samples/ApiDemos/src/com/examp...
http://developer.android.com/reference/android/app/AlarmManager.html
Kris
On Fri, Jan 6, 2012 at 1:38 PM, Diego Tori
diegotoridoesandr...@gmail.com wrote:
After reading lots of sample code into this matter, I'm trying to
figure out the simplest way to achieve the following:
I want to be able to schedule an Intent that calls back to my Alarm
BroadcastReceiver, which in turn fires off my Service. However, I want
to set up so that it calls said Intent twice a day and to only
schedule the alarms if they haven't already been set (likewise for
canceling the alarms).
However, I am unsure if the following code is the correct way to set
and cancel alarms.
//Static function for setting the alarm
//My midday calendar object (cal1)
...
//My evening calendar object (cal2)
Intent myIntent = new Intent(context, MyAlarmReceiver.class);
PendingIntent firstCallIntent =
PendingIntent.getBroadcast(context, FIRST_CALL_ID, myIntent,
PendingIntent.FLAG_NO_CREATE);
PendingIntent secondCallIntent=
PendingIntent.getBroadcast(context, SECOND_CALL_ID, myIntent,
PendingIntent.FLAG_NO_CREATE);
if(firstCallIntent != null){
if(DEBUG){
Log.d(TAG, Setting Midday Alarm);
}
firstCallIntent = PendingIntent.getBroadcast(context,
FIRST_CALL_ID, myIntent, 0);
alarms.setInexactRepeating(AlarmManager.RTC_WAKEUP,
cal1.getTimeInMillis(), AlarmManager.INTERVAL_DAY, firstCallIntent);
}
if(secondCallIntent != null){
if(DEBUG){
Log.d(TAG, Setting Evening Alarm);
}
secondCallIntent = PendingIntent.getBroadcast(context,
SECOND_CALL_ID, myIntent, 0);
alarms.setInexactRepeating(AlarmManager.RTC_WAKEUP,
cal2.getTimeInMillis(), AlarmManager.INTERVAL_DAY, secondCallIntent);
}
//Static call to cancel the alarm.
Intent myIntent = new Intent(context, MyAlarmReceiver.class);
PendingIntent firstCallIntent =
PendingIntent.getBroadcast(context, FIRST_CALL_ID, myIntent, 0);
alarms.cancel(firstCallIntent);
firstCallIntent.cancel();
PendingIntent secondCallIntent =
PendingIntent.getBroadcast(context, SECOND_CALL_ID, myIntent, 0);
alarms.cancel(secondCallIntent);
secondCallIntent.cancel();
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Fetching a GPS Network Location within a short time frame (10 seconds)
I'm trying to set up a quick and dirty GPS lookup via LocationManager
which fetches a network location (within 500 meters) every half second
for ten seconds. In other words, I'm just trying to find the correct
coarse Criteria settings and the correct logic to stop checking after
10 seconds of no better locations within my Handler thread.
I'm thinking my main loop should look something like this:
/**
* Iteration step time.
*/
private static final int ITERATION_TIMEOUT_STEP = 500;
public void run(){
boolean stop = false;
counts++;
if(DEBUG){
Log.d(TAG, counts= + counts);
}
//if timeout (11 secs) exceeded, stop tying
if(counts 22){
stop = true;
}
//location from my listener
if(bestLocation != null){
//remove all network and handler callbacks
} else {
if(!stop){
handler.postDelayed(this, ITERATION_TIMEOUT_STEP); //
half-sec intervals
} else {
//remove callbacks
}
}
}
What I want to know is after I fetch the last known location as my
initial best location and kick off my thread, how do I set up the
coarse criteria so that I receive a more accurate one than the initial
one (in order to compare the two), which is diametrically different
from my current location?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Fetching a GPS Network Location within a short time frame (10 seconds)
Yeah, after adopting your advice, I was able to find a good starting last known location from all providers, then spin up my listener to do the comparison, at which after 10 seconds, it kicked off my message thread to shut everything down and send the result back to my callback. It was close enough the returned location. On Dec 22, 6:43 pm, TreKing treking...@gmail.com wrote: On Thu, Dec 22, 2011 at 5:04 PM, Diego Tori diegotoridoesandr...@gmail.comwrote: What I want to know is after I fetch the last known location as my initial best location and kick off my thread, how do I set up the coarse criteria so that I receive a more accurate one than the initial one (in order to compare the two), which is diametrically different from my current location? You're over-complicating this. Get that last known location - that's your base, assuming it's not null. Register a listener for new update using whatever criteria you need. Immediately after, post your 10 second stop message. If and when your listener is hit, save that as the best location. When you stop message is called, remove the callback and use the last one found. There's no need for this every half second stuff. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Touch to erase portions of foreground ImageView to expose background View
So I've been struggling with this for a better part of a day. Suppose
I have a custom ImageView that I want to overlay over a background
View (both within a RelativeLayout), which when touched, it erases
portions of the View's source bitmap like the erase tool in MS Paint,
exposing the View below it. I've checked pretty much all of the
threads (like this one:
http://groups.google.com/group/android-developers/browse_thread/thread/5b0a498664b17aa0/de4aab6fb7e97e38?lnk=gstq=erase+transparent#
) and they suggest to use PorterDuff SRC Mode in the Paint object as
well as creating a Canvas out out the ARGB_ shadow copy of the
source bitmap to apply the masking.
Also, I can't set the source of the overlay ahead of time since I have
to download it over the network so that the ImageView's scale type
takes care of the scaling for me.
Every time I override onDraw, when I apply the erase on the IV's
Bitmap, it unveils a black background instead of the view below it,
even though I set the background to transparent. So I'm at my last
rope as to what to do in order to unveil the background view.
Here's what I have so far:
view constructor:
paint.setXfermode(new
PorterDuffXfermode(PorterDuff.Mode.CLEAR));
paint.setColor(Color.TRANSPARENT);
paint.setStyle(Paint.Style.STROKE);
paint.setStrokeJoin(Paint.Join.ROUND);
paint.setStrokeWidth(STROKE_WIDTH);
paint.setAntiAlias(true);
overrode setImageBitmap to set my canvas from my re-configed source
bitmap:
public void setImageBitmap(Bitmap bitmap){
super.setImageBitmap(bitmap);
Drawable bd = getDrawable();
if(bd == null){
return;
}
Bitmap fullSizeBitmap = ((BitmapDrawable) bd).getBitmap();
overlay = fullSizeBitmap.copy(Config.ARGB_, true);
c2 = new Canvas(overlay);
}
onDraw method:
protected void onDraw(Canvas canvas) {
/*
* Override paint call by re-drawing the view's Bitmap first,
then
overlaying our path on top of it
*/
Drawable bd = getDrawable();
if(bd == null){
return;
}
Bitmap fullSizeBitmap = ((BitmapDrawable) bd).getBitmap();
if(fullSizeBitmap != null c2 != null){
canvas.drawColor(Color.TRANSPARENT);
c2.drawBitmap(fullSizeBitmap, 0, 0, null);
c2.drawPath(path, paint);
canvas.drawBitmap(overlay, 0, 0, null);
}
}
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Toggling ViewSwitcher children on GridView click and focus change
Right now, suppose I have a GridView with ViewSwitchers, and what I want to do is when the user clicks on an item, it switches my ViewSwitcher to the second child. However, when a user scrolls away from that item or clicks another one, I want it to reset the switcher for that previous item back to the first child. For the first one (clicking), is it just a matter of casting the incoming view in onItemClick as ViewSwitcher, and then doing the switch from there? For the second one (focus change), what callback will I need to switch back that previously clicked item back to its first child? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Adapting ImageDownloader enhancements to my app
Right now, I'm trying to modify ImageDownloader (http:// code.google.com/p/android-imagedownloader/source/browse/trunk/src/com/ example/android/imagedownloader/ImageDownloader.java) so I can implement a couple of enhancements particular to my app: First, I am going to adapt the code to utilize hard and soft HashMaps for a few different types of bitmaps for different aspects of my app called from my singleton cache object. In other words, I will add a constructor that will specify the type of image that I want to cache (defined by a pre-determined State ID), that way, my cache object only saves to and loads from those particular HashMaps for that type of Bitmap I want to download. I am wondering whether I should just create pairs of hard and soft hashmaps like the class for every type of Bitmap I need to cache separately, or whether I should just create one soft hashmap that the other hard ones dump their old images into? Second, since I want to incorporate caching to either cache or SD card (via flag from constructor), would it make sense that it be the last check it performs in getBitmapFromCache, and if it does recover the image from SD, do I have to add it back to the hard cache? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Broadcasting custom intent actions to background activities from foreground activity.
So you're saying in this case it's better to just populate the UI in onResume for data that is dependent on the outcome of that event? That would be the case for a couple of activities that depend on it. However, I'm more concerned about the performance impact, since this data in particular has dozens of members and if I have to re-create the UI every time onResume is called, it will create a bad UX within those Activities, even if I put up a loading screen and use a thread. I guess one way to reduce the number of unnecessary data refreshes is once my event occurs, I save a timestamp to my in-memory cache, and then every time an activity is added to the stack, it retrieves that value and keeps it there. As a result, every time the user generates the event, all the other activities below it will check the new timestamp in onResume and if the latest one is greater than the one the activity has, it refreshes itself and its current timestamp value. Also, my app guarantees that this event will occur when it first starts up, before it launches its home activity, so there will be a timestamp available. On Jun 8, 5:02 pm, Mark Murphy mmur...@commonsware.com wrote: On Wed, Jun 8, 2011 at 4:16 PM, Diego Tori diegotoridoesandr...@gmail.com wrote: That's the thing, if I set a shared preference flag or cached flag via cache object, and they did try to check for that value in onResume, wouldn't the first activity from the back stack to get the foreground check its state, then set it back to false after checking for it being true before having to do work? Delete the flag. You don't need the flag. Update the UI of the activity in onResume(). Period. Even if I didn't reset the flag, every time it would hit that function, it would still get caught in that flag, so that isn't really useful. Hence, get rid of the flag. Update the UI of the activity in onResume(). Period. So there is no way that I can just broadcast one intent that my listening activities can listen to after the intent is sent as soon as they get the foreground again? What makes you think that your activity even exists? Your non-foreground activities may not even be in memory, because Android may have destroyed them to save RAM. If you simply update your UI in onResume(), it handles both the activity-in-RAM and the activity-out-of-RAM scenario. Your proposed model is akin to: every time Google indexes a new page, it proactively updates every browser on the face of the planet, even those that do not use Google, do not care about the newly indexed page, or are not even running. Keep in mind that this is not a one-time event. All the more reason to not push updates out to activities that do not yet need the information. Rather it is an event that the user generates, all I want those other activities to know is whether or not the event was generated by the user while in the background. So, update the UI of the activity from your persistent store or in-memory cache in onResume(). Period. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android 3.0 Programming Books:http://commonsware.com/books -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Broadcasting custom intent actions to background activities from foreground activity.
That could also work, since it would keep things simple and efficient. I think this approach makes more sense anyways, since I can fill out my onResume functions to first check for latest versions of said number and if it's newer, then invalidate old data, fetch new set, and populate, or whatever else that needs to be done regarding that new event. On Jun 9, 12:02 pm, Dianne Hackborn hack...@android.com wrote: Yes only updating when the data has changed is a good approach. Instead of a timestamp, I would suggest just using a sequence number that you increment every time the data has changed. This technique is used in a lot of places in Android -- for example to know when the locale cache of the Settings provider values is out of date, or when dispatching a new Configuration to determine if it is a newer one than the last one that was handled. On Thu, Jun 9, 2011 at 7:59 AM, Diego Tori diegotoridoesandr...@gmail.comwrote: So you're saying in this case it's better to just populate the UI in onResume for data that is dependent on the outcome of that event? That would be the case for a couple of activities that depend on it. However, I'm more concerned about the performance impact, since this data in particular has dozens of members and if I have to re-create the UI every time onResume is called, it will create a bad UX within those Activities, even if I put up a loading screen and use a thread. I guess one way to reduce the number of unnecessary data refreshes is once my event occurs, I save a timestamp to my in-memory cache, and then every time an activity is added to the stack, it retrieves that value and keeps it there. As a result, every time the user generates the event, all the other activities below it will check the new timestamp in onResume and if the latest one is greater than the one the activity has, it refreshes itself and its current timestamp value. Also, my app guarantees that this event will occur when it first starts up, before it launches its home activity, so there will be a timestamp available. On Jun 8, 5:02 pm, Mark Murphy mmur...@commonsware.com wrote: On Wed, Jun 8, 2011 at 4:16 PM, Diego Tori diegotoridoesandr...@gmail.com wrote: That's the thing, if I set a shared preference flag or cached flag via cache object, and they did try to check for that value in onResume, wouldn't the first activity from the back stack to get the foreground check its state, then set it back to false after checking for it being true before having to do work? Delete the flag. You don't need the flag. Update the UI of the activity in onResume(). Period. Even if I didn't reset the flag, every time it would hit that function, it would still get caught in that flag, so that isn't really useful. Hence, get rid of the flag. Update the UI of the activity in onResume(). Period. So there is no way that I can just broadcast one intent that my listening activities can listen to after the intent is sent as soon as they get the foreground again? What makes you think that your activity even exists? Your non-foreground activities may not even be in memory, because Android may have destroyed them to save RAM. If you simply update your UI in onResume(), it handles both the activity-in-RAM and the activity-out-of-RAM scenario. Your proposed model is akin to: every time Google indexes a new page, it proactively updates every browser on the face of the planet, even those that do not use Google, do not care about the newly indexed page, or are not even running. Keep in mind that this is not a one-time event. All the more reason to not push updates out to activities that do not yet need the information. Rather it is an event that the user generates, all I want those other activities to know is whether or not the event was generated by the user while in the background. So, update the UI of the activity from your persistent store or in-memory cache in onResume(). Period. -- Mark Murphy (a Commons Guy)http://commonsware.com| http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android 3.0 Programming Books:http://commonsware.com/books -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com 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
[android-developers] Broadcasting custom intent actions to background activities from foreground activity.
So I want to achieve the following: suppose I have one Activity in my app that generates an event that I want other Activities in my app's back stack to know about so they can react to it accordingly (i.e. update UI, refresh data via separate Thread, etc...). What strategies would I have to pursue in order to accomplish this? Would I have to set up BroadcastReceivers and if so, how would I set up the receivers? Also, for this case, would it make sense to register and un-register the receiver(s) in onCreate and onDestroy respectively, since using onResume and onPause would prevent it from listening in when receiving Activity is in the background? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Broadcasting custom intent actions to background activities from foreground activity.
That's the thing, if I set a shared preference flag or cached flag via cache object, and they did try to check for that value in onResume, wouldn't the first activity from the back stack to get the foreground check its state, then set it back to false after checking for it being true before having to do work? Even if I didn't reset the flag, every time it would hit that function, it would still get caught in that flag, so that isn't really useful. So there is no way that I can just broadcast one intent that my listening activities can listen to after the intent is sent as soon as they get the foreground again? On Jun 8, 3:16 pm, Mark Murphy mmur...@commonsware.com wrote: On Wed, Jun 8, 2011 at 3:00 PM, Diego Tori diegotoridoesandr...@gmail.com wrote: So I want to achieve the following: suppose I have one Activity in my app that generates an event that I want other Activities in my app's back stack to know about so they can react to it accordingly (i.e. update UI, refresh data via separate Thread, etc...). What strategies would I have to pursue in order to accomplish this? Have them find out about the new information in onResume(). They do not need the information before then, since they are not in the foreground. Would I have to set up BroadcastReceivers and if so, how would I set up the receivers? No. Also, for this case, would it make sense to register and un-register the receiver(s) in onCreate and onDestroy respectively, since using onResume and onPause would prevent it from listening in when receiving Activity is in the background? No. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android 3.0 Programming Books:http://commonsware.com/books -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Broadcasting custom intent actions to background activities from foreground activity.
Keep in mind that this is not a one-time event. Rather it is an event that the user generates, all I want those other activities to know is whether or not the event was generated by the user while in the background. On Jun 8, 4:16 pm, Diego Tori diegotoridoesandr...@gmail.com wrote: That's the thing, if I set a shared preference flag or cached flag via cache object, and they did try to check for that value in onResume, wouldn't the first activity from the back stack to get the foreground check its state, then set it back to false after checking for it being true before having to do work? Even if I didn't reset the flag, every time it would hit that function, it would still get caught in that flag, so that isn't really useful. So there is no way that I can just broadcast one intent that my listening activities can listen to after the intent is sent as soon as they get the foreground again? On Jun 8, 3:16 pm, Mark Murphy mmur...@commonsware.com wrote: On Wed, Jun 8, 2011 at 3:00 PM, Diego Tori diegotoridoesandr...@gmail.com wrote: So I want to achieve the following: suppose I have one Activity in my app that generates an event that I want other Activities in my app's back stack to know about so they can react to it accordingly (i.e. update UI, refresh data via separate Thread, etc...). What strategies would I have to pursue in order to accomplish this? Have them find out about the new information in onResume(). They do not need the information before then, since they are not in the foreground. Would I have to set up BroadcastReceivers and if so, how would I set up the receivers? No. Also, for this case, would it make sense to register and un-register the receiver(s) in onCreate and onDestroy respectively, since using onResume and onPause would prevent it from listening in when receiving Activity is in the background? No. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android 3.0 Programming Books:http://commonsware.com/books -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: comparison between viewstub and latoutinflater to add view at runtime?
If I recall correctly, ViewStub acts as a lazy XML include, in that the referenced view only gets added to the view hierarchy in the time that it's inflated, not ahead of time. The gain on this method is that it makes it quick and cheap to inflate a view, however, once it's inflated, it cannot be recreated or re-inflated (since the VS reference is gone from the heirarchy). LayoutInflater on the other hand allows you to inflate views at will, and add them directly into the heirarchy, however, you have to deal with the overhead of inflating them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Effective way to manage binding/unbinding from local service across multiple activities
Apparently, it was leaking memory due to the fact that I wasn't properly unbinding from the service when exiting the activities. That and there were certain cases where I wasn't carrying over the Service bindings when rotating, thus it was creating a new connection every time. All is good now. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Effective way to manage binding/unbinding from local service across multiple activities
Targeting and building from API Level 4 and above.
Right now, I'm dealing with an issue in which I'm trying to maintain
bindings to my local service across multiple activities, and stop the
service when the last connection is unbound.
In a nutshell, my service just calls a system service in a HandlerThread
that returns quickly to a BroadcastReceiver, then does that same call again
after waiting a pre-determined amount of time (at least 15 seconds).
Suppose I have my base activity create the first bond to my service in
onCreate() in this fashion:
Intent service = new Intent(ActivityA.this, MyLocalService.class);
getApplicationContext().bindService(service, mConnection,
BIND_AUTO_CREATE);
Suppose also that due to the fact that I maintain my binding across screen
rotations by carrying over the binder and connection, I do not unbind from
the service until the activity is finished:
//onRetainNonConfigurationInstance carries over my binder and connection
since i bound from the app context, so they are fair game.
public void onDestroy(){
super.onDestroy();
//using binder, remove callback to service from current activity
if(isFinishing(){
getApplicationContext().unbindService(mConnection);
}
}
I pretty much do this setup for any other Activity that wants to listen in
on the service.
My problem is that eventually, some activities don't unbind instantly, hence
the service will still hang around as per the behavior of the bind/unbind
pattern if the service is auto created. I had to go as far as stopping my
thread before unbinding on the last activity, which prevented any system
services being called in the BG. Is there a better way to manage binding and
unbinding services, or am I doing my best with my current setup? Also, since
my service (via the binder) is weakly referenced, would this reduce my risk
of leaking memory?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Calling a system service in fixed intervals within another service
Sorry to bump the thread, but after creating a HandlerThread, all of the
locking stopped and the service stopped on a dime after unbinding even when
it waited for the allotted time before the next scan. Anyways, I was
wondering if I managed to implement it correctly:
class MyHandlerThread extends HandlerThread{
isRunning = false;
Handler _handler;
public MyHandlerThread(){
super(MyHandlerThread.class.getSimpleName(),
Process.THREAD_PRIORITY_BACKGROUND);
//register our custom BroadcastReceiver
//get Wi-Fi service
isRunning = true;
}
public void fireWhenReady(){
getHandler().sendEmptyMessage(DO_WIFI_SCAN);
}
public synchronized Handler getHandler() {
while (_handler == null) {
try {
wait();
} catch (InterruptedException e) {
//Ignore and try again.
}
}
return _handler;
}
@Override
public void run(){
Looper.prepare();
synchronized(this){
_handler = new Handler(){
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case DO_WIFI_SCAN:
//do our wifi scan call
break;
case SHUTDOWN:
removeMessages(DO_WIFI_SCAN);
getLooper().quit();
break;
}
}
};
notifyAll();
}
Looper.loop();
}
public void stopTheThread(){
isRunning = false;
//send SHUTDOWN message to handler
//unregister receiver and clean up
}
class MyBroadcastReceiver extends BroadcastReceiver{
@Override
public void onReceive(Context context, Intent intent) {
if(isRunning){
//go through the results
//send the next wifi scan call to the handler after
sleeping for a certain amount of time
}
}
}
}
Also I wonder how I would incorporate a timeout mechanism like I tried in
previous attempts after calling the scan using this model?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Calling a system service in fixed intervals within another service
So yeah, I managed to try calling the wifi scanner in this fashion within my
thread:
private Object _lock = new Object();
private final long SLEEP_TIME = 15000; //Scan every 15 secs
private final long WIFI_SCAN_TIMEOUT = 6; //One minute timeout
for getting called back, otherwise, initiate a new scan.
@Override
public void run() {
while(running){
//Start a new scan;
wifiSearchComplete = false;
_wifiMan.startScan();
while(!wifiSearchComplete){
synchronized(_lock){
try{
_lock.wait(WIFI_SCAN_TIMEOUT);
} catch (InterruptedException ie){
Log.d(TAG, TAG+.run() caught +
ie.getMessage() + when trying to sleep for + (WIFI_SCAN_TIMEOUT/1000)
+secs.);
Thread.currentThread().interrupt();
}
}
if(!wifiSearchComplete){
synchronized(_lock){
//Try scanning again since we didn't get called
back at all;
_lock.notify();
}
}
}
}
}
public boolean isRunning(){
return running;
}
public void stop(){
synchronized(_lock){
running = false;
//unregister receivers and cleanup
_lock.notify();
}
}
@Override
public void onReceive(Context context, Intent intent) {
synchronized(_lock){
wifiSearchComplete = true;
//iterate through our SSID's
try{
_lock.wait(SLEEP_TIME);
} catch (InterruptedException ie){
Log.d(TAG, TAG+.onReceive() caught +
ie.getMessage() + when trying to sleep for + (SLEEP_TIME/1000) +secs.);
Thread.currentThread().interrupt();
}
_lock.notify();
}
}
However, even though it waits every 15 seconds before it scans again, when
trying to exit my test activity (calling onDestroy) it blocks the main
thread for the sleep time, before it unbinds the service. In other words, is
this the appropriate way of trying to accomplish what I want to do w/o
blocking, or do I have to simply create a BroadcastReceiver and call
Thread.sleep at the end of onReceive before calling starting a new scan?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Calling a system service in fixed intervals within another service
I don't think it's doing any blocking operations at all since startScan
calls back onReceive rather quickly (even on a G1), and then I just use the
returned SSID data to call back to the activities bound to the service based
on the existence of a pre-determined SSID that I'm trying to find in that
list.
So in essence, you want me to do the following:
Create Handler object and then within my BroadcastReceiver's onReceive
method, do the following:
final int DO_WIFI_SCAN = 0;
private Handler _handler = new Handler(){
@Override
public void handleMessage(Message msg){
switch(msg.what){
case DO_WIFI_SCAN:
//call startScan here
break;
}
}
};
public void onReceive(){
//Iterate through the SSID's
_handler.sendEmptyMessageDelayed(DO_WIFI_SCAN, SLEEP_TIME);
}
Also, how would I model it if I try to use the HandlerThread approach? In
other words, where would I call startScan when starting thread, in run or in
the HandlerThread's constructor?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Calling a system service in fixed intervals within another service
As the question implies, I am wondering how I could write a thread
that would call a system service and then wait a certain amount of
time before calling said system service's function that calls back to
onReceive from a registered BroadcastReceiver.
In other words, I am trying to call the Wifi scanning service
(registering a BroadcastReceiver with IntentFilters) within my custom
local service so I can get the current SSID's available and send them
back to the activities that are bound to this service. I know what I
will end up doing with the received data, which is not relevant to
this question. However, I will need to wait a certain amount of time
before calling startScan again within onReceive, and that is where I
am trying to determine the best course of action.
Here is what I have so far:
class MyWifiScanner extends BroadcastReceiver implements Runnable{
private boolean running;
private final int SLEEP_TIME = 1;
private Object mSync = new Object();
WifiManager wifiMan;
Thread t;
public MyWifiScanner(){
//receiver registered with intent filters
wifiMan = (WifiManager)
SSIDListenerService.this.getSystemService(Context.WIFI_SERVICE);
t = new Thread(this);
t.start();
}
@Override
public void onReceive(Context context, Intent intent) {
//Received WiFi access point names, handle them
//Should I call wait on a sync object while syncronized
with it for
said amount of time and then call notify???
syncrhonized(mSync){
mSync.wait(SLEEP_TIME);
mSync.notify();
}
}
@Override
public void run() {
while(running){
syncrhonized(mSync){
wifiMan.startScan();
}
}
}
}
Or would it make sense to just create a BroadcastReceiver object that
just calls Thread.sleep in the end of onReceive?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Calling a system service in fixed intervals within another service
That's the thing, it has to be short intervals in between scans since
this has almost real-time implications, no greater than 15 secs at
most, so I dunno how AlarmManager would fit into the equation. Is
there any chance you can show me how to modify the above code to
utilize AlarmManager to have it sleep before the onReceive gets called
again?
On Apr 15, 6:27 pm, Kostya Vasilyev kmans...@gmail.com wrote:
Use AlarmManager for this, it's more reliable and easier to use than coding
a thread with sleep/wait.
16.04.2011 2:24 пользователь Diego Tori diegotoridoesandr...@gmail.com
написал:
As the question implies, I am wondering how I could write a thread
that would call a system service and then wait a certain amount of
time before calling said system service's function that calls back to
onReceive from a registered BroadcastReceiver.
In other words, I am trying to call the Wifi scanning service
(registering a BroadcastReceiver with IntentFilters) within my custom
local service so I can get the current SSID's available and send them
back to the activities that are bound to this service. I know what I
will end up doing with the received data, which is not relevant to
this question. However, I will need to wait a certain amount of time
before calling startScan again within onReceive, and that is where I
am trying to determine the best course of action.
Here is what I have so far:
class MyWifiScanner extends BroadcastReceiver implements Runnable{
private boolean running;
private final int SLEEP_TIME = 1;
private Object mSync = new Object();
WifiManager wifiMan;
Thread t;
public MyWifiScanner(){
//receiver registered with intent filters
wifiMan = (WifiManager)
SSIDListenerService.this.getSystemService(Context.WIFI_SERVICE);
t = new Thread(this);
t.start();
}
@Override
public void onReceive(Context context, Intent intent) {
//Received WiFi access point names, handle them
//Should I call wait on a sync object while syncronized with it for
said amount of time and then call notify???
syncrhonized(mSync){
mSync.wait(SLEEP_TIME);
mSync.notify();
}
}
@Override
public void run() {
while(running){
syncrhonized(mSync){
wifiMan.startScan();
}
}
}
}
Or would it make sense to just create a BroadcastReceiver object that
just calls Thread.sleep in the end of onReceive?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Calling a system service in fixed intervals within another service
You pretty much hit the nail on the head. I just need to figure out the best way to add the time buffer in between the startScan calls without creating too much overhead and accomplishing the task at hand. On Apr 15, 6:59 pm, Mark Murphy mmur...@commonsware.com wrote: On Fri, Apr 15, 2011 at 6:43 PM, Diego Tori diegotoridoesandr...@gmail.com wrote: That's the thing, it has to be short intervals in between scans since this has almost real-time implications, no greater than 15 secs at most, so I dunno how AlarmManager would fit into the equation. Is there any chance you can show me how to modify the above code to utilize AlarmManager to have it sleep before the onReceive gets called again? My interpretation of what you're trying to accomplish is that you have 1+ activities that need to hear about scan results, for a startScan() kicked off every so often. Let's assume a service being bound to by the activities is the right answer. I'm more than a tad skeptical on that, actually, but I'm trying to keep this simple relative to your apparent current implementation. Step #1: In onCreate() of the service, you register a BroadcastReceiver for SCAN_RESULTS_AVAILABLE_ACTION, then call startScan(). onCreate() then returns. Or, if this should not be going for the entire time the service is in memory, expose a method from your Binder that does the aforementioned work and returns. Step #2: When SCAN_RESULTS_AVAILABLE_ACTION occurs and your BroadcastReceiver is called with onReceive(), you: Step #2a: Arrange for your next scan (e.g., use Timer/TimerTask to call startScan() after some delay -- I agree that AlarmManager is not ideal for this particular implementation) Step #2b: Call getScanResults() and asynchronously notify the activities (your own broadcast Intent that the activities register for, or via a callback method the activities register with the service, or via a Messenger, or via a PendingIntent created by createPendingResult(), etc.). Step #3: In onDestroy(), you unregister your BroadcastReceiver and arrange to not invoke the next scan (e.g., cancel the Timer). -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy Android 3.0 Programming Books:http://commonsware.com/books -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Call back to an Activity in the bottom of the stack from a global Activity.
I already know that I can pass Bundled data through setResult from one Activity back to another. However, suppose I have an global Activity that can be launched from anywhere in my app since it is mapped to a button that appears in my title bar in almost all of my activities. Long story short, after it completes its user-driven process, I want it to signal back to the very first activity in the back stack, basically my Home activity, so that it updates the UI accordingly. Part of the problem is that since if I use a BroadcastReceiver, it is unregistered when my activity is in the background, and it will not get the signal to refresh its data set. What I want to achieve is the following: From either Home (ActivityA), or any other activity (Activity B, C, etc...) that can open out my global activity (ActivityX), it should find a way to call back to ActivityA without bringing it to the front. Should I use FLAG_ACTIVITY_FORWARD_RESULT and if so, how should I model it from my subsequent activities after Home. In other words, if I launch a child activity from Home, should I launch it with startActivityForResult with whatever request code I define and then pass FLAG_ACTIVITY_FORWARD_RESULT when opening my global activity so that the result will be set from there? Also, suppose I launch a child activity from Home with a result, and then from my child activity I add more to the stack, from which I open ActivityX. Would the system still remember the result chain as long as I opened the first child from Home with a result? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Call back to an Activity in the bottom of the stack from a global Activity.
That actually sounds like a winner right here, since it bypasses the whole starting of activities with a result. I mean, it's just checking for a flag that gets set by this one activity, and the overhead is pretty small anyways to pull it off. I'll see if I can try it first thing tomorrow morning. On Mar 22, 10:22 pm, TreKing treking...@gmail.com wrote: On Tue, Mar 22, 2011 at 7:17 PM, Diego Tori diegotoridoesandr...@gmail.comwrote: From either Home (ActivityA), or any other activity (Activity B, C, etc...) that can open out my global activity (ActivityX), it should find a way to call back to ActivityA without bringing it to the front. When Activity X does something, set flag in a sharedpreference. When Home Activity is brought back to focus (onStart()) check the flag and do what's needed. Also, suppose I launch a child activity from Home with a result, and then from my child activity I add more to the stack, from which I open ActivityX. Would the system still remember the result chain as long as I opened the first child from Home with a result? It should. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
