Blackberry App start Webservice Null - web-services

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.

Related

Multithreading Synchronisation

I'm trying to write a multithreaded graphics manipulation program using Borland's C++ Builder 6 on WinXP SP3, but have run into (I think) a synchronisation issue, and can't figure out why.
Main Form (Form1) has a TPicture loaded from file. A copy of this is acquired by the thread via a Synchronize() call, and works fine. The thread does some work on the image, and in theory, it periodically updates the main Form image. The main Form also controls a machine, and is a 'First Resort' emergency stop, so blocking isn't an option. Everything is fine until the main Form gets hold of the working copy, or a copy of the working copy (sorry, but it's got to that) at which point the program hangs, and is only responsive to a 'program reset' from the IDE. A poor solution is to copy the working image to the Clipboard, and then, from the main Form, copy from the Clipboard to the main Form's image.
//Synchronization routines:
//----------------------------------------------------------------
`void __fastcall ImageRout::update()
{
Form1->Image9->Picture->Bitmap->Assign(Imgcopy);
//never returns
}
//----------------------------------------------------------------
void __fastcall ImageRout::getimage()
{
Imgcopy->Assign(Form1->Image9->Picture);
}
//----------------------------------------------------------------
//do the initialisation things... Then,
//(data is a struct, loaded with image data via a Synchronize() call)
Imgcopy=new Graphics::TBitmap;
Imgcopy->Width=data.width;
Imgcopy->Height=data.height; //size the bitmap
while(Imgcopy->Canvas->LockCount!=1)
{
Imgcopy->Canvas->TryLock();
} //have to Lock() the image or it gets lost... Somewhere
Synchronize(getimage); //works fine
//do some work on Imgcopy
//"By the book"- attempt 1
//(rate (=15) is a 'brake' to stop every alteration being displayed)
update_count++;
if(update_count>rate) //after a few iterations, update
{ //user interface
Synchronize(update); //fails: never returns from Synchronize call
update_count=0;
}
After a lot of failed attempts, I came up with this.
//in the thread...
update_count++;
if(update_count>rate)
{
EnterCriticalSection(&Form1->mylock1);
Form1->tempimage->Assign(Imgcopy); //tempimage is another bitmap,
InterlockedExchange(&Form1->imageready,1);//declared in the main Form
LeaveCriticalSection(&Form1->mylock1); //and is only ever accessed
update_count=0; //inside a critical section
}
//...and in the main Form....
if(imageready==1)
{
EnterCriticalSection(&mylock1);
Image9->Picture->Bitmap->Assign(tempimage); //Fails here
InterlockedExchange(&gotimage,1);
InterlockedExchange(&imageready,0);
LeaveCriticalSection(&mylock1);
}
So, in desperation.
//in the thread...
update_count++;
if(update_count>rate)
{
Synchronize(update);
EnterCriticalSection(&Form1->mylock1);
Form1->tempimage->Assign(Imgcopy);
Clipboard()->Assign(Imgcopy);
InterlockedExchange(&Form1->imageready,1);
LeaveCriticalSection(&Form1->mylock1); */
update_count=0;
}
//and in the main Form...
if(imageready==1)
{
EnterCriticalSection(&mylock1);
if (Clipboard()->HasFormat(CF_BITMAP))
{
Image9->Picture->Bitmap->Assign(Clipboard());
}
InterlockedExchange(&gotimage,1);
InterlockedExchange(&imageready,0);
LeaveCriticalSection(&mylock1);
}
This last attempt works, albeit relatively slowly, because of the Clipboard overhead, and it's a poor crutch, at best. I suspect the Clipboard is enforcing an otherwise failed synchronisation effort, but, as I said earlier, I can't fathom why. What can be the issue?
Thanks for your comments, Remy. They shook me out of a "tizzy" I'd got myself into whilst trying to solve the problem. I'd forgotten that Windows needs to move memory blocks around, and can't do this if locked them.
The initial problem of the Synchronize(update) call (code block 1 above) was caused by my still having the working copy (Imgcopy) locked (from inside the thread) during the call, preventing the main Form from subsequently accessing it. I suspect (but haven't investigated- that code has gone) the same root cause was at work in code block 2.
Locking every bitmap just prior to access, and unlocking immediately afterwards has solved this problem.
Peter O, thanks for your edit- I didn't realise there was so much overhead in my initial post.

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.

delay espresso cannot handle

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!

WT widget not updating in boost thread

I have run into an interesting problem with WT, I have solved it, but I do not understand WHY my solution solved the problem. I've dug through WT documentation for the widgets and have come up empty handed so far, so maybe someone who knows more about WT can help me out here.
Anyway, the problem is with a WComboBox widget in a boost thread not updating it's data when clicked on and having it's selection changed.
I created a boost thread in a class
class MyConsole: public WApplication
{
private:
boost::shared_ptr<boost::thread> _thread;
WComboBox* _combo_box;
bool running;
//Thread function
void my_thread(Wt::WApplication *app);
}
Then I fill the combo box with data, lets use "foo" and "goya" as the 2 entries. I made a function for the thread, and put a loop into it.
void MyConsole::my_thread(Wt::WApplication *app)
{
while(running)
{
std::string test;
Wt::WApplication::UpdateLock lock(app);
if(lock)
{
test = _combo_box->valueText().narrow();
}
if (strcmp("foo", test.c_str()) == 0)
{
cout << "we got foo" << endl;
}
else if (strcmp("goya", test.c_str()) == 0)
{
cout << "we got goya" << endl;
}
}
}
Without changing the initial selection of the combo box, the above code always enters the foo if statement, which is expected. However, when I change the selection of the _combo_box to "goya" the above code still enters the "foo" if statement, which is very unexpected. Investigating the matter further such as printing out the current index of the combo box before the if statement showed me that it is always 0 and never gets incremented when the selection changes.
The way I fixed it was by connecting the combo box changed() signal to a do nothing function that I added to the class.
class MyConsole: public WApplication
{
private:
...
void WWidgetForceUpdate(void)
{
}
...
}
...
_combo_box->changed().connect(this, &MyConsole::WWidgetForceUpdate);
With the addition of that function call when the selection changes, the "foo" and "goya" if statements worked properly, and printing out the current index of the combo box before the if statement confirmed that the index was now changing.
Why did connecting the changed() signal to a do nothing function remedy the situation? I am sure there is a bigger problem that I am not seeing here :(
Any help would be much appreciated.
Wt sends changes from the browser to the server when events happen. If your program is not interested in an event, this synchronisation will not take place (otherwise synchronisation would take place on every character of text you enter in an input box, on every mose movement, .... even if your application is not doing anything with it). Nothing connected to changed() means that nothing is interested in that specific event, and the browser will not notify the server when it happens.
Any event that is being listened upon will send all changes of all widgets to the server, so that the full widget tree is synchronised. So if you have a button with clicked() listener, and a combobox without a changed() listener, the state of the combobox will still be updated in the widget tree when you click the button.
There is however a bug in your code: you cannot just access the widget tree from a random thread without grabbing the update lock (WApplication::UpdateLock).

wxProgressDialog somehow keeping app alive after death?

I'm having a strange problem with wxWidgets. I have the following code
MyFrame::OnDoSomeLongThing(...) {
progScreen = new wxProgressDialog(text,text,number,this,wxPD_AUTO_HIDE); // wxProgressDialog *progScreen is class member
doPartOfThing() // calls the update method at the end of it
....
doLastPartOfThing() // again calls update method that pushes value to 100/100
progScreen->Destroy();
}
MyFrame::update() {
progScreen->Update(newValue);
}
Now here's the thing. I can literally comment out the lines relating to progScreen, just let the process go without using a progress dialog, after all is said and done, my apps exits gracefully when I close the main window.
However, just the use of the progress dialog is somehow extending the life of the application. I've tried Destroy(), I've tried simply 'delete progScreen', and both, every time: I'll close the main frame, the process keeps running, and at some point exits with some astronomical number. The only thing I could think might be relevant, is that the doPartsOfThings methods may call boost::this_thread::sleep, because it involves waiting and whatnot down in my model class. But this shouldn't have anything to do with my problem. Or maybe it does... EDIT: I do want to emphasize that progScreen->Update() IS being called from the main (GUI) thread.
So I ask, am I using a wxProgressDialog correctly? If not, how should it be used?
Thanks for your help!
EDIT:
Well... it turns out that removing wxPD_AUTO_HIDE fixed the problem. I'm still not quite sure what the problem is, but the dialog even still behaves as before. App closes as expected.
I think that you need to override the wxApp method that closes the application so that it closes the wxProgressDialog object before it quits.
wxApp::OnExit
virtual int OnExit()
Override this member function for any processing which needs to be
done as the application is about to exit. OnExit is called after
destroying all application windows and controls, but before wxWidgets
cleanup. Note that it is not called at all if OnInit failed.
The return value of this function is currently ignored, return the
same value as returned by the base class method if you override it.
You will need something like, assuming progScreen is a public attribute of your frame
int myApp::OnExit()
{
(MyFrame*)(GetTopWindow())->progScreen->Destroy()
return wxApp::OnExit();
}