Question : Which of the following is a rule that developers must always follow when writing multi-threaded Android applications? (Choose two)
A. A worker thread must not be created from inside the UI thread. B. Each UI thread must not create more than one worker thread. C. The UI thread must never be blocked. D. The Android UI must not be accessed from outside the UI thread. 1. A,B 2. B,C 3. C,D 4. A,D
Correct Answer : 3 Explanation: Every app has its own special thread that runs UI objects such as View objects; this thread is called the UI thread. Only objects running on the UI thread have access to other objects on that thread. Because tasks that you run on a thread from a thread pool aren't running on your UI thread, they don't have access to UI objects. To move data from a background thread to the UI thread, use a Handler that's running on the UI thread. The UIThread is the main thread of execution for your application. This is where most of your application code is run. All of your application components (Activities, Services, ContentProviders, BroadcastReceivers) are created in this thread, and any system calls to those components are performed in this thread.
For instance, let's say your application is a single Activity class. Then all of the lifecycle methods and most of your event handling code is run in this UIThread. These are methods like onCreate, onPause, onDestroy, onClick, etc. Additionally, this is where all of the updates to the UI are made. Anything that causes the UI to be updated or changed HAS to happen on the UI thread. When you explicitly spawn a new thread to do work in the background, this code is not run on the UIThread. So what happens if this background thread needs to do something that changes the UI? This is what the runOnUiThread is for. Actually you're supposed to use a Handler (see the link below for more info on this). It provides these background threads the ability to execute code that can modify the UI. They do this by putting the UI-modifying code in a Runnable object and passing it to the runOnUiThread method. I personally only use the runOnUiThread method in my Instrumentation Tests. Since the test code does not execute in the UIThread, you need to use this method to run code that modifies the UI. So, I use it to inject click and key events into my application. I can then check the state of the application to make sure the correct things happened.
Question : Which of the following is NOT true about SQLiteOperHelper class? (Choose two)
A. It has two abstract methods: onCreate() and onUpgrade(). B. It is used to perform database querying. C. It manages database creation and updates. D. It manages database versions using ContentProvider 1. A,B 2. B,C 3. C,D 4. A,D 5. A,C
Correct Answer : 5 Explanation:
SQLiteOpenHelper onCreate() and onUpgrade() callbacks are invoked when the database is actually opened, for example by a call to getWritableDatabase(). The database is not opened when the database helper object itself is created.
SQLiteOpenHelper versions the database files. The version number is the int argument passed to the constructor. In the database file, the version number is stored in PRAGMA user_version.
onCreate() is only run when the database file did not exist and was just created. If onCreate() returns successfully (doesn't throw an exception), the database is assumed to be created with the requested version number. As an implication, you should not catch SQLExceptions in onCreate() yourself.
onUpgrade() is only called when the database file exists but the stored version number is lower than requested in constructor. The onUpgrade() should update the table schema to the requested version.
When changing the table schema in code (onCreate()), you should make sure the database is updated. Two main approaches:
Delete the old database file so that onCreate() is run again. This is often preferred at development time where you have control over the installed versions and data loss is not an issue. Some ways to to delete the database file:
Uninstall the application. Use the application manager or adb uninstall your.package.name from shell.
Clear application data. Use the application manager. Increment the database version so that onUpgrade() is invoked. This is slightly more complicated as more code is needed.
For development time schema upgrades where data loss is not an issue, you can just use execSQL("DROP TABLE IF EXISTS ") in to remove your existing tables and call onCreate() to recreate the database.
For released versions, you should implement data migration in onUpgrade() so your users don't lose their data.
Question : What method you should override to use Android menu system?
1. onCreateOptionsMenu()
2. onCreateMenu()
3. onMenuCreated()
4. onCreateContextMenu()
Correct Answer : 1 Explanation: To specify the options menu for an activity, override onCreateOptionsMenu() (fragments provide their own onCreateOptionsMenu() callback). In this method, you can inflate your menu resource (defined in XML) into the Menu provided in the callback. For example:
@Override public boolean onCreateOptionsMenu(Menu menu) { MenuInflater inflater = getMenuInflater(); inflater.inflate(R.menu.game_menu, menu); return true; } You can also add menu items using add() and retrieve items with findItem() to revise their properties with MenuItem APIs.
If you've developed your application for Android 2.3.x and lower, the system calls onCreateOptionsMenu() to create the options menu when the user opens the menu for the first time. If you've developed for Android 3.0 and higher, the system calls onCreateOptionsMenu() when starting the activity, in order to show items to the app bar.