ctrl+space
Also see auto complete
Fn + Ctrl + F12
Are android:name and class: interchangeable?
As CS students you already know this - when in doubt stackoverflow. Most Android developers are on there and the problems you are experiencing and can't seem to get beyond have -- in all likliness -- been experienced and documented on that forum.
On annoying thing about android programming is they keep evolving the APIs between major releases of the OS. No sooner have you used an API than the next release depricates some part of it. So the goal posts keep moving. But it seems much more stable now than two years ago.
Previously, I could see method javadoc description, when moving my mouse over a method name and waiting for about a second. Now it stopped working for some reason.
Go to Window->Android SDK Manager and install "Sources for Android SDK".
Now try to control-click some Android identify, you will get the usual "no source attached" page. Click "Attach Source" and get the option to select an external folder.
Now browse to /home/me/android-sdks/sources/android-16 (or wherever your SDK is installed; this is the default), and hit ok.
It should think for a moment and then display the source! Yeay!
Sometime you get strange warnings. For example, I added a new activity to the manifest that had an intent filter. I got a new warning that I'd not seen before about Exported activity does not require permission. This is the android system telling you about resticting the activity to be fired only by components associated with your app or exporting it so other apps can fire intents to your component. Going on stackflow I found that I should include an android:exported="false" to slove this. But I've never had to do this before. Odd. True I'n using a new API version. More digging and I eventually found this good advise
And once I'd done this my warning was gone.
To clean the workspace:
project -> clean and then select clean all projects
http://www.mybringback.com/travis-android-help/1/hello-world/
Under SDK Manager
if you get a warning that your SDK is not up to date but when you do a check for software updates you get no updates then read this.
http://stackoverflow.com/questions/15105730/when-i-load-adt-why-do-i-receive-the-error-the-android-sdk-requires-android-dev
at sun.nio.ch.FileDispatcher.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29)Try Cleaning your project.
Check on build automatically -- build only selective projects
Restart Eclipse.
http://stackoverflow.com/questions/4745366/how-to-resolve-build-path-errors
You should be able to select all the offending markers in the Problems View, right-click and choose Delete from the context menu. Clean-building causes all builders to remove only the markers that they produced, but these markers weren't produced by a builder (you created them through an explicit invocation of the "validate" command.)
http://stackoverflow.com/questions/3420536/how-do-you-clear-the-validation-errors-in-eclipse
Try changing the ADB connection timeout. I think it defaults that to 5000ms and I changed mine to 10000ms to get rid of that problem. If you are in Eclipse, you can do this by going through Window -> Preferences and then it is in DDMS under Android.
http://stackoverflow.com/questions/5229906/android-failed-to-install-helloworld-apk-on-device-null-error
If you are working on an app, make a change (say you make changes to working code) and experience some strange behavior -- even though you have convinced yourself you have added code that hasn't created new bugs -- then uninstall the app on the phone settings>app>uninstall then try and install and see if it works. If not you added bugs.
http://developer.android.com/tools/help/adb.html
http://mobileaccessibility.cs.washington.edu/apps/docs/HowToInstallAPKFiles.pdf
Generally when I see this error if I am using Eclipse I will close and reopen the program. I will then uninstall the Application from the target phone. This sometimes fixes the issue but not always.
Next I will open up the command terminal and head into the android-sdk then run:
./adb install
(9 times out of 10 it simply says 'INSTALL_ALREADY_EXISTS' and I go and uninstall the application off the target phone again then run adb and I am working fine.
Installing an Application You can use adb to copy an application from your development computer and install it on an emulator/device instance. To do so, use the install command. With the command, you must specify the path to the .apk file that you want to install:
adb install
You should set up your $PATH in .bash_profile to include
/Users/atc/Dropbox/teaching/cs65/workspace/adt-bundle-mac-x86_64/sdk/platform-tools
/Users/atc/Dropbox/teaching/cs65/workspace/HelloWorld/bin/HelloWorld.apk
You can't install and run in one go - but you can certainly use adb to start your already installed application. Use adb shell am start to fire an intent - you will need to use the correct intent for your application though. A couple of examples:
adb shell am start -a android.intent.action.MAIN -n com.android.settings/.Settings will launch Settings, and
adb shell am start -a android.intent.action.MAIN -n com.android.browser/.BrowserActivity will launch the Browser. If you want to point the Browser at a particular page, do this
adb shell am start -a android.intent.action.VIEW -n com.android.browser/.BrowserActivity http://www.google.co.uk
http://stackoverflow.com/questions/6109234/how-to-runnot-only-install-an-android-application-using-apk-file
$adb shell am start -a android.intent.action.MAIN -n edu.dartmouth.cs.helloworld/.MainActivity
Starting: Intent { act=android.intent.action.MAIN cmp=edu.dartmouth.cs.helloworld/.MainActivity }
Check it out
The Android logging system provides a mechanism for collecting and viewing system debug output. Logs from various applications and portions of the system are collected in a series of circular buffers, which then can be viewed and filtered by the logcat command.
You can use the logcat command to view and follow the contents of the system's log buffers. The general usage is:
[adb] logcat [option] ... [filter-spec] ... You can use the logcat command from your development computer or from a remote adb shell in an emulator/device instance. To view log output in your development computer, you use
adb logcat and from a remote adb shell you use
logcat
Window > Reset Perspective
Make sure you have selected the right configuration -- make sure you have set up a run configuration.
See Run> Run Configuration or Run > Run History
Shitt Command F11
Sweet
You have to add compatibility library by right clicking your project and selecting Android Tools -> Add Compatibility Library. Once its added, clean your project and build again.
http://stackoverflow.com/questions/7298731/when-to-call-activity-context-or-application-context
getApplicationContext() is almost always wrong. Ms. Hackborn (among others) have been very explicit that you only use getApplicationContext() when you know why you are using getApplicationContext() and only when you need to use getApplicationContext().
To be blunt, "some programmers" use getApplicationContext() (or getBaseContext(), to a lesser extent) because their Java experience is limited. They implement an inner class (e.g., an OnClickListener for a Button in an Activity) and need a Context. Rather than using MyActivity.this to get at the outer class' this, they use getApplicationContext() or getBaseContext() to get a Context object.
You only use getApplicationContext() when you know you need a Context for something that may live longer than any other likely Context you have at your disposal. Scenarios include:
Use getApplicationContext() if you need something tied to a Context that itself will have global scope. I use getApplicationContext(), for example, in WakefulIntentService, for the static WakeLock to be used for the service. Since that WakeLock is static, and I need a Context to get at PowerManager to create it, it is safest to use getApplicationContext().
Use getApplicationContext() when you bind to a Service from an Activity, if you wish to pass the ServiceConnection (i.e., the handle to the binding) between Activity instances via onRetainNonConfigurationInstance(). Android internally tracks bindings via these ServiceConnections and holds references to the Contexts that create the bindings. If you bind from the Activity, then the new Activity instance will have a reference to the ServiceConnection which has an implicit reference to the old Activity, and the old Activity cannot be garbage collected.
Some developers use custom subclasses of Application for their own global data, which they retrieve via getApplicationContext(). That's certainly possible. I prefer static data members, if for no other reason than you can only have one custom Application object. I built one app using a custom Application object and found it to be painful. Ms. Hackborn also agrees with this position.
Here are reasons why not to use getApplicationContext() wherever you go:
It's not a complete Context, supporting everything that Activity does. Various things you will try to do with this Context will fail, mostly related to the GUI.
It can create memory leaks, if the Context from getApplicationContext() holds onto something created by your calls on it that you don't clean up. With an Activity, if it holds onto something, once the Activity gets garbage collected, everything else flushes out too. The Application object remains for the lifetime of your process.
thisWhen you create a new OnClickListener, you are creating a anonymous class which implements a particular interface. Thus, this does not refer to the Activity, since you are actually in another object.
http://stackoverflow.com/questions/9138875/toast-maketextgetapplicationcontext-string-toast-length-long-here-ge
http://www.codeproject.com/Articles/166327/Anonymous-Classes-vs-Delegates ## onSaveInstanceState() and onPause() -- when to use what?
http://stackoverflow.com/questions/5166201/android-onsaveinstancestate-and-onpause
onSaveInstanceState() is meant to "remember" the current state when a configuration change occurs like e.g. a screen orientation change. This is not meant for "long term persistence".
Note: Because onSaveInstanceState() is not guaranteed to be called, you should use it only to record the transient state of the activity (the state of the UI)—you should never use it to store persistent data. Instead, you should use onPause() to store persistent data (such as data that should be saved to a database) when the user leaves the activity.
dataonly... You can save non-view instance state ("internal state such as user preferences") on a soft kill (orientation change) in onSaveInstanceState using bundles and on a hard kill (back button while we are in focus) in onStop using preferences. If you have other data ("shared document-like data -- typically stored in a SQLite database using a content provider"), you should do this in onPause.