it so that the TimerView binds to the TimerService and communicates to
it directly through its ServiceConnection (just like in the sample
code). There is so much to the API I didnt know about that sample or
about the CountDownTimer! Thanks again.
On Oct 22, 6:44 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> ClarkBattle wrote:
> > TimerActivity.onCreate() inflates the TimerView (allowing the user to
> > set the time and hit the start button) and starts the TimerService.
>
> Creating a custom View is certainly possible but probably way overkill
> for this sort of app.
>
> > When the start button is pressed the TimerView broadcasts a START
> > intent containing the number of seconds. The TimerService contains a
> > BroadcastReceiver listening for the START intent.
>
> Why not just call a method on the service object? You can get the
> service object either by creating your own public static singleton or by
> using the local binding pattern shown in the ApiDemos of your SDK.
>
> > When the
> > TimerService receives START it begins broadcasting a TICK intent
> > (containing the number of seconds remaining) every second until zero
> > is reached.
>
> Why not just register a listener object with the service, that the
> service calls periodically?
>
> Broadcast Intents are broadcast to the device, not the app, and so are
> much more expensive in terms of CPU time than merely calling a method.
> They are also public, in the sense that any app can receive those
> broadcasts.
>
>
>
> > public class TimerService extends Service
> > {
> > private int _seconds = 0;
> > private Handler _timerHandler;
>
> > @Override
> > public void onCreate()
> > {
> > _timerHandler = new Handler( );
> > }
>
> > ...
>
> > public class StartListener extends BroadcastReceiver
> > {
> > @Override
> > public void onReceive(Context context, Intent intent)
> > {
> > _seconds = intent.getIntExtra( "seconds", 0 );
> > _timerHandler.postAtTime( runTimer, SystemClock.uptimeMillis() +
> > 1000 );
> > }
>
> I have never used a Handler in a Service, so I don't know how that
> fares. As an alternative, you might use android.os.CountDownTimer, which
> seems tailor-made for your scenario.
>
> > <receiver android:name="TimerService$StartListener">
> > <intent-filter>
> > <action android:name="com.poof.timer.action.START"/>
> > </intent-filter>
> > </receiver>
>
> For temporary broadcast receivers, use registerReceiver() in Java code,
> not a manifest-registered receiver like you have here.
>
> > Look good so far? Well, it isnt. The problem is that it wont build
> > because, according to Eclipse, "com.icd.timer.TimerService
> > $StartListener is enclosed, but not static". Its the same with
> > TickListener. I could simply make the StartReceiver and TickReceiver
> > classes static but that wont work because both of them need to set the
> > state of their containing objects.
>
> > How do I get around this?
>
> Try getting rid of the public keyword and make them simply
> package-private or private inner classes, after switching to using
> registerReceiver(). If you switch to the listener pattern, the receivers
> all become moot, anyway.
>
> > (Its my first android app).
>
> Welcome to Android!
>
> --
> Mark Murphy (a Commons Guy)http://commonsware.com|http://twitter.com/commonsguy
>
> Android Training in Germany, 18-22 January 2010:http://bignerdranch.com
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
No comments:
Post a Comment