delay espresso cannot handle - unit-testing

For testing software with Google Espresso test-framework I have following issue:
At start of the program, a splash screen starts and initialises the entire application. After this, I start an Activity which asks for input.
In Espresso, the application starts and the test starts with following code:
onView(withId(R.id.chooseBookTitle)).perform(click());
This crashes, because the display still shows the splash screen and the chooseBookTitle is only visible afterwards. How to prevent that Google-Espresso will click the key before it is there?
(I don't want to insert wait loops, but keep it event driven. In worse case, I go back to Robotium)

Please check the IdlingResource interface:
As mentioned by Stefano Dacchille (see sample below) you must create an idling ressource implementation that waits to become idle:
public class WaitForSomethingResource implements IdlingResource {
ResourceCallback mResourceCallback;
private boolean isIdle;
#Override
public String getName() {
return WaitForSomethingResource.class.getName();
}
#Override
public void registerIdleTransitionCallback(
ResourceCallback resourceCallback) {
mResourceCallback = resourceCallback;
}
#Override
public boolean isIdleNow() {
return isIdle;
}
/**
* Register an listener, use an event bus or something
* else to get notified about any change you want to track.
*/
public void onProgressChanged() {
isIdle = true;
if (isIdle && mResourceCallback != null) {
mResourceCallback.onTransitionToIdle();
}
}
}
After that, you have to register the IdlingResource implementation within the tests setUp() or #before method by writing:
Espresso.registerIdlingResource(waitForSomethingResource)
Sample:
http://dev.jimdo.com/2014/05/09/wait-for-it-a-deep-dive-into-espresso-s-idling-resources/
API Doc:
http://developer.android.com/reference/android/support/test/espresso/IdlingResource.html#isIdleNow()

From what I see, you should open directly the activity that contains R.id.chooseBookTitle, otherwise your view will never be on the screen so your test will always fail because Espresso can't find the specified view.
Otherwise, I use Thread.sleep(...) before I do some tests to make the tests wait. Try it before calling onView(withId(R.id.chooseBookTitle)).perform(click()); and see if it's working.
Good luck!

Related

Vaadin 8: Dynamically turn on and off #Push to use #Push with cookies

In my application (Vaadin.8.6.3, Tomcat 9 and Maven 3) I need to set cookies which works well unless I use #Push. I need #Push only for one progress window implemented as described here.
I read that it is possible to turn #Push on and off using e.g.
getUI().getPushConfiguration().setPushMode(PushMode.AUTOMATIC);
I tried several ways and places in the code to turn #Push on and off, but nothing worked.
One example:
#Push(PushMode.DISABLED)
public class MyUI extends UI {
Since I have more than one place in the code where I do cookies handling, I thought the best is to disable #Push in the UI class and turn it on when I run the background thread.
With a button click I start the runnable and in the runnable I turn on the #Push mode:
class Loader implements Runnable {
#Override
public void run() {
try {
getUI().access(() -> {
getUI().getPushConfiguration().setPushMode(PushMode.AUTOMATIC);
getUI().getNavigator().navigateTo("scandataview/" + name);
});
} catch (Exception e) {
e.printStackTrace();
}
}
}
I have no error but nothing happens, i.e. the data I want to load are never loaded and the progress window stays forever.
My questions:
Is it possible to just turn on #Push to show the progress window while loading long data and turn it off after loading?
If yes, where in the code should I turn on/off the #Push?
If you need more information please let me know. I would be very glad for your help. Thank you!
If you need Push only in one place and for some reason have described complications I recommend the following.
Set the push mode to manual i.e. #Push(PushMode.MANUAL)
And then modify the code as follows, i.e. perform manual push instead of relying automatic.
class Loader implements Runnable {
#Override
public void run() {
try {
getUI().access(() -> {
getUI().getNavigator().navigateTo("scandataview/" + name);
getUI().push();
});
} catch (Exception e) {
e.printStackTrace();
}
}
}
The above use of access() can be further improved according information provided in this question: Access method from current UI in Vaadin

Detect wink on Google Glass without taking picture

Is there a way to stop Glass from taking picture while listening to wink command?
Whenever I detect Wink from my code, it automatically takes a picture which I don't want.
Edit:
The library is a stub. Whenever the onDetected function is called, I get a log message then Glass takes picture. Is there a way to stop the Internal glass function from running? I tried adding return at the end of onDetected but that didn't work.... Maybe a function to abort to exit the function?
The code is below.
#Override
public void onDetected(final EyeGesture eyeGesture) {
runOnUiThread(new Runnable() {
#Override
public void run() {
mAudioManager.playSoundEffect(Sounds.SUCCESS);
Log.e(TAG, eyeGesture + " is detected");
if(eyeGesture==target1.WINK){
mTextView.setText("Detected " + eyeGesture + "!");
}
}
});
}
In the old days (XE16 and before), winks sent out a broadcast. If you simply created a high priority broadcast receiver, you could abort the broadcast (and the wink-picture-receiver would never see the broadcast).
I put togethher some old code to demonstrate this here: https://gist.github.com/victorkp/0f98cd5c096de53f4518
Try this code:
https://github.com/prt2121/EyeGestureLib
Revision for XE19.

How to force a LiveCard to be visible until dismissed

I'm building a heads up display for OBD data (speed, RPM, throttle position etc.) using Glass.
I am using a LiveCard to display the HUD, but like all cards it fades away after a few seconds as Glass puts the display to sleep.
Is there a way to force the card to remain visible until it's dismissed? A HUD display isn't very useful if it keeps needing to be woken up.
The code thus far is here: https://github.com/mpicco/glass-obd-hud.
Thanks,
Marty
I'd would recommend using an Immersion + the FLAG_KEEP_SCREEN_ON flag or getting a partial wakelock within your Service.
From the Android documentation:
PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
PowerManager.WakeLock wl = pm.newWakeLock(PowerManager.SCREEN_DIM_WAKE_LOCK, "My Tag");
wl.acquire();
// ..screen will stay on during this section..
wl.release();
If you do use the wakelock solution, do not forget to release it once your Service is stopped.
The way I've done this is inside the activity that I wish to keep the screen on for, I've added a window parameter like so:
public class MyActivity extends Activity {
...
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);
}
}
The power manager service would likely work just as well, but this way when the user destroys my activity or other such things, I don't have to worry about maintaining state.

