Obsolete
Status Update
Comments
ro...@gmail.com <ro...@gmail.com> #2
I guess hidden should just be defined. Meaning, right now, hidden should just defined as "whether this fragment was hidden as part of a transaction". Hidden is not equivalent with visibility. I think that's where the confusion comes from.
pe...@gmail.com <pe...@gmail.com> #3
We have passed this to the development team and will update this issue with more information as it becomes available.
el...@gmail.com <el...@gmail.com> #4
Yeah, I'm seeing this issue as well, currently this is the workaround that I've come up with:
// This method is called when hide()/show() methods are called on the transaction. Unfortunately Android doesn't
// propagate it to the child fragments (even though their visibility is affected by the parent visibility), so we
// do it manually.
override fun onHiddenChanged(hidden: Boolean) {
super.onHiddenChanged(hidden)
childFragmentManager.fragments.forEach { it.onHiddenChanged(hidden) }
}
// This method is called when hide()/show() methods are called on the transaction. Unfortunately Android doesn't
// propagate it to the child fragments (even though their visibility is affected by the parent visibility), so we
// do it manually.
override fun onHiddenChanged(hidden: Boolean) {
super.onHiddenChanged(hidden)
childFragmentManager.fragments.forEach { it.onHiddenChanged(hidden) }
}
ca...@gmail.com <ca...@gmail.com> #5
@4 That actually won't technically fix as isHidden() will technically mismatch with the state passed into the child fragment. Each child fragment legitimately needs to have their state set to hidden.
hi...@gmail.com <hi...@gmail.com> #6
Yeah, I realized that as I kept working further on it. Nevermind that solution, it doesn't work.
aw...@googlemail.com <aw...@googlemail.com> #7
@6 I don't know what the ramifications are, but when you iterate, you can save the "currentState" and then hide them all via a transaction. When restoring to visible, restore to the original state.
aw...@googlemail.com <aw...@googlemail.com> #8
Project: platform/frameworks/support
Branch: androidx-main
commit 02290cddca3d5e4dc94e2c5f77a6728ad970b204
Author: Jeremy Woods <jbwoods@google.com>
Date: Thu Oct 07 13:11:45 2021
Dispatch onHiddenChanged to child fragments
When a parent fragment is hidden all of its children will automatically
be hidden, but we never call onHiddenChanged on any of the children.
We should dispatch onHiddenChanged down parent's entire hierarchy and
ensure that `isHidden()` also considers the parent's state.
RelNote: "Parent fragments will now dispatch `onHiddenChanged()` down
their entire hierarchy before launching their own call back."
Test: added test
Bug: 77504618
Change-Id: Iedc201ab435cb963e81bc02d203d4d37ff827e01
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentViewTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
https://android-review.googlesource.com/1850016
Branch: androidx-main
commit 02290cddca3d5e4dc94e2c5f77a6728ad970b204
Author: Jeremy Woods <jbwoods@google.com>
Date: Thu Oct 07 13:11:45 2021
Dispatch onHiddenChanged to child fragments
When a parent fragment is hidden all of its children will automatically
be hidden, but we never call onHiddenChanged on any of the children.
We should dispatch onHiddenChanged down parent's entire hierarchy and
ensure that `isHidden()` also considers the parent's state.
RelNote: "Parent fragments will now dispatch `onHiddenChanged()` down
their entire hierarchy before launching their own call back."
Test: added test
Bug: 77504618
Change-Id: Iedc201ab435cb963e81bc02d203d4d37ff827e01
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentViewTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
a....@aarboard.ch <a....@aarboard.ch> #9
This has been fixed internally and will be available in the Fragment 1.4.0-beta01
release.
a....@aarboard.ch <a....@aarboard.ch> #10
iPhone has CardDav and CalDav support since at least iOS3
ro...@gmail.com <ro...@gmail.com> #11
Actually, CardDAV is new to iOS4, it wasn't present in prior versions. CalDAV was however in there.
Regardless - Android needs this now!!
Regardless - Android needs this now!!
by...@gmail.com <by...@gmail.com> #12
Yeah be sure to star issue 36907451 too. Not like it will make a difference at this point, but hey.
we...@gmail.com <we...@gmail.com> #13
we definitly need caldav + carddav or I go back to my iphone ..
ma...@gtempaccount.com <ma...@gtempaccount.com> #14
Critical for business use
be...@gmail.com <be...@gmail.com> #15
Think google wants us to develop this feature. As with every service on Android, Google provides the backend and a minimal example frontend. (Except browser?) So who is willing to code this absolutely necessary feature?
I hope I will have some time to look into this next month. (If it isn't fixed till then, which I would prefer.) Who is with me? Write me a mail:
mail @tbenjamin-behringer.de
I hope I will have some time to look into this next month. (If it isn't fixed till then, which I would prefer.) Who is with me? Write me a mail:
mail @t
an...@gmail.com <an...@gmail.com> #16
CalDAV is supported, search for CalDAV in the market. It works pretty good for me so far. See also: http://www.hypermatix.com/products/calendar_sync_for_android
pa...@gmail.com <pa...@gmail.com> #17
Google, if you want to compete with the iPhone and gain some additional market share, CalDAv and CardDAV are a must.
by...@gmail.com <by...@gmail.com> #18
Does anyone know of a project already underway to implement CardDAV on Android? Something we could contribute to maybe? Looking at the the list of issues in Android as a whole, top issues with >1000 stars have not even been reviewed by Google. I wouldn't hold your breath waiting for this issue (currently 65 stars) to get any attention. There is a CalDAV app out there, if we get a CardDAV one as well then we can stop waiting on Google.
lo...@googlemail.com <lo...@googlemail.com> #19
there is already a GPLed (C) lib: libcarddav ( http://trinity.pearsoncomputing.net/related_projects/libcarddav/ ), I'm currently playing with it on FreeBSD, seems to work niceley. Somebody with some Android experience should get something working quite easiley
no...@gmail.com <no...@gmail.com> #20
CardDAV and CalDAV are must for android. Please!
pg...@gmail.com <pg...@gmail.com> #21
Caldal & carddav is à minimum if you want your phone to be used in enterprise.. PLEASE add this protocol!
by...@gmail.com <by...@gmail.com> #22
[Comment deleted]
by...@gmail.com <by...@gmail.com> #23
Just found this: http://dmfs.org/carddav/?home
It's force-closing on my EVO, but it might work on your phone. Either way, you might want to support this developer or submit bugs, etc.
It's force-closing on my EVO, but it might work on your phone. Either way, you might want to support this developer or submit bugs, etc.
by...@gmail.com <by...@gmail.com> #24
This doesn't force close anymore, you just need to avoid spaces in the account name during setup. It's still only one-way, but working great! Finally I can stop watching this ignored thread.
si...@gmail.com <si...@gmail.com> #25
Weird. I somewhat was under the impression Android already has builtin support for Caldav & Carddav. Reading that it still is missing makes me reconsider if I should by a Nexus or iPhone.
ro...@gmail.com <ro...@gmail.com> #26
seigfried - a similar technology is built-in, for Google Accounts, but not for any other server.
It's like the equivalent of having Gmail only on a phone, and no support for any other POP/IMAP services...
It's like the equivalent of having Gmail only on a phone, and no support for any other POP/IMAP services...
si...@gmail.com <si...@gmail.com> #27
Thanks for clarifying. But I do not want to use my Google account to sync business related data. On an iPhone I dom't need an Apple account to access Caldav & Carddav based servers...
ro...@gmail.com <ro...@gmail.com> #28
Same here. I use an iPhone for work email, as it's still a superior mail application, as well as syncing calendars and address books to the company server. Oh, I use the iPhone for picture taking more too, even with the 5MP camera on it (versus my Android's 8MP), the HDR feature takes a superior photograph.
I use an Android as well, mostly for searching and navigation, as Android blows the doors off any competition in that area.
I'm hoping to carry just one device at some point though.
I use an Android as well, mostly for searching and navigation, as Android blows the doors off any competition in that area.
I'm hoping to carry just one device at some point though.
he...@gmail.com <he...@gmail.com> #30
I think the problem is that nobody has yet coded a robust solution for this problem. The API for it is in place and an app exists, but it is not stable. This feature does not necessarily need to be in the core OS.
Let's hope it all works out eventually.
Let's hope it all works out eventually.
si...@gmail.com <si...@gmail.com> #31
Don't get me wrong on this. I don't want to start a flamewar. I just compare features of my more than two years old iPhone 3G with a current Android system like the Nexus S.
While Apple didn't ship Caldav & Carddav with my old device they released iOS 3 about two years ago adding native OS support. I'm sure they didn't do it just for fun but rather because customer were asking for it.
IMHO if I buy a rather expensive business Android smartphone nowadays I expect it to support open standards, especially since the device OS is open source itself.
I don't want to start messing with third-party SW just for basic features competitor devices already have implemented for years. Instead I expect to unbox the device and start using it with at least POP3/IMAP/LDAP, iCAL and Caldav & Carddav and no Google account.
It's just that simple..
While Apple didn't ship Caldav & Carddav with my old device they released iOS 3 about two years ago adding native OS support. I'm sure they didn't do it just for fun but rather because customer were asking for it.
IMHO if I buy a rather expensive business Android smartphone nowadays I expect it to support open standards, especially since the device OS is open source itself.
I don't want to start messing with third-party SW just for basic features competitor devices already have implemented for years. Instead I expect to unbox the device and start using it with at least POP3/IMAP/LDAP, iCAL and Caldav & Carddav and no Google account.
It's just that simple..
ni...@gmail.com <ni...@gmail.com> #32
@heller, nobody coded it yet. But it would be peanuts for google to implement it and they would probably profit from more business users. But: they did not implement it over years. They even removed the possibility of a not-google-synced native local calendar on android phones!
The only explanation for this is that the interest of forcing people into google accounts is bigger than investing in open standards.
This is sad. As a privacy aware smartphone user who wants to sync his contacts and calenders with his own server, or keep them local, an iphone will be my next phone. After years of android usage and confidence that it can't take more than 3 month for google or the community to implement native caldav and carddav sync...
The only explanation for this is that the interest of forcing people into google accounts is bigger than investing in open standards.
This is sad. As a privacy aware smartphone user who wants to sync his contacts and calenders with his own server, or keep them local, an iphone will be my next phone. After years of android usage and confidence that it can't take more than 3 month for google or the community to implement native caldav and carddav sync...
he...@gmail.com <he...@gmail.com> #33
@siegfried I completely agree that android devices should support this out of the box. I simply wanted to point out that the API is in place for extra data providers.
I am also not trying to start a flamewar :-)
Also: how widely is carddav/caldav used (except by devs/programmers)? I have no idea, can someone enlighten me?
I am also not trying to start a flamewar :-)
Also: how widely is carddav/caldav used (except by devs/programmers)? I have no idea, can someone enlighten me?
ni...@gmail.com <ni...@gmail.com> #34
hard to measure. A caldav feature request has 1700+ stars.
he...@gmail.com <he...@gmail.com> #35
@nilsjan fair enough. As I said, I agree that it should be on every Android phone.
on the not-google-synced native local calendar that got chucked: That is truly, very annoying!
Yes, I am aware of that caldav feature request, but frankly, a bugtracker probably isn't the right place to get statistics for the everyday userbase. No offense.
on the other hand: is an iPhone really better? :D
The problem is that it's apparently not top priority for google. instead of everyone complaining, maybe someone should provide a patch. I tried, but I definitely need more experience under my belt.
on the not-google-synced native local calendar that got chucked: That is truly, very annoying!
Yes, I am aware of that caldav feature request, but frankly, a bugtracker probably isn't the right place to get statistics for the everyday userbase. No offense.
on the other hand: is an iPhone really better? :D
The problem is that it's apparently not top priority for google. instead of everyone complaining, maybe someone should provide a patch. I tried, but I definitely need more experience under my belt.
ma...@googlemail.com <ma...@googlemail.com> #36
When I bought my first Android phone last September I was (like all of you) quite disappointed about the missing CalDAV/CardDAV support.
In February I decided to start my own sync-adapter. You may have heard about it. It is called CardDAV-Sync and in April I started with CalDAV-Sync. Both sync Android's native address books/calendars the way it's meant to be (see the screenshots).
One of the major reasons the Apps are still beta and alpha is that I have to deal with many broken server implementations. It seems like most CalDAV/CardDAV servers are targeted to work with iToys.
While Apple can be sure that most developers will test their CalDAV/CardDAV implementation with iToys, Google would have make sure their implementation works with all those broken server from the start. That is a tough job, believe me.
Besides, from the ratings and comments you can see that my Apps do a good job ;-)
In February I decided to start my own sync-adapter. You may have heard about it. It is called CardDAV-Sync and in April I started with CalDAV-Sync. Both sync Android's native address books/calendars the way it's meant to be (see the screenshots).
One of the major reasons the Apps are still beta and alpha is that I have to deal with many broken server implementations. It seems like most CalDAV/CardDAV servers are targeted to work with iToys.
While Apple can be sure that most developers will test their CalDAV/CardDAV implementation with iToys, Google would have make sure their implementation works with all those broken server from the start. That is a tough job, believe me.
Besides, from the ratings and comments you can see that my Apps do a good job ;-)
ni...@gmail.com <ni...@gmail.com> #37
marten, does CalDAV-sync work without a google account? because on my device i can not create a calender without a google account...
ho...@gmail.com <ho...@gmail.com> #38
That's one of those areas where the API is NOT in place. You can't create multiple calendars even with a google account. There's one local+one per google account, which is quite utterly useless no matter what 3rd party software does.
ma...@googlemail.com <ma...@googlemail.com> #39
If your phone's manufacturer didn't mess up things completely: It totally does.
It creates a new calendar account with all calendars found on your CalDAV-account. See the screenshots at the market, there is no Google account. As I write it's implemented as a native sync-adapter.
The API it not public (yet), but that didn't keep me from using it anyway. So far it seems to work...
It creates a new calendar account with all calendars found on your CalDAV-account. See the screenshots at the market, there is no Google account. As I write it's implemented as a native sync-adapter.
The API it not public (yet), but that didn't keep me from using it anyway. So far it seems to work...
ba...@live.com <ba...@live.com> #40
#26
#31
'Do not trust google with my information'
I have not added a gmail account to my phone -- business reasons, too. I don't trust them with personal information either. None of my hats are comprised of tinfoil.
#32
> how widely caldav
Is yahoo calendar wide enough?
...
For most uses other than yahoo calendars implementation of CalDav there is:
aCal
http://f-droid.org/repository/browse/?fdid=com.morphoss.acal
HTH
#31
'Do not trust google with my information'
I have not added a gmail account to my phone -- business reasons, too. I don't trust them with personal information either. None of my hats are comprised of tinfoil.
#32
> how widely caldav
Is yahoo calendar wide enough?
...
For most uses other than yahoo calendars implementation of CalDav there is:
aCal
HTH
ba...@live.com <ba...@live.com> #42
Alternatives to spoon feeding your calendared life to google
Funambol (free)
http://f-droid.org/repository/browse/?fdid=com.funambol.androidsync
Hotmail live ActiveSync (free)
http://windowsteamblog.com/windows_live/b/windowslive/archive/2010/08/30/hotmail-now-supports-push-email-calendar-and-contacts-with-exchange-activesync.aspx
And more
https://wiki.mozilla.org/Calendar:QA_CalDAV_Support
Hope this helps liberate many from google data mining
Funambol (free)
Hotmail live ActiveSync (free)
And more
Hope this helps liberate many from google data mining
he...@gmail.com <he...@gmail.com> #43
#39,#40
very interesting. good to know :)
#41
spoon feeding it to microsoft is better? ;)
thanks for the info
very interesting. good to know :)
#41
spoon feeding it to microsoft is better? ;)
thanks for the info
an...@gmail.com <an...@gmail.com> #44
@36 I can confirm that martens application (CardDAV and CalDAV) work without a Google account. Check the apps in the market: https://market.android.com/developer?pub=dmfs
It's amazing what this guy did in recovering the calendars names and even the colors of the iCal calendars on my Mac. I don't care, if a software is out of the box, as long as there is a good app to cover my needs.
It's amazing what this guy did in recovering the calendars names and even the colors of the iCal calendars on my Mac. I don't care, if a software is out of the box, as long as there is a good app to cover my needs.
ch...@gmail.com <ch...@gmail.com> #45
I'm also really satisfied with the two sync apps from Marten...
http://dmfs.org/caldav/
http://dmfs.org/carddav/
/Christian
/Christian
ba...@live.com <ba...@live.com> #46
#42
Google's first order of business is selling- and showing ads. Microsoft's is not.
Yes, Microsoft is orders of magnitude less bad.
Google's first order of business is selling- and showing ads. Microsoft's is not.
Yes, Microsoft is orders of magnitude less bad.
ni...@gmail.com <ni...@gmail.com> #47
marten, when will caldav- and carddav-sync approximately go open source?
ma...@googlemail.com <ma...@googlemail.com> #48
Nils, I don't have a time line. I'll open it step by step whenever I think a lib is good enough (i.e. its interface is stable and it meets own my quality requirements)
ma...@gmail.com <ma...@gmail.com> #49
[Comment deleted]
ma...@gmail.com <ma...@gmail.com> #50
(sorry, for the previous post ... note for myself: don't write comments on issue trackers, when in hurry) Marten, if you plan to open up the code eventually, then I think you have it other way around ... first open the code and then work on making it good (and good enough for commercial sale).
If you'd put the code somewhere even in the current state, I'd be willing to help with QAing, testing, maybe even a patch could come, but when it is not FLOSS I don't have enough faith in you, that you won't come away in the moment my work starts to depend on your plugins.
And you don't have to give up on the commercial sale ... e.g., open just the source code without .apk, so only geeks will be able to use it. I think most of the “normal people” browser through the market anyway.
If you'd put the code somewhere even in the current state, I'd be willing to help with QAing, testing, maybe even a patch could come, but when it is not FLOSS I don't have enough faith in you, that you won't come away in the moment my work starts to depend on your plugins.
And you don't have to give up on the commercial sale ... e.g., open just the source code without .apk, so only geeks will be able to use it. I think most of the “normal people” browser through the market anyway.
la...@gmail.com <la...@gmail.com> #51
Where's the +1 Button for matej.cepl?
I'm be interested in helping with development whenever i can spare some time (which isn't the case very often, but hey!).
I'm be interested in helping with development whenever i can spare some time (which isn't the case very often, but hey!).
ma...@googlemail.com <ma...@googlemail.com> #52
Hi Guys,
thanks for your interest in my app. I completely understand you, but I've a very good reason to keep the sources closed for now. That is: Quality.
I'm a freelancer. Android development currently has a share of about 15-20% of my income, and I have to work for other customers as well (I could not live from what the apps return).
To get good jobs I have to show that I can deliver quality software.
How do you rate the quality of a closed source app? By how it works.
And although my apps are currently in beta, I think they work quite well (and as you can see by the comments, my users think so too)
How do you rate the quality of an open source app? By its source code!
Currently, the sources of my apps are a mess. When I started with CardDAV-Sync and CalDAV-Sync I had no idea of Android development, vcards, ics files or *DAV at all. And the last time I coded in Java was when Java 1.1 was state of the art.
Until now my focus was on the features and bug fixes not on the architecture. I wanted a working solution and I wanted it quickly. Of course I've learned a lot about Android and *DAV during development. Nowadays I would do many things completely different. So, I've started to refactor several parts and I'll release them open source when they meet my own quality requirements (and leave no doubt, that I'm really good at what I'm doing ;-) )
I hope you can understand my point.
cheers
Marten
thanks for your interest in my app. I completely understand you, but I've a very good reason to keep the sources closed for now. That is: Quality.
I'm a freelancer. Android development currently has a share of about 15-20% of my income, and I have to work for other customers as well (I could not live from what the apps return).
To get good jobs I have to show that I can deliver quality software.
How do you rate the quality of a closed source app? By how it works.
And although my apps are currently in beta, I think they work quite well (and as you can see by the comments, my users think so too)
How do you rate the quality of an open source app? By its source code!
Currently, the sources of my apps are a mess. When I started with CardDAV-Sync and CalDAV-Sync I had no idea of Android development, vcards, ics files or *DAV at all. And the last time I coded in Java was when Java 1.1 was state of the art.
Until now my focus was on the features and bug fixes not on the architecture. I wanted a working solution and I wanted it quickly. Of course I've learned a lot about Android and *DAV during development. Nowadays I would do many things completely different. So, I've started to refactor several parts and I'll release them open source when they meet my own quality requirements (and leave no doubt, that I'm really good at what I'm doing ;-) )
I hope you can understand my point.
cheers
Marten
ma...@gmail.com <ma...@gmail.com> #53
I understand your point, but I don't agree with it. Any potential customer who is able to judge the quality of programmer by looking at the code (and how many of them are such), will have enough smarts to recognize good programmer even in the code where he obviously is a bit lost in the actual programming language or the underlying technology.
And yes, my current employer (Red Hat) is probably a bit weird, but I know that leading an open source project with active users (and even if possible active contributors) is way more important than the beauty of the code. Leadership, willingness to communicate with customers (aka users), testing of the program, is much more important than the platonic beauty of the source code.
And yes, my current employer (Red Hat) is probably a bit weird, but I know that leading an open source project with active users (and even if possible active contributors) is way more important than the beauty of the code. Leadership, willingness to communicate with customers (aka users), testing of the program, is much more important than the platonic beauty of the source code.
ma...@gmail.com <ma...@gmail.com> #54
and of course, I don't want to imply that you would have to agree with me or something. just my rhoughts out of my whatwver.
[Deleted User] <[Deleted User]> #55
[Comment deleted]
an...@gmail.com <an...@gmail.com> #56
Please add CalDAV and CardDAV native support on Android.
da...@gmail.com <da...@gmail.com> #57
CalDAV-sync and CardDAV-sync (referenced in comment 44) in the market are completely satisfactory implementations of this. In reality Google could just buy the developer's time to get longish term support and make them the official solution.
pi...@gmail.com <pi...@gmail.com> #58
If Google and other smartphone producers intend to acquire iPhone users CalDAV/CardDAV Sync is a must have option. I came from an iPhone but I use only Mac at home with iCloud sync (all my contacts and calendar are here) and not all people that have an iCloud account can use CalDAV/CardDAV sync from Google Play (and the iCloud certified version is not free) to use it's new device.
It's absurd that now Gmail and Google Calendar support CardDAV and CalDAV for iPhone users but Android users can't connect to this open solution. Please add CalDAV and CardDAV in 4.2 or 4.1.2 version of Android...
It's absurd that now Gmail and Google Calendar support CardDAV and CalDAV for iPhone users but Android users can't connect to this open solution. Please add CalDAV and CardDAV in 4.2 or 4.1.2 version of Android...
mi...@gmail.com <mi...@gmail.com> #59
I don't have permission from my contacts to export their information outside the country to Google's servers. Is there any way to use an Android address book and not violate my own privacy policies?
ms...@gmail.com <ms...@gmail.com> #60
Agreed - google should simply pay the devs a lump sum and implement it in the OS. DAV support is critical for business use and really no different than wanting to use your own email and/or webservers.
in...@gmail.com <in...@gmail.com> #61
I am just happy that I made apparently the right decision more than a year ago to opt in on iPhone rather than Android. I am running my own groupware server and can connect to any desktop pc, Apple Mac and Linux computer. Still just not android.
I have been following this discussion for almost two years now and it's rather pathetic how google is still trying to push users into their calendar and contact solution rather than offering open standards.
On my phone as well as on my Linux desktop pc I can now have all my private caldav calendars side by side in a single application with my scouts google calendars and Facebook events.
Something that I have not yet seen on android.
The same applies to contacts. And reminders/todos.
As long as such things are not possible on Android, there is absolutely no incentive whatsoever to change to a shiny galaxy 3s.
I have been following this discussion for almost two years now and it's rather pathetic how google is still trying to push users into their calendar and contact solution rather than offering open standards.
On my phone as well as on my Linux desktop pc I can now have all my private caldav calendars side by side in a single application with my scouts google calendars and Facebook events.
Something that I have not yet seen on android.
The same applies to contacts. And reminders/todos.
As long as such things are not possible on Android, there is absolutely no incentive whatsoever to change to a shiny galaxy 3s.
da...@gtempaccount.com <da...@gtempaccount.com> #62
There is an app that you can install that does this beautifully. Please stop spamming the ticket, it won't help this become pre-installed functionality.
in...@gmail.com <in...@gmail.com> #63
If there is an app, why do we need this ticket?
The point is exactly that this should not be an app.
The age of the ticket however indicates to me that google is simply not interested in providing an integrated functionality.
The point is exactly that this should not be an app.
The age of the ticket however indicates to me that google is simply not interested in providing an integrated functionality.
mi...@gmail.com <mi...@gmail.com> #64
There is no app. To the best of my knowledge, at this point, there is no CardDAV support, merely a way to sync your CardDAV contacts into Google. This doesn't keep your private information private, is not competitive with features from Apple or even RIM's Playbook(?!), and is not good enough for my business or the businesses I work with.
la...@gmail.com <la...@gmail.com> #65
I'm still waiting for the builtin carddav support in android os. There is few apps on the market, but they doesnt have full support.
ma...@gmail.com <ma...@gmail.com> #66
Please add CalDAV, CardDAV as a native protocol on Android.
iOS 1 - Android 0
iOS 1 - Android 0
jy...@gmail.com <jy...@gmail.com> #67
Seeing that Google is removing exchange access from January 2013 ; accessing your calendar will now require CardDAV... So, maybe it's a good time for google to proprose this service in all Android device !
si...@gmail.com <si...@gmail.com> #68
[Comment deleted]
ga...@gmail.com <ga...@gmail.com> #70
If Google doesn't add CardDAV, I can't invest more in Android phones for my company. May I come back tom Blackberry 10...?
en...@google.com <en...@google.com>
na...@gmail.com <na...@gmail.com> #71
Google needs to add CardDAV and CalDAV support just like Apple does have on iOS
ao...@gmail.com <ao...@gmail.com> #72
Mar 15, 2015 -> marked as: Status: Won't Fix (Obsolete)
Google does not care at all about open standards, they just care about being able to milk the cow. See how in any release they make it harder to avoid "their ways": try to turn a default privacy-related setting off? you'll be asked and reminded every single time until you click on the wrong button (and then never again), or be warned every time that "this may break your setup" etc.
Neither does Apple care, actually, but Apple users are "caught" anyways...
Google does not care at all about open standards, they just care about being able to milk the cow. See how in any release they make it harder to avoid "their ways": try to turn a default privacy-related setting off? you'll be asked and reminded every single time until you click on the wrong button (and then never again), or be warned every time that "this may break your setup" etc.
Neither does Apple care, actually, but Apple users are "caught" anyways...
Description
CalDAV, but that's got it's own issue).
"CardDAV is an address book client/server protocol designed to allow users
to access and share contact data on a server."
Text from