Android reference view from activity

Referencing Android Activity View from a Singleton object

Suppose I have an Android Activity ( SecondaryActivity ), which is started from MainActivity

SecondaryActivity contains a text view, TextView tv;

I have a Singleton that looks something like this:

In my SecondaryActivity I do:

Now imagine later I run finish() inside SecondaryActivity so the program state returns back to MainActivity , popping SecondaryActivity off the Activity stack.

And now imagine MainActivity runs

After this, if I run

will we be referencing the TextView within the Activity currently at the top of the Activity stack?

Also, is there any obvious problems with my approach in general?

1 Answer 1

will we be referencing the TextView within the Activity currently at the top of the Activity stack?

Only if you run Singleton.getInstance().setTV(findViewById(R.id.sec_text_view)); in the onCreate method of your second activity.

Also, is there any obvious problems with my approach in general?

YES!! You should not put views/activity references in static classes/fields. You are creating memory leaks. When you call finish from the SecondaryActivity your singleton still references the text view and the activity can’t be garbage collected. This leaks memory.

When you start SecondaryActivity again, a new instance of SecondaryActivity is created. Unless you call setTV again your singleton still references the text view from the finished activity.

Here is a blog post with more information about memory leaks.

If you want to simplify view binding you should take a look at ButterKnife.

Источник

How to reference the current or main activity from another class

I often find myself needing to access methods that require referencing some activity. For example, to use getWindowManager , I need to access some Activity. But often my code for using these methods is in some other class that has no reference to an activity. Up until now, I’ve either stored a reference to the main activity or passed the context of some activity to the class. Is there some better way to do this?

12 Answers 12

If you already have a valid context, just use this: Activity activity = (Activity) context;

Passing context is better way for refrence Activity.

You can pass Context to another class.

IN Activity ::

IN Another Class

You can implement the necessary methods in your activity and implement a Handler. Then, simply pass a handler instance to your classes, where you can obtain a message for handler and send it to target.

You can make you application instance a singleton, and use it when you need a Context

This way, when you need a Context, you can get it with
Context context = MyApplication.getInstance()

This might not be the cleanest solution, but it has worked well for me so far

I’m new to android so my suggestion may look guffy but what if you’ll just create a reference to your activity as a private property and assign that in OnCreate method? You can even create your CustomActivity with OnCreate like that and derive all your activities from your CustomActivity, not generic Activity provided by adnroid.

I found a way to get the Activity to a non-activity class that I have not seen discussed in forums. This was after numerous failed attempts at using getApplicationContext() and of passing the context in as a parameter to constructors, none of which gave Activity. I saw that my adapters were casting the incoming context to Activity so I made the same cast to my non-activity class constructors:

After doing this cast conversion of Context to Activity I could use this.activity wherever I needed an Activity context.

There are many ways for Activities communication.

the startActivityForResult method

a system of broadcast message and receiver (you can broadcast an event from the actual activity, and register a receiver in the target activity. Remember that the target activity must be previously initialized and non finished)

as you say, store a reference of the target activity wherever you need.

We built a framework for this. We have a BaseActivity class that inherits from Activity and it overrides all the lifecycle methods and has some static (class) variables that keep track of the activity stack. If anything wants to know what the current activity is, it just calls a static method in BaseActivity that returns the activity on top of our privately-managed stack.

It is kinda hacky, but it works. I’m not sure I would recommend it though.

Handle the Intent in the class you want to do these methods, and send your information to it in a Bundle like so:

Then use an OnActivityResultListener to grab the new data.

I solved this by making a singleton class has an instance of the class below as a member.

This class can get a T object and return a unique integer assigned to the object by attach(). Assigned integers will not collide with each other unless HashMap fails. Each assigned integer will be freed when its corresponding object is detached by detach(). Freed integers will be reused when a new object is attached.

And from a singleton class:

And from an activity that needs to be referred:

Now with this, a unique integer corresponding to this activity instance is returned. And an integer can be delivered into another starting activity by using Intent and putExtra().

And from the another activity:

And finally the activity can be referred. And InterActivityReferrer can be used for any other class.

Источник

How to get Activity’s content view?

What method should I call to know if an Activity has its contentView (once the method setContentView() has been called)?

8 Answers 8

You can get the view Back if you put an ID to your Layout.

And call it from findViewById .

You may want to try View.getRootView() .

You can also override onContentChanged() which is among others fired when setContentView() has been called.

If you are using Kotlin

There is no «isContentViewSet» method. You may put some dummy requestWindowFeature call into try/catch block before setContentView like this:

If content view was already set, requestWindowFeature will throw an exception.

The best option I found and the less intrusive, is to set a tag param in your xml, like

