android in practice_Using the AlarmManager(portfolio project)
来源:互联网 发布:旁氏米粹怎么样知乎 编辑:程序博客网 时间:2024/06/07 16:31
system-level alarms.
you can’t guarantee that it’ll still be running at that point in the future.
To ensure that our code is executed at the desired time, we can’t rely on the Service because the OS could kill the Service to free up memory. We must use the OS to schedule the execution, and to do this we must use the android.app.AlarmManager class.
we’ve already created a BroadcastReceiver that’s invoked when the device finishes booting up.here you see a new version that instead schedules the Service to be executed.
Using a device boot receiver to schedule Service execution.
modify the device boot BroadcastReceiver class PortfolioStartupReceiver:
we use the AlarmManager C to schedule the PendingIntent for execution. By specifying the type of alarm as RTC_WAKEUP, we’re instructing the OS to execute this alarm even if the device has been put to sleep.
Note that our Intent wasn’t for the Service directly,but instead fora class called AlarmReceiver.
now we want that Service to update the stock data and check whether it needs to send Notifications to the user.
This method will be invoked each time a client context calls startService, such as in listing 5.18, even if the Service is already running. All we want to do is call our update-
StockData method, since it’ll take care of retrieving fresh data from the network,updating the locally cached data in our database, checking whether we need to send out Notifications, and send them out if so.
Note that this method must return an integer. The value of that integer tells the OS what to do with the Service if it’s killed by the OS. The START_NOT_STICKY flag indicates that the OS can forget about this Service if it has to kill it.
SERVICE ONSTART VERSUS ONSTARTCOMMAND,You should always use onStartCommand, unless you need to write code specifically for devices running pre-2.0.
you can’t guarantee that it’ll still be running at that point in the future.
To ensure that our code is executed at the desired time, we can’t rely on the Service because the OS could kill the Service to free up memory. We must use the OS to schedule the execution, and to do this we must use the android.app.AlarmManager class.
we’ve already created a BroadcastReceiver that’s invoked when the device finishes booting up.here you see a new version that instead schedules the Service to be executed.
Using a device boot receiver to schedule Service execution.
modify the device boot BroadcastReceiver class PortfolioStartupReceiver:
/** * <code>BroadcastReceiver</code> that is notified when the device boots up. * It uses the {AlarmManager} to schedule regular invocations of the {@PortfolioManagerService}. * * This can be easily modified to use Cloud to Device Messaging, see comments in the code for details. * */public class PortfolioStartupReceiver extends BroadcastReceiver {private static final int FIFTEEN_MINUTES = 15*60*1000;// Uncomment this constant to use C2DM and insert the email address that// you use to submit your apps to the Android Market//private static final String DEVELOPER_EMAIL_ADDRESS = "";@Overridepublic void onReceive(Context context, Intent intent) {// TODO Auto-generated method stub/*It creates a new Intent and uses that Intent to start the Service. * This will cause the onCreate and then the onStartCommand methods to be invoked on our Service(PortfolioManagerService), * and then return back to the BroadcastReceiver. *///start the background service once the device boots up.//Intent stockService=new Intent(context,PortfolioManagerService.class);//context.startService(stockService);// Begin AlarmManager code. Delete this to use C2DMAlarmManager mgr=(AlarmManager)context.getSystemService(Context.ALARM_SERVICE);Intent i=new Intent(context,AlarmReceiver.class);PendingIntent sender=PendingIntent.getBroadcast(context, 0, i, PendingIntent.FLAG_CANCEL_CURRENT);Calendar now=Calendar.getInstance();now.add(Calendar.MINUTE,2);mgr.setRepeating(AlarmManager.RTC_WAKEUP, now.getTimeInMillis(), FIFTEEN_MINUTES, sender);// End AlarmManager code// Uncomment out the following code to use C2DM//Intent registrationIntent = new Intent("com.google.android.c2dm.intent.REGISTER");//registrationIntent.putExtra("app", PendingIntent.getBroadcast(context, 0, new Intent(), 0)); // boilerplate//registrationIntent.putExtra("sender", DEVELOPER_EMAIL_ADDRESS);//context.startService(registrationIntent);}}we’ve changed the implementation of the onReceive method. Now instead of starting the Service, we’ll schedule it. We create an Intent B for the BroadcastReceiver that will receive the alarm from the AlarmManager.
we use the AlarmManager C to schedule the PendingIntent for execution. By specifying the type of alarm as RTC_WAKEUP, we’re instructing the OS to execute this alarm even if the device has been put to sleep.
Note that our Intent wasn’t for the Service directly,but instead fora class called AlarmReceiver.
public class AlarmReceiver extends BroadcastReceiver {@Overridepublic void onReceive(Context context, Intent intent) {Intent stockService =new Intent(context, PortfolioManagerService.class);context.startService(stockService);}}All it does is create an Intent for the PortfolioManagerService and then immediately start that Service.
now we want that Service to update the stock data and check whether it needs to send Notifications to the user.
Modified Service to work with system alarms:
public class PortfolioManagerService extends Service {// other code omitted@Overridepublic int onStartCommand(Intent intent, int flags, int startId) {updateStockData();return Service.START_NOT_STICKY;}}To get our Service to work properly with the system alarms, we need to override another of android.app.Service’s lifecycle methods: the onStartCommand method.
This method will be invoked each time a client context calls startService, such as in listing 5.18, even if the Service is already running. All we want to do is call our update-
StockData method, since it’ll take care of retrieving fresh data from the network,updating the locally cached data in our database, checking whether we need to send out Notifications, and send them out if so.
Note that this method must return an integer. The value of that integer tells the OS what to do with the Service if it’s killed by the OS. The START_NOT_STICKY flag indicates that the OS can forget about this Service if it has to kill it.
SERVICE ONSTART VERSUS ONSTARTCOMMAND,You should always use onStartCommand, unless you need to write code specifically for devices running pre-2.0.
- android in practice_Using the AlarmManager(portfolio project)
- android in practice_Using a Service for caching data(portfolio project)
- android in practice_Using Cloud to Device Messaging(portfolio project)
- android in practice_Using internal storage(FileExplorer project)
- android in practice_Using external storage(FileExplorer project)
- android in practice_Using Intents(GoodShares project)
- android in practice_Creating notifications(portfolio project)
- android in practice_Keeping Services awake(portfolio project)
- android in practice_create and start a service(portfolio project)
- android in practice_Communicating with a Service (portfolio project)
- android in practice_Using standard ContentProviders(AutoForm)
- IT Project Portfolio Management
- Android Studio-“Android framework is detected in the project”
- 浅谈PPM (Project Portfolio Management)
- 浅谈PPM (Project Portfolio Management)
- Frameworks detected: Android framework is detected in the project
- Using AlarmManager and BroadcastReceiver in Android
- Portfolio of Mouwu Lin for application to the Emerging Media Program in CMU
- 网站在本地执行正常发布到服务器有部分页面出错
- 系统执行阻塞分析及解决方案
- Erlang中的nif
- 用GDI学习C语言,控制台也能画图
- 获取项目根目录
- android in practice_Using the AlarmManager(portfolio project)
- Android 解析assets目录下的json文件
- 刷新视图
- 背包问题
- C++学习之C++动态分配内存
- 从数据库表反射出实体类,自动生成实体类
- HandlerThread, Handler, Looper
- 在外键上创建索引V1.0
- R语言学习由浅入深路线图