Obsolete
Status Update
No update yet.
Comments
sa...@gmail.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
du...@gmail.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.....
jo...@gmail.com
[Comment deleted]
jo...@gmail.com
ot...@gmail.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);
}
sa...@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.
sa...@gmail.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.
ru...@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.
dp...@google.com
[Comment deleted]
dp...@google.com
[Comment deleted]
dp...@google.com
The "official" workaround is to stick an "Edit in AcmeContacts" line item in the data table and make it launch AcmeContacts, which would presumably offer a full editor (perhaps based on the open source one).
I know, it's severely suboptimal, but so far we have not been able to figure out any other comprehensive solution. In our experience, every contact source comes with its own set of unique features and constraints, so having a one-size-fits-all editor does not appear to be feasible. On the other hand, loading 3rd party code into the Contacts app to do "embedded editing" would present a challenge from the security perspective. :-(
We are very much open to suggestions.
And BTW, we certainly did not "intentionally keep the lock-in on sync functionality". Trust me on that one - I was there. We tried very hard to come up with the most open solution we could.
I know, it's severely suboptimal, but so far we have not been able to figure out any other comprehensive solution. In our experience, every contact source comes with its own set of unique features and constraints, so having a one-size-fits-all editor does not appear to be feasible. On the other hand, loading 3rd party code into the Contacts app to do "embedded editing" would present a challenge from the security perspective. :-(
We are very much open to suggestions.
And BTW, we certainly did not "intentionally keep the lock-in on sync functionality". Trust me on that one - I was there. We tried very hard to come up with the most open solution we could.
ru...@gmail.com
I really don't understand why this limitation in the UI. We already can do much more with code. We can insert all the data that we want; control aggregations; sniff other accounts (except the contacts marked as "restricted"). We can even run a little black box in the SyncManager slot... What's the harm of providing a mechanism to bind the data to the Activity components? It's not that we are adding anything new that isn't already running as a service in the account SyncAdapter.
Anyway, I don't quite understand your suggestion for the workaround. If I understood correctly, we can specify in the ContactsContract.Data which editor to launch for the edition and creation of a contact?! The Android Contacts application does that for us? Bypassing the Intent chooser? I didn't found anything that could do that (that was documented in the API). But, that would be a step up from were I am right now.
Anyway, I don't quite understand your suggestion for the workaround. If I understood correctly, we can specify in the ContactsContract.Data which editor to launch for the edition and creation of a contact?! The Android Contacts application does that for us? Bypassing the Intent chooser? I didn't found anything that could do that (that was documented in the API). But, that would be a step up from were I am right now.
m....@gmail.com
I have also deeply digged into the code to work around this problem and finally implemented my own edit screen (intercepting the edit intent). But there are many drawbacks in this approach and I would love if the bug could get fixed.
My guess is that everybody is using the standard contacts provider, so the standard address book is a good choice to view/edit these contacts. If an external account could use the standard edit (the one used for Google contacts), that would be a huge step forward.
The ability to specify what fields are supported via XML is yet another improvement. But IMHO not the first thing to do. As a first step it would be great to have the generic edit screen working for any account.
My guess is that everybody is using the standard contacts provider, so the standard address book is a good choice to view/edit these contacts. If an external account could use the standard edit (the one used for Google contacts), that would be a huge step forward.
The ability to specify what fields are supported via XML is yet another improvement. But IMHO not the first thing to do. As a first step it would be great to have the generic edit screen working for any account.
dp...@google.com
@rui.mtd.roque: I was talking about using the approach that the Facebook and Twitter sync adapters use to navigate from the Contacts app to their respective apps. They introduce a custom mime type, which is handled by their own activites. They insert a row for each of their RawContacts into the Data table with that mime type and that's the integration. As far as creating a new contact - perhaps intercepting the intent is the best way to go.
@m.garatti: the Google contact source is tailored to what GMail back end can hold. Should we assume that every sync adapter can handle all the same types of data as GMail Contacts with the same restrictions and nothing more? Sounds like too much for some and too little for others.
@m.garatti: the Google contact source is tailored to what GMail back end can hold. Should we assume that every sync adapter can handle all the same types of data as GMail Contacts with the same restrictions and nothing more? Sounds like too much for some and too little for others.
ar...@gmail.com
@dplotni...@google.com: If Google fixes this bug and allows non-Google contacts to be edited with the standard address book editor, at least it leave developers with a choice: (1) Use the standard editor and be limited to fields supported by Google contacts or (2) Use a custom editor for non-Google sync adaptors if the Google contacts fields don't suffice. Since the vast majority of contact fields in most systems are more or less the same (name, phone numbers, email addresses, etc.), choice #1 may make sense for many cases although in some specific case, choice #2 may be needed in which case the developer does get to choose which fields to display in the editor, but it also comes with many disadvantages.
dp...@google.com
My concern comes from the obvious expectation that Gmail Contacts are not going to remain the same in the future. I am sure GMail folks will add new data types, new subtypes, they will integrate with some Google systems etc. GoogleSource will need to track those changes. I don't think it's a good idea to impose the same on all sync adapters. I would much prefer for the custom editors to be totally independent. If somebody likes the "standard" editor - why not copy/paste it into their own app?
I think the focus should be on integration between the Contacts app and the 3rd party editors.
For editable sync adapters, we should probably do these things:
1. Do some UI clean up and make sure we properly display the "Edit in AcmeContacts" link in Contacts app editor.
2. If there is only one writable account, the New Contact intent should redirect to the app that owns that account.
3. If there are multiple writable accounts, the Contacts app shows a disambiguation dialog. We should change it to make sure that if the user selects a 3rd-party account from that dialog, we take them directly to that 3rd-party app.
I think the focus should be on integration between the Contacts app and the 3rd party editors.
For editable sync adapters, we should probably do these things:
1. Do some UI clean up and make sure we properly display the "Edit in AcmeContacts" link in Contacts app editor.
2. If there is only one writable account, the New Contact intent should redirect to the app that owns that account.
3. If there are multiple writable accounts, the Contacts app shows a disambiguation dialog. We should change it to make sure that if the user selects a 3rd-party account from that dialog, we take them directly to that 3rd-party app.
ha...@gmail.com
OP has it right:
"There ought, nay SHOULD, be a way to define a new account type and use the
"standard" layout as supplied by the system for unsynchronized
contacts/phone only - adding a new account type and sync adapter isn't
always about filling it to the brim with custom fields you know - it might
just be about synchronizing the fields. "
From an OS perspective yes you can think of all sorts of theoretical ways this might potentially cause some range of problems maybe in the future so-let's-not-deal-with-it. From a developer perspective it is disappointing that it was shipped broken in the first place and astonishing that it has still not been fixed.
A bunch of us have independently gone down this path and all have hit this same dead end. We also did this months and months ago when there was no sample code and precious little documentation. It basically took a weeks worth of effort to determine that a custom contact that wasn't the trivial social-network variety just wouldn't work as a customer facing solution.
Fix it.
"There ought, nay SHOULD, be a way to define a new account type and use the
"standard" layout as supplied by the system for unsynchronized
contacts/phone only - adding a new account type and sync adapter isn't
always about filling it to the brim with custom fields you know - it might
just be about synchronizing the fields. "
From an OS perspective yes you can think of all sorts of theoretical ways this might potentially cause some range of problems maybe in the future so-let's-not-deal-with-it. From a developer perspective it is disappointing that it was shipped broken in the first place and astonishing that it has still not been fixed.
A bunch of us have independently gone down this path and all have hit this same dead end. We also did this months and months ago when there was no sample code and precious little documentation. It basically took a weeks worth of effort to determine that a custom contact that wasn't the trivial social-network variety just wouldn't work as a customer facing solution.
Fix it.
m....@gmail.com
@dplotni: first of all thank you for your comments, very much appreciated. I see your point and it is great you are trying to provide such a generic mechanism. But honestly today the situation is very far from this. We are actually in a situation where third party apps cannot create read/write address books, because editing is not available. By providing the standard editor to all accounts, you are doing at least the first step, bringing Android at the same level of any other platform. This would probably make 90% of users/developers happy.
For a more generic solution, my suggestion would be to have a mechanism to customize the intent which is generated for editing contacts. Today the only intent I was able to intercept is the "edit contact" one. Therefore I have to show to the user a list of available accounts to let him choose the one he wants (at least for creating contacts). One possibility would be that the platform handles the account selection, and then generates a specific intent for editing the contact. This intent could be somehow specific for each account, so that it would be possible to customize the editing. If an account is not interested at handling the editing, then the intent for the standard editor would be generated.
For a more generic solution, my suggestion would be to have a mechanism to customize the intent which is generated for editing contacts. Today the only intent I was able to intercept is the "edit contact" one. Therefore I have to show to the user a list of available accounts to let him choose the one he wants (at least for creating contacts). One possibility would be that the platform handles the account selection, and then generates a specific intent for editing the contact. This intent could be somehow specific for each account, so that it would be possible to customize the editing. If an account is not interested at handling the editing, then the intent for the standard editor would be generated.
ha...@gmail.com
Native android contacts are not really 'gmail' contacts. They are gmail contacts that have been mapped to the ContactsContract domain. It's not a one to one mapping but it is close. Exchange contacts also map to this same domain in a very similar way (though not exactly).
The newer ContactsContract canonicalizes many aspects of native contacts. Some more work here would go a long way towards contact interoperability on the platform.
As a developer I want to be able to look into a raw contact and grab the entry's primary mobile phone number. I don't want to have to know what kind of contact that is in order to do that. Similarly I would like to add my own contact source and the contract simply needs to be that I adhere to a standard mapping.
It should also be noted that the built in contact viewer displays many of the fields that the editor does not.
The newer ContactsContract canonicalizes many aspects of native contacts. Some more work here would go a long way towards contact interoperability on the platform.
As a developer I want to be able to look into a raw contact and grab the entry's primary mobile phone number. I don't want to have to know what kind of contact that is in order to do that. Similarly I would like to add my own contact source and the contract simply needs to be that I adhere to a standard mapping.
It should also be noted that the built in contact viewer displays many of the fields that the editor does not.
dp...@google.com
@m.garatti: right back at you: I see your point.
How about beefing up the solution I outlined earlier with an option for the sync adapter to declare that it wants a "standard" editor. It shouldn't really be the Google editor for the reasons I mentioned, but it could be some sort of lowest common denominator editor that provides basic functionality for a bunch of common data types.
As far as the intent is concerned, we can use the contacts.xml file that comes with the sync adapter to declare a "create contacts" intent that should be used for accounts handled by the corresponding app - that should be sufficient.
How about beefing up the solution I outlined earlier with an option for the sync adapter to declare that it wants a "standard" editor. It shouldn't really be the Google editor for the reasons I mentioned, but it could be some sort of lowest common denominator editor that provides basic functionality for a bunch of common data types.
As far as the intent is concerned, we can use the contacts.xml file that comes with the sync adapter to declare a "create contacts" intent that should be used for accounts handled by the corresponding app - that should be sufficient.
m....@gmail.com
@dplotni: what you described sounds great! Please let us know any development or news on this subject. Thanks.
cc...@gmail.com
@dplotni: this sounds like a great stopgap and would save some bacon. Would it be available as contacts update on 2.1 ? Or only on 2.2+ ?
dp...@google.com
Contacts app is an embedded part of the system, so any changes in the app can only be done a future release of Android.
ar...@gmail.com
Isn't this [1] the Code which should read a XML description of an contact edit form?
"In the future this may be inflated from XML defined by a data source.", but when will the future start?
I can't find this file in the current sources.
[1]http://www.google.com/codesearch/p?hl=de#J8HqCFe1rOo/src/com/android/contacts/model/ContactsSource.java&q=ContactsSource&sa=N&cd=1&ct=rc (also in Attachment)
"In the future this may be inflated from XML defined by a data source.", but when will the future start?
I can't find this file in the current sources.
[1]
ms...@gmail.com
Could we make ContactsSource.java part of the framework and have people implement what they need to much like GoogleSource, then potentially have the manifest point to this class definition so that it can be loaded by Sources.java or something to that effect? Not sure if it's possible, but it almost seems like we could do the same thing we're doing with the XML for the actual class implementation as well.
ms...@gmail.com
Just read the idea about the customized intent -- that sounds like it could work. Might take a bit to make it work with the current EditContactActivity, though.
ni...@gmail.com
This is a big limitation for Sync adpater deployment.
I Hope that Google team will fix that as soon as possible.
I Hope that Google team will fix that as soon as possible.
mi...@gmail.com
well we are facing the same broken api, but right now , we are trying not to used the sync feature just to add accounts but it seems that they are both tied to work, i also made it to a Phone Unsynchronized , but i guess some devices(and future ones) will have problems displaying it in their native phone books, Unless you have a very fine call of ACTION_VIEW
ma...@googlemail.com
this not a solution but merely a work-around:
to give users of my CardDav-Sync adapter the ability to edit the synced contacts, I grabbed the default editor from the 2.1 sources, fixed it to work with arbitrary contacts (by copying the editor for Google contacts) and removed most dependencies on the internal API to make it work with FroYo. It is reported to work with 2.1 and 2.2 and available at the market under org.dmfs.android.contacts.
to give users of my CardDav-Sync adapter the ability to edit the synced contacts, I grabbed the default editor from the 2.1 sources, fixed it to work with arbitrary contacts (by copying the editor for Google contacts) and removed most dependencies on the internal API to make it work with FroYo. It is reported to work with 2.1 and 2.2 and available at the market under org.dmfs.android.contacts.
ma...@googlemail.com
sorry, the correct link to the editor is
market://search?q=pname:org.dmfs.android.contacts
market://search?q=pname:org.dmfs.android.contacts
er...@gmail.com
can we get the source of your changes, maybe we can build version for 2.3, too
because i'm 100% sure, that a fix from google will need another 1 year :(
so, we must do this for now by ourself ...
because i'm 100% sure, that a fix from google will need another 1 year :(
so, we must do this for now by ourself ...
ma...@googlemail.com
It seems to work fine in the 2.3 and 3.0 emulator as well. And I haven't gotten any bug reports from 2.3 or Honeycomb users so far.
vs...@gmail.com
Hi, I've developed my own editor and linked a mimetype entry as advised above. pressing it invokes my editor and works as expected. Now the last point would be somehow getting when a contact has been created so I can insert my custom field in the RawContact entry. Unfortunately the contact creation is invoked by an explicit itntent (Android 2.1) and I have no way to get hold of it. Since people seem to have managed this what are the steps to do this?
ma...@googlemail.com
[Comment deleted]
ma...@googlemail.com
The intent filter for inserting contact looks like (from the stock editor)
<intent-filter android:label="@string/insertContactDescription">
<action android:name="android.intent.action.INSERT" />
<category android:name="android.intent.category.DEFAULT" />
<data android:mimeType="vnd.android.cursor.dir/person" />
<data android:mimeType="vnd.android.cursor.dir/contact" />
<data android:mimeType="vnd.android.cursor.dir/raw_contact" />
</intent-filter>
Of course you can add/replace your own mime-type but no app will ever call your editor with this mime-type, because they just don't know about it.
So your app has to handle contact creation requests for other accounts as well.
The stock editor handles this by showing a list of available accounts (including accounts that do not provide contacts, which is a bug obviously) and the user can select under which account the contact shall be created.
Motoblur seems to handle this by creating the contact under every available account. There is a global option to select the accounts you want, but you can not choose at creation time.
<intent-filter android:label="@string/insertContactDescription">
<action android:name="android.intent.action.INSERT" />
<category android:name="android.intent.category.DEFAULT" />
<data android:mimeType="vnd.android.cursor.dir/person" />
<data android:mimeType="vnd.android.cursor.dir/contact" />
<data android:mimeType="vnd.android.cursor.dir/raw_contact" />
</intent-filter>
Of course you can add/replace your own mime-type but no app will ever call your editor with this mime-type, because they just don't know about it.
So your app has to handle contact creation requests for other accounts as well.
The stock editor handles this by showing a list of available accounts (including accounts that do not provide contacts, which is a bug obviously) and the user can select under which account the contact shall be created.
Motoblur seems to handle this by creating the contact under every available account. There is a global option to select the accounts you want, but you can not choose at creation time.
vs...@gmail.com
That did the trick thank you a lot for your help (it looks like I should have looked for the source code before thinking it was using an explicit intent).
ma...@gmail.com
is it possible to use my editor only when i'm trying to edit contact from my custom account? the other contacts i want to edit with default editor. i mean without anoying "Complete action using" screen.
[Deleted User] <[Deleted User]>
[Comment deleted]
ky...@gmail.com
Is this fixed? I'm not seeing anything obvious that points at how to do this.
ga...@gmail.com
As the developer of Enhanced Email I too would like to see this get some attention. I'd prefer not bundling the stock contact editor and balloon up the size of my app for something that should be doable in the framework.
tg...@gmail.com
Please fix this!
de...@gmail.com
Hi Guys, this is affecting the dev from the app enhanced email
su...@gmail.com
A fix at the earliest please.
ce...@gmail.com
Need a fix ASAP!
ra...@gmail.com
It is 2013, Android 4.2 is out, and this still isn't fixed. Come on guys, please fix this issue!
ma...@googlemail.com
FYI: this has been fixed some time ago in 4.0. All you have to do is to include a contact definition xml. That works on all 4.x devices without HTC Sense, see http://dmfs.org/wiki/index.php?title=HTC_Sense_issue
ga...@gmail.com
#47 Can you paste a sample "ContactsSource" xml file where all fields are supported? Perhaps on pastebin so we can all see?
ga...@gmail.com
Disregard my
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android-apps/4.0.4_r1.2/packages/apps/Contacts/tests/res/xml/test_basic_contacts.xml?av=f
So for any other devs wanting to do this check that file for what to include in your definition file. I've verified it works.
So for any other devs wanting to do this check that file for what to include in your definition file. I've verified it works.
ad...@gmail.com
Looking forward to this getting fixed! Please!
ro...@gmail.com
Looking forward to this getting fixed! Please!
rs...@gmail.com
Looking forward to this getting fixed! Please!
ma...@gmail.com
Lamenting the lack of fix for this problem.
ar...@gmail.com
#41 #42 #43 #44 #45 #46 #50 #51 #52 #53 just star the issue and stop spamming mine and 85 other people's inboxes
ar...@gmail.com
Guys, this is a bug, not an enhancement. If this is fixed in 4.2.2 then it should be backported to 4.1.x releases, if backportable. I don't know how Google Dev works, but at Oracle we should just file a backport request for the particular fix and that would be all...
Can somebody file this backport request bug?
Can somebody file this backport request bug?
ma...@googlemail.com
This issue was fixed long ago in 4.0.3 and it works on all newer Android versions (except on HTC devices, see my link above). The only issue left is the lack of documentation.
ar...@gmail.com
You are right, wrong bug comment. This should go to the settings loss after restart jelly bean issue
jb...@android.com
rw...@gmail.com
Seriously though why are we still having to deal with this
sa...@google.com
Thank you for the feedback. We're closing this issue as Obsolete.
If it is still observed in the latest Android release, please open a new issue inhttps://goo.gl/TbMiIO along with a reference to this issue.
If it is still observed in the latest Android release, please open a new issue in
Description
--
Android 2.0.1 SDK
Steps to reproduce the problem:
--
1. Implement a SyncAdapter implementation for the com.android.contacts
authority. Use a custom account type, e.g. some.account.type.
2. Add an account in the Contacts app.
3. Attempt to add or edit a contact in this account.
4. Behold the barren UI.
5. Lament at the barren UI.
6. Search for documentation.
7. More lamenting.
8. Find Sources.java in the Contacts app.
9. Behold the apparent silliness, for lo, it has special treatment for
Google and Exchange account types, your stuck with ExternalSource.java.
Dogfooding indeed.
10. Lament the lack of dogfooding, for it produces sloppy code.
11. Inspect ExternalSource.java.
12. There appears to be a comment missing in this file. I suggest "There be
dragons".
13. On row 98 we see the reaction to an undefined contacts layout - it just
plops up the photo and name, discarding the fully functional implementation
supplied by the superclass.
14. More lamenting. But you're probably getting used to this.
What happened
--
Anger. Disappointment. Pointless XML files added to projects across the world.
What you think the correct behavior should be.
--
There ought, nay SHOULD, be a way to define a new account type and use the
"standard" layout as supplied by the system for unsynchronized
contacts/phone only - adding a new account type and sync adapter isn't
always about filling it to the brim with custom fields you know - it might
just be about synchronizing the fields.