Proper way to wait end of a service and singleton design
Bug?

The catch block is a bit suspicious here:


try 
{
    FileTestSingleton.getIstance(); //this could be long, read from file
} catch (Exception e) 
{
    Log.e(LoadDataService.class.getName(), "FILE DATA LOADING ERROR \n" + e);
    result = Activity.RESULT_CANCELED;
}
result = Activity.RESULT_OK;
publishResults(result);



When you catch the exception, you set result = Activity.RESULT_CANCELED;,
but execution continues and on the next line comes result = Activity.RESULT_OK;.
In short, the method will return with success as if nothing happened.

Don't catch Exception

Always catch the most specific Exception type possible.
By catching something overly generic,
you may not notice when something truly unexpected is thrown.
In most practical situations there is a more specific exception class that you should check.

Don't declare a method to throw Exception

A method that's declared to throw Exception is very poorly designed.
It gives no clue to the caller about the kind of failure that can happen,
and it's impossible to know how to recover from it.
Surely you can think of something more specific,
to give the chance to callers to handle the failure gracefully.

Coding style

There is a standard in Java for placing braces:
the opening braces should be on the same line as their statement. Follow this style:

try {
    // ...
} catch (Exception e) {
    // ...
}


Proper way to wait for end of X

In other words, the proper way to execute a long operation without freezing the client. I think it's using an AsyncTask, with a ProgressDialog. Here's a rough sketch:

class WaitForServiceAsyncTask extends AsyncTask&lt;Void, Integer, Void&gt; {
    ProgressDialog mProgressDialog;

    protected void onPreExecute() {
        mProgressDialog = ProgressDialog.show(YourActivity.this, "",
                YourActivity.this.getString(R.string.msg_waiting_for_service), false, true);
    }

    protected Void doInBackground(Void... params) {
        // the long task -- calling the service
    }
}


This won't freeze the UI thread and will let the user know that the app is not dead, but actually doing something.