Fixed
Status Update
No update yet.
Comments
da...@google.com
I created a thread on the android-developers forum related to this bug:
http://groups.google.com/group/android-
developers/browse_thread/thread/6caa57135927e242/86d4d895e88a5ebb?
lnk=gst&q=custom+account#86d4d895e88a5ebb
developers/browse_thread/thread/6caa57135927e242/86d4d895e88a5ebb?
lnk=gst&q=custom+account#86d4d895e88a5ebb
el...@google.com
da...@google.com
ap...@google.com
My personal theory is that Google broke this part of the API intentionally to keep
the lock-in on sync functionality they've enjoyed since Android 1.0.....
the lock-in on sync functionality they've enjoyed since Android 1.0.....
da...@google.com
da...@google.com
[Comment deleted]
th...@gmail.com
da...@google.com
ExternalSource.java bug
protected void inflate(Context context, XmlPullParser parser)
{
final AttributeSet attrs = Xml.asAttributeSet(parser); << It can't read any
attributes from the ContactsDataKind tag. It should located blow the second while
loop.
try
{
int type;
while((type = parser.next()) != XmlPullParser.START_TAG &&
type != XmlPullParser.END_DOCUMENT)
{
// Drain comments and whitespace
}
if(type != XmlPullParser.START_TAG)
{
throw new IllegalStateException("No start tag found");
}
if(!InflateTags.CONTACTS_SOURCE.equals(parser.getName()))
{
throw new IllegalStateException("Top level element must be " +
InflateTags.CONTACTS_SOURCE);
}
protected void inflate(Context context, XmlPullParser parser)
{
final AttributeSet attrs = Xml.asAttributeSet(parser); << It can't read any
attributes from the ContactsDataKind tag. It should located blow the second while
loop.
try
{
int type;
while((type = parser.next()) != XmlPullParser.START_TAG &&
type != XmlPullParser.END_DOCUMENT)
{
// Drain comments and whitespace
}
if(type != XmlPullParser.START_TAG)
{
throw new IllegalStateException("No start tag found");
}
if(!InflateTags.CONTACTS_SOURCE.equals(parser.getName()))
{
throw new IllegalStateException("Top level element must be " +
InflateTags.CONTACTS_SOURCE);
}
ne...@gmail.com
Any feedback from Google guys?
It doesn't seem to be fixed in Android 2.2 and actually is going to be a blocking issue for third party sync providers. We cannot claim to sync contacts if the user cannot edit them.
Looking at the code, the fix is very easy (at least to let sync providers to use the same contact structure used by Google accounts).
Please let us know if and when you can work on this.
It doesn't seem to be fixed in Android 2.2 and actually is going to be a blocking issue for third party sync providers. We cannot claim to sync contacts if the user cannot edit them.
Looking at the code, the fix is very easy (at least to let sync providers to use the same contact structure used by Google accounts).
Please let us know if and when you can work on this.
yb...@google.com
Could anyone give an answer please?
In Android SDK 2.2 you added a beautiful example about how to create a Contacts Sync Adapter:
http://developer.android.com/resources/samples/SampleSyncAdapter/index.html
BTW if you see the sync adapter definition you realize that it doesn't support uploading, it means that all the contacts are not editable (the same as in Facebook accounts), is it casual???
Why did you do such a huge work, if you still have this kind of bugs?? I'm really start thinking the same as in comment 2.
In Android SDK 2.2 you added a beautiful example about how to create a Contacts Sync Adapter:
BTW if you see the sync adapter definition you realize that it doesn't support uploading, it means that all the contacts are not editable (the same as in Facebook accounts), is it casual???
Why did you do such a huge work, if you still have this kind of bugs?? I'm really start thinking the same as in comment 2.
be...@gmail.com
Days trying to figure out how the ContactsContract worked. Days doing code. Other team members spent more days doing the WebServices. More days changing the DB and adding more business logic in the server side. And in the last task, the easy one, building the contact fields in the UI... pufff. This is so disappointing.
I HAVE to find a workaround for this now.
I HAVE to find a workaround for this now.
Description
Component used: Room
Version used: 2.4.0-alpha04
Devices/Android versions reproduced on: Pixel 3a emulator
Description:
It's not uncommon to have an
idcolumn of every database entity. However, the code generated using the new JOIN feature introduced in Room 2.4.0 doesn't have the ability to distinguish betweenidcolumns from different entities, which can produce completely wrong results.I've attached a minimal working AS project. In this I've created a
Userand aUserCommentRoom entity and attempt to retrieve a list of all Users mapped to theirUserComments. But because both entities contain anid-column, Room gets confused and actually returns a list ofUsers with ids taken fromUserComment.As I understand it, differentiating columns with the same name is difficult for Room, but this issue makes the new feature much less useful and downright dangerous given how prevalent the name
idfor the column is.If it's not possible to fix it, perhaps the Room plugin could generate a warning or error if it picks up duplicate column names. As it stands, Room will just silently create faulty data.