On Jan 3, 10:54 pm, Neilz <[email protected]> wrote: > Dear Rohit. > > When you have found your answers, please come back here and post them > so we can all share in your new found knowledge. > > Thanx in advance... ;-)
Q. Handler and Looper? Handler The most flexible means of making an Android-friendly background thread is to create an instance of a Handler subclass. You only need one Handler object per activity, and you do not need to manually register it or anything—merely creating the instance is sufficient to register it with the Android threading subsystem. Your background thread can communicate with the Handler, which will do all of its work on the activity’s UI thread. This is important because UI changes, such as updating widgets, should only occur on the activity’s UI thread. You have two options for communicating with the Handler: messages and Runnable objects. Messages To send a Message to a Handler, first invoke obtainMessage() to get the Message object out of the pool. There are a few flavors of obtainMessage(), allowing you to just create empty Message objects, or ones populated with message identifiers and arguments. The more complicated your Handler processing needs to be, the more likely it is you will need to put data into the Message to help the Handler distinguish different events. Then, you send the Message to the Handler via its message queue, using one of the following sendMessage...() family of methods: • sendMessage() puts the message on the queue immediately • sendMessageAtFrontOfQueue() puts the message on the queue immediately, and moreover puts it at the front of the message queue (versus the back, as is the default), so your message takes priority over all others • sendMessageAtTime() puts the message on the queue at the stated time, expressed in the form of milliseconds based on system uptime (SystemClock.uptimeMillis()) • sendMessageDelayed() puts the message on the queue after a delay, expressed in milliseconds. To process these messages, your Handler needs to implement handleMessage(), which will be called with each message that appears on the message queue. There, the handler can update the UI as needed. However, it should still do that work quickly, as other UI work is suspended until the Handler is done. Looper Getting tasks into a separate thread, then getting results back to the main UI thread is where the Handler, and related classes, come into play. When a Handler is created, it is associated with a Looper. A Looper is a class that contains a MessageQueue and processes Message or Runnable objects that are sent via the Handler. In the Handler usage. With this approach, the Handler is automatically associated with the Looper of the current running thread, typically the main UI thread. The main UI thread, which is created by the process of the running application, is an instance of a HandlerThread, which is basically an Android Thread specialization that provides a Looper. Q.. What is a ContentProvider? How to involve it from ContentResolver? Content Providers Any Uri in Android that begins with the content:// scheme represents a resource served up by a content provider. Content providers offer data encapsulation using Uri instances as handles you neither know nor care where the data represented by the Uri comes from, so long as it is available to you when needed. The data could be stored in a SQLite database, or in flat files, or retrieved off a device, or be stored on some far-off server accessed over the Internet. A shareable data store. Content Providers are used to manage and share application databases. Content Providers are the preferred way of sharing data across application boundaries. This means that you can configure your own Content Providers to permit access from other applications and use Content Providers exposed by others to access their stored data. Android devices include several native Content Providers that expose useful databases like contact information. Content Providers are a generic interface mechanism that lets you share data between applications. By abstracting away the underlying data source, Content Providers let you decouple your application layer from the data layer, making your applications data-source agnostic. Content Providers feature full permission control and are accessed using a simple URI model. Shared content can be queried for results as well as supporting write access. As a result, any application with the appropriate permissions can add, remove, and update data from any other applications — including some native Android databases. Many of the native databases have been made available as Content Providers, accessible by third-party applications. This means that your applications can have access to the phone’s Contact Manager, media player, and other native database once they’ve been granted permission. By publishing your own data sources as Content Providers, you make it possible for you (and other developers) to incorporate and extend your data in new applications. Content Resolvers Using Content Providers Access to Content Providers is handled by the ContentResolver class. The following sections demonstrate how to access a Content Resolver and how to use it to query and transact with a Content Provider. They also demonstrate some practical examples using the native Android Content Providers. Introducing Content Resolvers Each application Context has a single ContentResolver, accessible using the getContentResolver method, as shown in the following code snippet: ContentResolver cr = getContentResolver(); Content Resolver includes several methods to transact and query Content Providers. You specify the provider to interact using a URI. A Content Provider’s URI is defi ned by its authority as defi ned in its application manifest node. An authority URI is an arbitrary string, so most providers expose a CONTENT_URI property that includes its authority. Content Providers usually expose two forms of URI, one for requests against all the data and another that specifi es only a single row. The form for the latter appends /<rowID> to the standard CONTENT_URI. Q. What is Canvas.restore() and Canvas.save()? Why are they required? public void restore () This call balances a previous call to save(), and is used to remove all modifications to the matrix/clip state since the last save call. It is an error to call restore() more times than save() was called public int save () Saves the current matrix and clip onto a private stack. Subsequent calls to translate,scale,rotate,skew,concat or clipRect,clipPath will all operate as usual, but when the balancing call to restore() is made, those calls will be forgotten, and the settings that existed before the save() will be reinstated. Returns • The value to pass to restoreToCount() to balance this save() -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
