Great question! Let's break this down clearly—this is all about understanding who's responsible for creating the object in the first place, and whether it already exists within the Android framework's context. Here's how to decide:

1. Use built-in getter methods when the object is already created by the system/framework #

The Android framework manages the lifecycle of core components (like Activities, Fragments, Views) and pre-creates critical objects for you. In these cases, you just need to grab a reference to the existing instance:

• getIntent(): The Intent that launched your Activity is created and passed to your app by the Android system when the Activity starts. You don't need to instantiate it—you just retrieve the one already provided.
• findViewById(R.id.button): Your Button instance is created automatically when the XML layout is inflated (during Activity initialization). The method just fetches the existing View object from the view hierarchy.
• getSupportFragmentManager(): The FragmentManager is a core part of your Activity's infrastructure, created by the framework when the Activity is set up. You use this getter to access it for fragment transactions.

Rule of thumb: If the object is tied to an Android component's lifecycle, or is a system-provided context/utility object, use the framework's built-in getter.

2. Use new when you need to create a custom or standalone object #

If the object isn't managed by the framework, or requires your own custom configuration/parameters, you're responsible for instantiating it:

• Creating a new Intent to launch another Activity: Intent intent = new Intent(this, TargetActivity.class); — this is a custom Intent you define for your navigation flow, so the system can't pre-create it for you.
• Instantiating a custom Fragment: MyCustomFragment fragment = new MyCustomFragment(); — since this is your own implementation, the framework has no way to know how to initialize it (e.g., with your custom arguments), so you create it directly.
• Creating a utility class instance: MyDataProcessor processor = new MyDataProcessor(); — this is a class you wrote for your business logic, so you handle its creation.

Rule of thumb: If the object is a custom implementation, requires specific initialization parameters, or isn't part of the Android component lifecycle, use new.

3. Use framework-provided factory methods as an alternative to new #

Sometimes the framework offers dedicated methods to create objects (instead of direct new) to handle context binding or simplify configuration. For example:

• AlertDialog dialog = new AlertDialog.Builder(this).setTitle("Hello").create(); — the Builder pattern here handles attaching the correct Activity context and simplifies setting up dialog properties, so it's better than directly instantiating AlertDialog with new.
• ViewModel viewModel = new ViewModelProvider(this).get(MyViewModel.class); — ViewModel requires lifecycle-aware initialization, so the framework provides the ViewModelProvider to create/retrieve instances correctly.

Rule of thumb: If the framework provides a specialized creation method (like builders or providers) for a class, use that instead of new—it ensures proper integration with Android's lifecycle and avoids common bugs.

内容的提问来源于stack exchange，提问作者SINGH