Android Interviews

Memory leak Create a memory leak? Here's a good way to create a true memory leak (objects inaccessible by running code but still stored in memory) in pure Java: The application creates a long-running thread (or use a thread pool to leak even faster). The thread loads a class via an (optionally custom) ClassLoader. The class allocates a large chunk of memory (e.g. new byte[1000000]), stores a strong reference to it in a static field, and then stores a reference to itself in a ThreadLocal. Allocating the extra memory is optional (leaking the Class instance is enough), but it will make the leak work that much faster. The thread clears all references to the custom class or the ClassLoader it was loaded from. Repeat. This works because the ThreadLocal keeps a reference to the object, which keeps a reference to its Class, which in turn keeps a reference to its ClassLoader. The ClassLoader, in turn, keeps a reference to all the Classes it has loaded...

Looper What is looper? Looper is a class which is used to execute the Messages(Runnables) in a queue. Normal threads have no such queue, e.g. simple thread does not have any queue. It executes once and after method execution finishes, the thread will not run another Message(Runnable). Where we can use Looper class? If someone wants to execute multiple messages(Runnables) then he should use the Looper class which is responsible for creating a queue in the thread. For example, while writing an application that downloads files from the internet, we can use Looper class to put files to be downloaded in the queue. How it works? There is prepare() method to prepare the Looper. Then you can use loop() method to create a message loop in the current thread and now your Looper is ready to execute the requests in the queue until you quit the loop.

ANR and how should we resolve that? ANR ,do you know how to fix it? Where To Look For ANR? The app is doing slow operations on main thread. (Including I/O) App is doing a long calculation on main thread. The main thread is doing a synchronous binder call to another process and that process is doing a heavy job. The main thread is blocked waiting for another process which is doing a long job. The main thread is in a deadlock with another thread. Fixes StrictMode is a developer tool which detects things you might be doing by accident and brings them to your attention so you can fix them. StrictMode is most commonly used to catch accidental disk or network access on the application's main thread, where UI operations are received and animations take place. Keeping disk and network operations off the main thread makes for much smoother, more responsive applications. By keeping your application'...

Have you ever used Room how to implement room db? Room is an ORM, Object Relational Mapping library. In other words, Room will map our database objects to Java objects. Room provides an abstraction layer over SQLite to allow fluent database access while harnessing the full power of SQLite. Database : This component represents data holder. The annotated class should be an abstract class that extends RoomDatabase. At runtime, you can acquire an instance of it by calling Room.databaseBuilder() or Room.inMemoryDatabaseBuilder(). DAO : DAOs are the main component of Room and are responsible for defining the methods that access the database. All queries are written in DAO only. IEntity : This component represents a database row of table. Each field of the entity is persisted in the database unless you annotate it with @Ignore . Difference between room and sqlite In case of SQLite, There is no compile tim...

Hello memory leaks.. How to handle memory leaks? The Activity starts to change configurations — is mercilessly torn down and recreated — but the previously existing and held reference keeps the Activity context and all its inflated Views alive, the garbage collector cannot finalize them. Of course, this also applies if the Activity is registered to a global bus, but it’s never unregistered, and the Activity is finished. Also happens if there is an uncleared static reference to the Activity. All of these can cause a memory leak. Effective remedies to be used WeakReference Using an EventBus that is paused while the Activity is not resumed, and enqueues events while paused PublishRelay + ObservableTransformers.valve() LiveData Read more about possible solutions here

ViewModel and its usage Should we use viewmodel and what benefits it brings? Architecture Components provides ViewModel helper class for the UI controller that is responsible for preparing data for the UI. ViewModel objects are automatically retained during configuration changes so that data they hold is immediately available to the next activity or fragment instance ViewModel objects are designed to outlive specific instantiations of views or LifecycleOwners. This design also means you can write tests to cover a ViewModel more easily as it doesn't know about view and Lifecycle objects. ViewModel objects are scoped to the Lifecycle passed to the ViewModelProvider when getting the ViewModel. The ViewModel remains in memory until the Lifecycle it's scoped to goes away permanently: in the case of an activity, when it finishes, while in the case of a fragment, when it's detached./li> If the ViewModel class is...

Have you heard of notification channels and what it does basically? Starting in Android 8.0 (API level 26), all notifications must be assigned to a channel. For each channel, you can set the visual and auditory behavior that is applied to all notifications in that channel. We also have the ability to group notification channels into separate groups. This is so that we are able to have the same notification channels across multiple application modes. Once our notifications are in these channels, we no longer have input into their functionality — so it is up to the user to manage these channels. Read more here

Livedata Why do you need Livedata? LiveData is lifecycle-aware.That means that only when the activity is in an active lifecycle state does the LiveData send an “on changed event”. If for example the activity is in the backstack, it won’t get notified on data changes until it becomes visible to the user again. No more manual lifecycle handling No crashes due to stopped activities No memory leaks Since the LiveData observable takes control of firing the events, there is no need for us to handle lifecycle manually. This ensures that when using LiveData, the UI component is always up to date even when it becomes inactive at some point, as it receives the latest data upon becoming active again. Read here to learn even more about it.