Command design pattern and user interaction

I am implementing command design pattern but my command needs to ask user for file name. I am not sure how can command ask for it?
The gang of four book seems to touch this issue but I am not quite clear. Below is my code (pseudo code to be correct and written on fly).
class OpenDocumentCommand : public Command
{
virtual char * AskUserForFileName();
virtual void Execute();
Application _App;
}
void OpenDocumentCommand::Execute()
{
char * fileName = AskUserForFileName();
_App.OpenDocument( fileName );
}
Now in typical simple example, AskUserForFileName() can be cin and cout but how can it ask for file name in a proper Windows application? It should open File Explorer and user can select file name?
Does it means it has to be tighly coupled with windows? My plan is to use this code both on Windows and iOS so I would like a decoupled solution.
To minimize coupling between your command and the window you should at least insert an abstraction layer between them. In many MVVM implementations you can find a "Modal Dialog"-interface that hides the implementation details of the window from the calling ViewModel.
This interface contains at least a single method "ShowDialog()", but it can also take a ViewModel as a parameter and returns a callback to inform the caller when it gets closed by the user.
Here is an example:
public interface IModalWindow
2 {
3 bool? DialogResult { get; set; }
4 event EventHandler Closed;
5 void Show();
6 object DataContext { get; set; }
7 void Close();
8 }

Blackberry App start Webservice Null

I have a version hit check right after my application gets start.
But when simulator is loading its sending the request and all that stuff. After my application starts it give version hit value NULL but after I close the application and open it again it gives the correct value.
1) My Question is that Why is this behavior occurring and what should I do that app starts and version check gives correct value at first attempt!
2) And the app is even not executed by user why its line of codes are executed?????
public MyScreen() {
Bitmap bitmap = Bitmap.getBitmapResource("background.png");
this.getMainManager().setBackground(
BackgroundFactory.createBitmapBackground(bitmap));
synchronized (Application.getEventLock())
{
UiApplication.getUiApplication().invokeLater(new Runnable()
{
public void run()
{
Status.show("Please Wait...", Bitmap.getPredefinedBitmap(Bitmap.INFORMATION), 1000);
LoginScreen();
}
});
}
Now what does it do is that it shows only the background screen and nothing happens no service but when I start it again it works. Whats the problem? Thanks
If your MyScreen class is actually a kind of Screen (through inheritance), then there's no need for you to synchronize on the event lock in this case. The constructor for a Screen will already be called on the UI thread, so, just simplify your code to:
public MyScreen() {
Bitmap bitmap = Bitmap.getBitmapResource("background.png");
this.getMainManager().setBackground(
BackgroundFactory.createBitmapBackground(bitmap));
UiApplication.getUiApplication().invokeLater(new Runnable()
{
public void run()
{
Status.show("Please Wait...", Bitmap.getPredefinedBitmap(Bitmap.INFORMATION), 1000);
LoginScreen();
}
});
Also, you might be able to get rid of the invokeLater() call, too, leaving you with this:
public MyScreen() {
Bitmap bitmap = Bitmap.getBitmapResource("background.png");
this.getMainManager().setBackground(
BackgroundFactory.createBitmapBackground(bitmap));
Status.show("Please Wait...", Bitmap.getPredefinedBitmap(Bitmap.INFORMATION), 1000);
LoginScreen();
You would normally use invokeLater() if you just wanted to safely initiate the code inside its run() method from a background thread, or if you wanted to queue it to be run after the constructor finishes.
But, if you're ready for it to happen right away, and you were just using that call to ensure that
Status.show("Please Wait...", Bitmap.getPredefinedBitmap(Bitmap.INFORMATION), 1000);
LoginScreen();
was run on the UI thread, then there's no need for that, because as I said, you're already on the UI thread in the MyScreen constructor.
But, I also can't see what you do at the end of your MyScreen constructor, so it's possible that using invokeLater() is appropriate.
Post some more information in response to my comment above, and I'll try to help with more.