HTTP basic authentication requires the username and password to be sent with every resource request. The username:password is passed in the "Authorization" request header base64 encoded string prefixed with "Basic ". If all of your http communication is encrypted (via ssl) the Authorization header's information shouldn't be able to be easily used by attackers since it's unlikely that they'll be able to get a hold of it.
SSL encrypted http with basic authentication should be enough.
There is no 100% secure solution. What ever you implement must be executable by a deterministic computer, so someone and substitute that and unpick what ever technical barriers you put in their way. You can make it more technically challenging and a more involved and slower process, but in time if the incentives are there, someone will break it.
If you are implementing this in .NET then, by default it is trivial for someone to obtain C# style source code to your application, and then to step through their C# code in a debugger. It is a little more complex in C/C++, but again not impossible. I do not know how much of a challenge this is with JAVA, but I would not expect it to be a significant hurdle.
There are processes that can be applied to make the code harder for a human to read, but do very little to make it harder for a computer to single step through the code. Someone can put a breakpoint in the system library and then back track up the call stack to see if this call to a network socket is of interest without having to understand your code base.
I have also seen encryption techniques used, where a program decrypts the actual code during run time. However, again, a determined hacker can just run this part of the code, obtain the decrypted code and then reverse engineer this into source code.
The best solution is to assume it will become compromised, and then ensure that the process for changing the sensitive data is trivial for you, and to process to compromise the sensitive data is as hard as possible for everyone else. That's why some systems require a web call to obtain the data. You can then block calls from IP's or from client certificates that you no longer trust, and give everyone else 'this months' application key.
In the end, you need to consider the consequences for having the data publicly known, and then decide how far you need to go, to make the process for obtaining it more skilled and and more time consuming.
Best Answer
Anything that ends up on the client in an unencrypted form can be accessed by the client. There's no way to avoid this. You have not control over what the client is doing with the responses that come from your server. The best you can do in this situation is obfuscate and/or try to make it more difficult for someone to access the key directly.
In situations like this, where you want to be able to allow your client to make direct calls to a third-party under your authority, you need some sort of token, ticket, or signing system which allows you to grant specific access to the client in a way that the 3rd-party provider can verify without giving the client your credentials.
I didn't spend much time looking into it and it's not really in the scope of this site to assist with the specifics of Googles API but as an example of how this works, it appears that this API provides a signature system. If I understand correctly, you would create a bare URL for the request that your client needs to make, and then using your credentials you get a signed URL from the API. This happens on your server, you would never provide your key to the client.
This signed URI would then be given back to the client and they can execute the call and the API will know that this is associated with your authority and billing. Presumably there is some sort of time limit on this signed URL. For those details, refer to the API documentation.