Got this all working and reliably.

I still use a state variable to tell me where I am in the state
machine - not ideal.

My reliability problems seem to have been down to using
SharedPreferences to hold state between tests.

Thanks for the responses.

Ian Hunter

On Nov 29, 8:10 pm, Ian <ian.fawcett.hun...@gmail.com> wrote:
> Thanks for your response - I think this could be enlightening
>
> However, a few questions...
>
> On Nov 29, 7:30 pm, "A. Elk" <lancaster.dambust...@gmail.com> wrote:
>
> > Can I get clarification here? Does your application call finish() at
> > some point? If so, at what point?
>
> > The Android design guidelines strongly discourage the use of an "exit"
> > button. You should see that most apps don't have one. The way to
> > "exit" an application is to switch to another one (including a phone
> > call) or go to the Launcher/Home. Whenever you switch, the onPause()
> > method for the foreground Activity of your app should be called.
> > Whenever you switch back, the onResume() method should be called.
>
> Can you please point me at the guidelines you are referring to?
>
> I have seen many references to the finish() method, but nothing
> discouraging its use. In the API it states...
>
> "void finish() - Call this when your activity is done and should be
> closed."
>
> In my scenario, the user rejects the Terms & Conditions in a dialog -
> and this seems the ideal thing to do, No?
>
>
>
> > I acknowledge that sometimes you may want to start a child *Activity*
> > and then kill it when you're done with it. To do this, use
> > finishActivity() with a result code. You may also want to start a
> > service when your app starts, but give the user the option to stop the
> > service if it's not being used. That's OK too, but you shouldn't shut
> > down the app itself.
>
> > In short, the Android model is that you leave the application paused,
> > and let Android destroy it to free up resources. If Android does this,
> > it should always call the onPause() method of any Activities that are
> > still running.
>
> > Can you describe your test harness in more detail? To unit test an
> > Activity, you shouldn't need anything more than
> > InstrumentationTestRunner and ActivityInstrumentationTestCase2. This
> > is documented under "Testing and Instrumentation" in the Android 2.2
> > Developer's Guide.
>
> I am using the ActivityInstrumentationTestCase2 as you suggest and
> calling getActivity() to start the Activity. I then do
> button.performClick() which causes 'finish()'. I am hoping to reliably
> test that the Activity has paused, stopped or whatever happens.
>
> I have refactored and now have a unit test which (via a state
> variable) does work, but not reliably - this may be another story :-)
>
> Thanks
> Ian Hunter

-- 
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

Reply via email to