Develop Reference

Flurry has an interface that always responds to 400

I mainly use the Flurry Event function, my other management is normal, but there is always an interface 400（https://data.flurry.com/v1/flr.do），which shows the information
HTTP ERROR 400
Problem accessing /v1/flr.do. Reason:
X-Flurry-Api-Key apikey not present in header
Powered by Jetty://
My initialization code is as follows
FlurryAgent.Builder()
.withLogEnabled(true)
.withCaptureUncaughtExceptions(true)
.withContinueSessionMillis(10000)
.withLogLevel(Log.VERBOSE)
.build(this.context!!, this.context!!.getString(R.string.ID_Flurry))

Please make sure R.string.ID_Flurry returns your correct Flurry API-KEY.

UrbanAirship: Error setting tags on namedUser

Following the instructions on UrbanAirship documentation, I need to add a TagGroup to a namedUser with this lines of code on a demo App in Android
airship.getPushManager().getNamedUser().setId("123456");
airship.getPushManager().getNamedUser().editTagGroups().addTag("loyalty", "elite").apply();
But, the LogCat shows this error:
D/UrbanAirshipDemo - UALib﹕ Received a response for tag groups: Response: ResponseBody: ResponseHeaders: {null=[HTTP/1.1 400 Bad Request], Connection=[close, Transfer-Encoding], Content-Type=[application/vnd.urbanairship+json; version=3], Date=[Wed, 24 Jun 2015 20:02:06 GMT], Transfer-Encoding=[chunked], X-Android-Received-Millis=[1435176126629], X-Android-Response-Source=[NETWORK 400], X-Android-Sent-Millis=[1435176126427]} ResponseMessage: Bad Request Status: 400
E/UrbanAirshipDemo - UALib﹕ Update tag groups failed with status: 400
E/UrbanAirshipDemo - UALib﹕ Both add & remove fields are present and the intersection of the tags in these fields is not empty.
Is it something weird on their API? Instructions from here: http://docs.urbanairship.com/platform/android.html#named-user-tag-groups
Is just simple the implementation, but their API is returning 400. Push notifications are working fine

I was able to reproduce the same issue. The error message is incorrect, the real issue is the tag group does not exists yet. Groups can only be created through Go. Try creating the group following - http://docs.urbanairship.com/topic-guides/tag-groups-walkthrough.html#create-a-tag-group and try again.
The error message will be fixed in a future release.

Download Unsuccessful on Mobile Browser (Android) when using cfheader and cfcontent in Coldfusion

When I run the code below from a desktop browser, there is no problem.
However, when I try it from either Android Chrome or the default Android browser, I always get a "Download Unsuccessful" message.
Code:
<cfsetting enablecfoutputonly="yes">
<cfcontent type="text/calendar" reset="Yes">
<cfheader name="Content-Disposition" value='inline; filename="newAppointment.ics"'>
<cfoutput>BEGIN:VCALENDAR
PRODID:-//Some organization//some application//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VEVENT
UID:20120925T072912Z-140#http://localhost/www/
CREATED:20140925T072912Z
DTSTAMP:20140922T090500Z
DTSTART:20140922T090500Z
DTEND:20140922T100500Z
DESCRIPTION:Please attend this sample meeting
SUMMARY:Invitation to attend training
LOCATION:Earth
ATTENDEE;RSVP=TRUE:mailto:periklis#example.com
ORGANIZER;CN=periklis#example.com:mailto:periklis#example.com
LAST-MODIFIED:20140925T072912Z
PRIORITY:5
SEQUENCE:0
STATUS:CONFIRMED
TRANSP:TRANSPARENT
END:VEVENT
END:VCALENDAR</cfoutput>
<cfsetting enablecfoutputonly="no">
I have tried using both "text/calendar" and "application/octet-stream" for the content type, and both "inline" and "attachment" for the content disposition. I have also tried the filename with and without quotes... all to no avail.
We are running Coldfusion 10 on an IIS server, and we added this configuration to the server so we can download an .ics file directly from the server now. However, we want to generate a single use file dynamically and serve it to the user.
IIS server setting:
<configuration>
<system.webServer>
<staticContent>
<remove fileExtension=".ics" />
<mimeMap fileExtension=".ics" mimeType="application/octet-stream" />
</staticContent>
</system.webServer>
</configuration>
Using Chrome's Remote Debugging, I can see this coming through as the Response header from the code above. (Note: I see a lot of people put cfheader first, then cfcontent... but if I follow that order, the content disposition is not passed along so I've been putting cfcontent first.)
Response Header:
HTTP/1.1 200 OK
Connection: close
Date: Fri, 05 Sep 2014 21:31:31 GMT
Server: Microsoft-IIS/6.0
P3P: CP='NOI DSP COR LAW NID CUR ADMa OUR DELa IND PHY ONL UNI PUR COM NAV STA'
Vary: Accept-Encoding,User-Agent
Content-Disposition: inline; filename="newAppointment.ics"
Content-Type: text/calendar;charset=UTF-8
I've scoured the internet, and the closest thing I've found was another stackoverflow question with some suggestions but no accepted answer. Also... being a new user, I can't comment on it to ask if an answer was found.
cfheader cfcontent Mobile Browser download unsuccessful
I tried to give as many details that I can think of. Let me know if more information would be helpful in solving the oddity.
As always, any help would be greatly appreciated.

Try changing this from "inline" to "attachment"
<cfheader name="Content-Disposition" value='inline; filename="newAppointment.ics"'>
<cfheader name="Content-Disposition" value="attachment; filename=""newAppointment.ics""">

Issues with Caching on OkHttpClient 2.0

