I have recently put an application on the Market and I have received until now 7 errors that look like the following:
java.lang.IllegalArgumentException: Wrong state class, expecting View State but received class android.widget.ProgressBar$SavedState instead. This usually happens when two views of different type have the same id in the same hierarchy. This view's id is id/0x2. Make sure other views do not use the same id.
Can someone tell me how to debug the problem? What is View with id 0x2 - is there a way to find out?
I've received this error under the following conditions - I'm replacing the icon of an item in the actionbar (in my case a throbber for a refresh button), and while it's in that state, I rotate the device. This error arises from it trying to restore the view's saved state and noticing the difference between what's declared and what's serialized.
There should be a stacktrace next to the report which could help you find the exact line of code.
Related
When I add a view to xml (layout) of my activity, it takes an id, so I can use that id in code of activity to recognize it and change my view if I like. Android make an R.class as an intermediate between my activity code an my layout(xml), so I use R.class for example:
findViewById(R.id.textView);
But how does android find it is a TextView? For example, if I write:
Button b = findViewById(R.id.textView);
I get an error. From where does it find I write it wrong?
I mean in R.class it define my id so android know a new id is defined in my xml, and I use it to return an object of View class or class extend View. But how does it find I am writing wrong and it is not a button, before I run the program (in compile time)?
Android Studio runs Android lint checks on your code, and there's the WrongViewCast check to detect such issues and report them as errors:
WrongViewCast
-------------
Summary: Mismatched view type
Priority: 9 / 10
Severity: Error
Category: Correctness
Keeps track of the view types associated with ids and if it finds a usage of
the id in the Java code it ensures that it is treated as the same type.
Source: http://tools.android.com/tips/lint-checks
If your view, that is returned by findViewById(R.id.ID), doesn't cast to the field you're assigning the view to, your code won't even compile! Android Studio checks your assigned variables and tries to cast them in real-time, but if that fails, because you made a mistake, your Activity.java can't compile! This is just a way of how this IDE operates.
Some time ago, you needed to cast the view manually, like this:
(TextView) findViewById(R.id.text_view)
But this is not necessary anymore.
I am getting TransactionTooLarge exception if page size = 50 and I press the home button. I checked the FragmentStateAdapter and found that 'saveState()' method is finalized.
Please help me how to resolve this.
In ViewPager it was overriden by me using below link-
https://medium.com/#mdmasudparvez/android-os-transactiontoolargeexception-on-nougat-solved-3b6e30597345
But no way in View pager2 library.
I had terrible random crash with my fragments.
The one megabyte limit is system wide, so it can crash at much lower thresholds.
I fixed the issue by stopping to use serialized objects and only passing integers into intents and fragment arguments.
Then fragments and activities can get the actual object from a repository using the integer id I gave to it.
It is faster and with insight it is a lot simpler.
I'm creating my first android app and i have a few layouts so far. In one of them i created a TextView and named it "textViewCurrentUserName". For my surprise, when i created a new layout, inserted a new TextView and try to name it "textViewCurrentUserName" i got a error stating that the name already exists!!! This has got to be a bug right?!? i mean, ok to "no repeat" on the same layout (xml), but these are totally different layouts!!!
Am I doing something wrong here?!? Is there a workaround this??? i dont want to keep a totally idiotic and hard-to-read/understand name such as "activity_UserDetails_TextViewCurrentUserName" and "activity_UserExport_TextViewCurrentUserName"
The Android ID field creates a unique ID for each UI element and stores them in the R file. Since fragments/activities and layouts and fairly decoupled, the app itself won't know which layouts and UI elements are available. Thus, you must explicitly state which element you're looking for. The app will throw an exception if the specified UI element is not currently available (or, perhaps, the element will be null).
The only workaround is to develop a naming convention. One might use [fragment-name]_textViewCurrentUser to allow each text view to have a unique ID. Or perhaps you can put a lowercase "t" in front of each UI element that is a text view: [fragment-name]_tCurrentUser.
I know I can create a fragment and add it via Tag or Id. Is it optional to use either one? Is there any kind of reason why I should use one over the other?
model = new ModelFragment();
//tag
getSupportFragmentManager().beginTransaction().add(model, "tag").commit();
//id
getSupportFragmentManager().beginTransaction().add( 4, model).commit();
IDs are used for static fragments, fragments whose state you don't want to modify during the activity life cycle.
To dynamically add a fragment use tags :
android.app.FragmentTransaction ft = getFragmentManager().beginTransaction();
ft.replace(R.id.fragment_container, fragment, TAG);
ft.commit();
To get the fragment somewhere in code, use something like:
if(getFragmentManager().findFragmentByTag(TAG)!=null){
ft.remove(getFragmentManager().findFragmentByTag(TAG));
ft.commit();
}
I believe you can only add an id to a Fragment if it is a static Fragment (i.e. via xml). If you want to dynamically add Fragments via FragmentTransaction the third parameter of add() is a String for the tag. Giving a tag is optional, but recommended so you can get a hold of the Fragment later on.
On the id case you are showing, the first parameter of add() is the layout id of the container you want to add the Fragment to, not the id for the Fragment itself.
IDs are used to identify the container this fragment will be placed into. Taken from documentation:
containerViewId Optional identifier of the container this fragment is to be placed in. If 0, it will not be placed in a container.
Using this id, you can retrieve the fragment later on with findFragmentById - see below.
Tags are a label used by fragment manager to later identify and retrieve a fragment. By using a tag, a fragment can be identified no matter what container holds that fragment.
Ids and tags can be used at the same time or separatelly. FragmentManager can identify a fragment by both id and tag.
I believe you can only add an id to a Fragment if it is a static Fragment (i.e. via xml)
I think it's an incorrect statement as I'm certain You can write something like:
mCoordinatorLayout.id = R.id.myview // or View.generateViewId() giving it whatever Id that You can retrieve later on typing: mCoordinatorLayout.id
So You can set the ID dynamically.
I think that TAG's work a bit differently (safer) and was introduced to avoid some bugs (I encountered) when You remove and add View Object's programmatically OR EVEN BEFORE COMPILING !
Let's say You write some code assigning a Button ID 'viewid'
Since now 'viewid' stays as an entry in R.id file and the entry is linked to the Button having assigned 'under the hood' it's Object number.
Than You remove code declaring the Button (but the 'viewid' is still there referencing to now nonexistent Object ! Probably it's not a big problem if You just leave the rubbish in the R.id file not using the same name again before compiling as most likely the link to nonexistent object would be cleared off during the next compilation)
But...
Now (before next compiling) create for an instance a FloatingActionButton (which is a different Object) and than assign it same named ID: 'viewid'.
BUG ! It's still referencing nonexistent Object (the already removed from code Button).
If it's nonexistent that's not the worse - it will give an error during compilation.
But imagine You have added another similar View, it compiles fine, but leads to unexpected behaviour referencing all the time wrong object !
I experienced that and it wasted me plenty of time...
It took me a lot to find out what was the problem and how to sort it out (clean project->rebuild project->clear caches and restart AS - not sure if all the steps was required, but it helps).
R.id file is just a list of ID's and it can also contain ID's for future purposes (or accidentally left rubbish).
Compiler must swap the alphanumeric representation of the ID's on numbers numbering View Objects as they go (1,2,3...). Than You can run on it
findViewById(whatever_id) // where 'whatever_id' under the hood really is an Object number
I guess there is some similar issue happening on run time and that's the reason of later on introducing TAG (which maybe stays in memory as an alphanumeric entry instead of just a number being more unambiguous ??) which runs extra check mechanisms to avoid such of bugs.
I think that ID may be working faster as under the hood it's operating on just a simple number with no fancy checks and that's why Android developers did not deprecated it (perhaps just yet only as it is deeply sitting in Android core since it's first revisions, but it may be a matter of time ??).
BTW
I've reported that the bug to AS, but they took no action about it maybe because I got some noobish rating so please let them know if You can as it is a serious bug.
Hi I am using Wiengine for making my game and I am getting this error
The child(wySprite, x) is already attached to another parent(wySprite, xx), skip addChild
Can any one let me know how this error can be resolved
It means the sprite already has a parent node. If you see this error, generally you have some wrong logic in your code. Well, currently WiEngine is open-sourced, you can directly debug it. https://github.com/stubma/WiEngine