File cacheDir;
File fileDir;
/* 取得目前Cache目录 */
cacheDir = this.getCacheDir();
/* 取得目前File目录 */
fileDir = this.getFilesDir();

几个不错的Android专栏地址:

第三极:

http://disanji.net/category/android-doc/

moandroid:

http://www.moandroid.com/?page_id=1176

maxlen的专栏:

http://mobile.csdn.net/a/20110209/291511.html

魏祝林的专栏:

http://blog.csdn.net/Android_Tutor/

duguguiyu的深入Android:

http://www.uml.org.cn/j2ee/201004135.asp

我一个哥们的博客，优化Dalvik虚拟机的牛人:

http://blog.csdn.net/tuhuolong/archive/2010/07/26/5766279.aspx

AnroidJNI开发入门系列:

http://my.unix-center.net/~Simon_fu/?p=833

Android游戏开发:

http://mobile.csdn.net/a/20110216/292016.html

Linux下搭建Android开发环境:

http://flysnow.iteye.com/blog/810083

Android的source code:

http://source.android.com/index.html

如果能把这些牛人的专栏研究透，应该多少也能算半个牛人了吧。

转至：http://lixiangyu.iteye.com/blog/1056295

A common question we hear is “Can parameters be safely passed in URLs to secure web sites? ” The question often arises after a customer has looked at an HTTPS request in HttpWatch and wondered who else can see this data.

For example, let’s pretend to pass a password in a query string parameter using the following secure URL:

https://www.httpwatch.com/?password=mypassword

HttpWatch is able to show the contents of a secure request because it is integrated with the browser and can view the data before it is encrypted by the SSL connection used for HTTPS requests:

If you look in a network sniffer, like Network Monitor, at the same request you would just see the encrypted data going backwards and forwards. No URLs, headers or content is visible in the packet trace::

You can rely on an HTTPS request being secure so long as:

• No SSL certificate warnings were ignored
• The private key used by the web server to initiate the SSL connection is not available outside of the web server itself.

So at the network level, URL parameters are secure, but there are some other ways in which URL based data can leak:

The solution to this problem requires two steps:

• Only pass around sensitive data if absolutely necessary. Once a user is authenticated it is best to identify them with a session ID that has a limited lifetime.
• Use non-persistent, session level cookies to hold session IDs and other private data.

The advantage of using session level cookies to carry this information is that:

• They are not stored in the browsers history or on the disk
• They are usually not stored in server logs
• They are not passed to embedded resources such as images or javascript libraries
• They only apply to the domain and path for which they were issued

Here’s an example of the ASP.NET session cookie that is used in our online store to identity a user:

Notice that the cookie is limited to the domain store.httpwatch.com and it expires at the end of the browser session (i.e. it is not stored to disk).

You can of course use query string parameters with HTTPS, but don’t use them for anything that could present a security problem. For example, you could safely use them to identity part numbers or types of display like ‘accountview’ or ‘printpage’, but don’t use them for passwords, credit card numbers or other pieces of information that should not be publicly available.