PHONE XML LAYOUT

TABLET XML LAYOUT

and then call this in your activity class:

Hope it works for u.

Not the answer you’re looking for? Browse other questions tagged android or ask your own question.

Linked

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

site design / logo © 2021 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2021.12.3.40888

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

View Binding in Android

We have learnt that every time we need to access a view from our XML layout into our Java or Kotlin code, we must use findViewById(). It was okay for small/personal projects where we use 5 to 6 views in a layout. But for larger projects we have comparatively more views in a layout, and accessing each view using the same findViewById() is not really comfortable.

What is View Binding?

View binding is a feature that allows you to more easily write code that interacts with views. Once view binding is enabled in a module, it generates a binding class for each XML layout file present in that module

Simply put, this allows us to access the views from the layout file in a very simple way by linking variables of our Kotlin or Java code with the XML views. When a layout is inflated, it creates a Binding object, which contains all the XML views that are casted to the correct type. This makes it really easier for us since we can retrieve all views in one line of code.

Getting started with View Binding

1. Let’s start by enabling view binding in our project:

In build.gradle(:app) add the code in -> android

2. Before the onCreate() method, we create our binding object

3. Perform the following steps in onCreate() method:

• Call the inflate() method to create an instance of the binding class for the activity to use.
• Get reference to the root view
• Pass the root view to setContentView() [setContentView(binding.root)] instead of layout [setContentView(R.id.activity_main)]

4. To get reference of any view, we can use the binding object:

Using View Binding in Fragments

We follow the same steps:

1. Before the onCreateView() method, we create our binding object

2. Initialize our binding object in onCreateView()

3. To get reference of any view, we can use the binding object

Note: The name of the binding class is generated by converting the name of the XML file to camel case and adding the word “Binding” to the end. Similarly, the reference for each view is generated by removing underscores and converting the view name to camel case . For example, activity_main.xml becomes ActivityMainBinding, and you can access @id/text_view as binding.textView.

View binding has important advantages over using findViewById():

• Null safety: Since view binding creates direct references to views, there’s no risk of a null pointer exception due to an invalid view ID.
• Type safety: The fields in each binding class have types matching the views they reference in the XML file. This means that there’s no risk of a class cast exception.

Start using View Binding

If you’re intrigued by View Binding and want to learn more about it, here’s some resources for you to learn:

One-Liner ViewBinding Library

You would have noticed that to use View Binding, we need to call the static inflate() method included in the generated binding class ( which creates an instance of the binding class for the activity or fragment )

Yesterday I came across an awesome library that makes ViewBinding one-liner ( By removing the boilerplate code and easily set ViewBindings with a single line )

One-liner ViewBinding Library : [Click Here]

Источник

Use view binding to replace findViewById

New in Android Studio 3.6, view binding gives you the ability to replace findViewById with generated binding objects to simplify code, remove bugs, and avoid all the boilerplate of findViewById .

• Enable view binding in build.gradle (no libraries dependencies)
• View binding generates a binding object for every layout in your module ( activity_awesome.xml → ActivityAwesomeBinding.java )
• Binding object contains one property for every view with an id in the layout — with the correct type and null-safety
• Full support for both the Java programming language and Kotlin

Update build.gradle to enable view binding

You don’t need to include any extra libraries to enable view binding. It’s built into the Android Gradle Plugin starting with the versions shipped in Android Studio 3.6. To enable view binding, configure viewBinding in your module-level build.gradle file.

In Android Studio 4.0, viewBinding has been moved into buildFeatures [release notes] and you should use:

Once enabled for a project, view binding will generate a binding class for all of your layouts automatically. You don’t have to make changes to your XML — it’ll automatically work with your existing layouts.

View binding works with your existing XML, and will generate a binding object for each layout in a module.

You can use the binding class whenever you inflate layouts such as Fragment , Activity , or even a RecyclerView Adapter (or ViewHolder ).

Use view binding in an Activity

If you have a layout called activity_awesome.xml , which contains a button and two text views, view binding generates a small class called ActivityAwesomeBinding that contains a property for every view with an ID in the layout.

You don’t have to call findViewById when using view binding — instead just use the properties provided to reference any view in the layout with an id.

The root element of the layout is always stored in a property called root which is generated automatically for you. In an Activity ’s onCreate method you pass root to setContentView to tell the Activity to use the layout from the binding object.

Easy Mistake: Calling setContentView(…) with the layout resource id instead of the inflated binding object is an easy mistake to make. This causes the layout to be inflated twice and listeners to be installed on the wrong layout object.

Solution: When using view binding in an Activity , you should always pass the layout from the binding object with setContentView(binding.root) .