I have an issue with caching using OkHttpClient 2.0. It seems that the Response is ignoring the Cache-Control header completely. This is how I am setting up the client and the cache.
OkHttpClient client = new OkHttpClient();
cache = new Cache(new File(Session.getInstance().getContext().getCacheDir(),"http"), 10 * 1024 * 1024);
client.setCache(cache);
client.setCookieHandler(CookieHandler.getDefault());
client.setConnectTimeout(CONNECTION_TIMEOUT, TimeUnit.MILLISECONDS);
client.setReadTimeout(SOCKET_TIMEOUT, TimeUnit.MILLISECONDS);
I believe that the cache directory is created correctly. This is what I see in journal in the /cache/http directory of my application.
libcore.io.DiskLruCache
1
201105
2
This is how I am creating the Request.
Request mRequest = new Request.Builder().url(mUrl).get().build();
Getting the response :
Response response = client.newCall(mRequest).execute();
When using curl, the headers as as follows.
< HTTP/1.1 200 OK
< Date: Fri, 27 Jun 2014 19:39:40 GMT
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< Cache-Control: no-transform, max-age=1800
< Content-Type: application/json
< Transfer-Encoding: chunked
The OKHttp response headers are as follows.
Connection:Keep-Alive
Content-Type:application/json
Date:Fri, 27 Jun 2014 18:58:30 GMT
Keep-Alive:timeout=5, max=100
OkHttp-Received-Millis:1403895511337
OkHttp-Selected-Protocol:http/1.1
OkHttp-Sent-Millis:1403895511140
Server:Apache-Coyote/1.1
Transfer-Encoding:chunked
The responses never get cached and the call client.getCache().getHitCount() always gives 0. Can someone please suggest what changes might be required here to make the cache work? Thanks.

Okay, the problem was all my get and post requests were using the Authorization Bearer xxxx header and http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html section 14.8 states that these requests can't be cached. The solution was to use s-maxage on the server instead of just max age according to this :
When a shared cache (see section 13.7) receives a request
containing an Authorization field, it MUST NOT return the
corresponding response as a reply to any other request, unless one
of the following specific exceptions holds:
If the response includes the "s-maxage" cache-control
directive, the cache MAY use that response in replying to a
subsequent request.

Are you reading the entire response body? OkHttp won't cache unless you consume the entire response.

I realize you solved your specific problem, but the symptom you describe has another cause.
When using the okhttp-urlconnection, caching doesn't kick in by default, unless we do this:
connection.setUseCaches(true)
(It should be on by default, but some library I was using was setting it to off)

Android URLConnection class cannot get content lenght using 3G internet connection

I've got the following piece of code:
URL url = new URL("http://myserver.com/getFile.php");
URLConnection conexion = url.openConnection();
conexion.connect();
int lenghtOfFile = conexion.getContentLength();
Everything works fine until I work with WiFi connection. If I try to run this code when there is only GPRS/3G connection available, conexion.getContentLength() returns -1.
Any idea why?
EDIT:
I've check the headers using getHeaderFields(). They are different if I use 3G network. Basically there is no Content-Length in this case. Any idea why server returns different headers? I'm not using any special script to provide the file, I only get the file that is placed at given location.
Entire header for the WiFi case:
{Accept-Ranges=[bytes], Connection=[Keep-Alive], Content-Length=[628254], Content-Type=[text/plain; charset=UTF-8], Date=[Tue, 29 Nov 2011 11:22:50 GMT], ETag=["7a0c7-9961e-4af3f38778500"], Keep-Alive=[timeout=15], Last-Modified=[Fri, 14 Oct 2011 09:52:52 GMT], Server=[Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch mod_python/3.3.1 Python/2.6.6 mod_ssl/2.2.9 OpenSSL/0.9.8o mod_wsgi/3.3 mod_perl/2.0.4 Perl/v5.10.0]}
Entire header for the case when using 3G:
{Accept-Ranges=[bytes], Connection=[Keep-Alive], Content-Type=[text/plain; charset=UTF-8], Date=[Tue, 29 Nov 2011 11:20:33 GMT], ETag=["7a0c7-9961e-4af3f38778500"], Keep-Alive=[timeout=15], Last-Modified=[Fri, 14 Oct 2011 09:52:52 GMT], Server=[Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch mod_python/3.3.1 Python/2.6.6 mod_ssl/2.2.9 OpenSSL/0.9.8o mod_wsgi/3.3 mod_perl/2.0.4 Perl/v5.10.0], Transfer-Encoding=[chunked], Warning=[214 warkaz-fe07 "Transformation applied"]}

Are you sure that the server provides the content length by sending the Content-Length header in the response?
From the headers it's clear that your provider has some kind of proxy in place that does a transformation, stripping the content-length in the process. The warning header clearly indicates this. You could try returning a different type of content type (you are now getting text/plain), maybe this particular proxy won't touch it. It's not a great solution of course, there are a lot things carriers may have to "optimize" their network in some way.
You could also try a HEAD request using a range header to get a ballpark of the content size. In that case you'd guess a few ranges, like 100k, 1000k etc to see if the server thinks that's an acceptable range. You could use that fake range for your progress. Again, this isn't a very good solution but if you really need the progress, it's something to try.
In the end it's best to just show the progress as unknown if there's no length known.

Since you are using
new URL("http://myserver.com/getFile.php");
I suppose you are using a personal server that you have set up, and when using WiFi your phone is in your local network and thereby can see your server, but when you are trying to connect via GPRs/3G you are trying to access your local server from the internet.

It is probably due to a limitation from your carrier. Try to avoid needing this value. (for example, by reading the inputStream until you cannot read it).