Create a native C# client library for the Channel API [35888715]

Feature Request

Status Update

No update yet.

Description

mo...@google.com

created issue #1

Dec 5, 2010 05:15AM

Like Java, it would be great to be able to write native client apps in C# that consume messages sent using the Channel API.

Comments

pe...@knego.net <pe...@knego.net> #2Dec 6, 2010 02:34PM

It looks like the culprit for this regression is aosp/3297690. Conrad, could you please take a look and confirm whether this is expected with your changes?

jb...@jbit.net <jb...@jbit.net> #3Dec 12, 2010 03:02AM

Thanks for the triage. I'll take a look!

ch...@google.com <ch...@google.com> Dec 14, 2010 01:16AM

Assigned to ch...@google.com.

gh...@gmail.com <gh...@gmail.com> #4Jan 6, 2011 05:57PM

Project: platform/frameworks/support
Branch: androidx-main
Author: drchen <conradchen@google.com>
Link: https://android-review.googlesource.com/3344233

Fix performance regression caused by rememberPaneExpansionState

Expand for full commit details

Fix performance regression caused by rememberPaneExpansionState 
 
The regression is caused by the introduction of LaunchEffect in the 
remember function, which is required to keep the state correctly between 
scaffold value changes. 
 
However, when paneExpansionDragHandle is not provided, there's no way 
for devs to mutate the default paneExpansionState. In this case, we can 
avoid a lot of management overhead by just providing a stub 
implementation. 
 
Relnote: Makes pane expansion state null by default 
Test: benchmarks and existing instrumentation tests 
Bug: 376394520 
Change-Id: Ia65f8919ba9aaaa4c611ecb40514ee41d1e8d56f

Files:

M compose/material3/adaptive/adaptive-layout/api/current.txt
M compose/material3/adaptive/adaptive-layout/api/restricted_current.txt
M compose/material3/adaptive/adaptive-layout/src/commonMain/kotlin/androidx/compose/material3/adaptive/layout/ListDetailPaneScaffold.kt
M compose/material3/adaptive/adaptive-layout/src/commonMain/kotlin/androidx/compose/material3/adaptive/layout/PaneExpansionState.kt
M compose/material3/adaptive/adaptive-layout/src/commonMain/kotlin/androidx/compose/material3/adaptive/layout/SupportingPaneScaffold.kt
M compose/material3/adaptive/adaptive-layout/src/commonMain/kotlin/androidx/compose/material3/adaptive/layout/ThreePaneScaffold.kt
M compose/material3/adaptive/adaptive-navigation/api/current.txt
M compose/material3/adaptive/adaptive-navigation/api/restricted_current.txt
M compose/material3/adaptive/adaptive-navigation/src/androidMain/kotlin/androidx/compose/material3/adaptive/navigation/AndroidThreePaneScaffold.android.kt

Hash: 53e5f16e76ae8e1b81468649f4bcc5ec8c06d05f
Date: Tue Nov 12 12:14:14 2024

ik...@google.com <ik...@google.com> #5Jan 7, 2011 12:08AM

How would a RESTful API work? The point of channel API is browser push, and if you wanted to push via HTTP, you already have URLFetch.

gh...@gmail.com <gh...@gmail.com> #6Jan 7, 2011 12:51AM

We have an internal Comet server we wrote that can handle around 7million open connections. For smaller projects, Channel API would be great. Our REST looking apis or nice looking HTTP ones, looks something like this from memory.

http://mycometserver/{ID}/{count} where {count} is what the client thinks they are up to. As a result, the response is the latest count the server says the client should be. If the client and server are the same, the server camps on the response.
To bump the count, there is another API:

http://mycometserver/Bump/{ID}/{new count}, which will result in the waiting client to return.
Why couldn't the Channel API, have done that, your POST is similar to our bump. You could have provided this sort of API as well as a the JS version. As a result, I have to sniff traffic to see what your HTTP call looks like.
That being said, I don't need a C# wrapper from you guys, just a nice HTTP api.

ma...@gmail.com <ma...@gmail.com> #7Feb 26, 2011 04:02PM

I would love to see this feature too, as I am working on a Silverlight application using App Engine and the Channel API to push data. Taking a detour to JavaScript seems tedious.

wa...@gmail.com <wa...@gmail.com> #8Apr 26, 2011 07:18PM

Add a HUGE +1 for this post as well. Would love to see the Channel API supported by other "channels", get it?

ri...@gmail.com <ri...@gmail.com> #9May 28, 2011 06:17AM

An Objective C library would be absolutely fantastic !

th...@gmail.com <th...@gmail.com> #10May 28, 2011 04:20PM

Seem like we just need C API...

hr...@gmail.com <hr...@gmail.com> #11Jun 21, 2011 04:15PM

If now channels work client-side by sending http requests, and server-side holding without answer for long time, Google could as well switch everything to Web Sockets when they become more mainstream?

But still I will vote for this. I would very much like to use Channels in my Android app to talk to my Google App Engine cloud.

ja...@novaleaf.com <ja...@novaleaf.com> #12Mar 15, 2012 01:36AM

some non-webpage channel would be nice, doesn't have to be C# only but if it works in c# others could port the features to other platforms

ur...@gmail.com <ur...@gmail.com> #13Nov 22, 2012 08:08AM

Need this too for Objective-C

vi...@umich.edu <vi...@umich.edu> #14Nov 22, 2012 03:02PM

In response to Comment 13, I recommend you star

Issue 7273

(Channel Client for iOS). Google prematurely closed that issue and needs to revisit it.

is...@google.com <is...@google.com> May 8, 2018 07:32PM

Status: New