Safe code using binding objects

findViewById is the source of many user-facing bugs in Android. It’s easy to pass an id that’s not in the current layout — producing null and a crash. And, since it doesn’t have any type-safety built in it’s easy to ship code that calls findViewById

(R.id.image) . View binding replaces findViewById with a concise, safe alternative.

View bindings are…

• Type-safe because properties are always correctly typed based on the views in the layout. So if you put a TextView in the layout, view binding will expose a TextView property.
• Null-safe for layouts defined in multiple configurations. View binding will detect if a view is only present in some configurations and create a @Nullable property.

And since the generated binding classes are regular Java classes with Kotlin-friendly annotations, you can use view binding from both the Java programming language and Kotlin.

What code does it generate?

View binding generates a Java class that replaces the need for findViewById in your code. It will generate one binding object for every XML layout in your module while mapping names so activity_awesome.xml maps to ActivityAwesomeBinding.java .

When editing an XML layout in Android Studio, code generation will be optimized to only update the binding object related to that XML file, and it will do so in memory to make things fast. This means that changes to the binding object are available immediately in the editor and you don’t have to wait for a full rebuild.

Android Studio is optimized to update the binding objects immediately when editing XML layouts.

Let’s step through the generated code for the example XML layout from earlier in this post to learn what view binding generates.

View binding will generate one correctly-typed property for each view with a specified id . It will also generate a property called rootView that’s exposed via a getter getRoot . View binding doesn’t do any logic– it just exposes your views in a binding object so you can wire them up without error-prone calls to findViewById . This keeps the generated file simple (and avoids slowing down builds).

If you’re using Kotlin, this class is optimized for interoperability. Since all properties are annotated with @Nullable or @NonNull Kotlin knows how to expose them as null-safe types. To learn more about interop between the languages, check out the documentation for calling Java from Kotlin.

In ActivityAwesomeBinding.java , view binding generates a public inflate method. The one argument version passes null as the parent view and doesn’t attach to parent. View binding also exposes a three argument version of inflate that lets you pass the parent and attachToParent parameters when needed.

The call to bind is where the magic happens. It will take the inflated layout and bind all of the properties, with some error checking added to generate readable error messages.

The bind method is the most complex code in the generated binding object, with a call to findViewById for each view to bind. And here you can see the magic happen – since the compiler can check the types and potential nullability of each property directly from the XML layouts it can safely call findViewById .

Note, the actual generated code for the bind method is longer and uses a labeled break to optimize bytecode. Check out this post by Jake Wharton to learn more about the optimizations applied.

On each binding class, view binding exposes three public static functions to create a binding an object, here’s a quick guide for when to use each:

• inflate(inflater) – Use this in an Activity onCreate where there is no parent view to pass to the binding object.
• inflate(inflater, parent, attachToParent) – Use this in a Fragment or a RecyclerView Adapter (or ViewHolder ) where you need to pass the parent ViewGroup to the binding object.
• bind(rootView) – Use this when you’ve already inflated the view and you just want to use view binding to avoid findViewById . This is useful for fitting view binding into your existing infrastructure and when refactoring code to use ViewBinding .

What about included layouts

One binding object will be generated for each layout.xml in a module. This is true even when another layout s this this layout.

In the case of included layouts, view binding will create a reference to the included layout’s binding object.

Note that the tag has an id: android:id=»@+id/includes» . This is required for view binding to generate a property (just like a normal view).

Include tags must have an id to generate a binding property.

View binding will generate a reference to the IncludedButtonsBinding object in ActivityAwesomeBinding .

Using view binding and data binding

View binding is only a replacement for findViewById . If you also want to automatically bind views in XML you can use the data binding library. Both libraries can be applied to the same module and they’ll work together.

When both are enabled, layouts that use a tag will use data binding to generate binding objects. All other layouts will use view binding to generate binding objects.

You can use data binding and view binding in the same module.

We developed view binding in addition to data binding because many developers provided feedback that they wanted a lighter weight solution to replace findViewById without the rest of the data binding library – and view binding provides that solution.

View binding and Kotlin synthetics or ButterKnife

One of the most common questions asked about view binding is, “Should I use view binding instead of Kotlin synthetics or ButterKnife?” Both of these libraries are used successfully by many apps and solve the same problem.

For most apps we recommend trying out view binding instead of these libraries because view binding provides safer, more concise view lookup.

While ButterKnife validates nullable/non-null at runtime, the compiler does not check that you’ve correctly matched what’s in your layouts

We recommend trying out view binding for safe, concise, view lookup.

Learn more

To learn more about view binding check out the official documentation.

And we’d love to hear your experiences with #ViewBinding library on twitter!

Источник