[android-developers] EXCELLENT HOT LIST: ||JAVA || ORACLE CC || FULL STACK || JAVA J2EE/UI || DevOps || ORACLE CC TESTER ||

[madasu melody songs m]

Hi Partner!!!

 

I am *Madasu* from* Riyantech Software Solutions Inc *, Hope you are doing 
great today...

 

Please find the updated *HOT LIST *of my consultants.

Below is the list of Available Candidates for your requirements. Let me 
know if you have any requirements that match my list of available 
candidates and their criteria given below.

You can Contact me: *302-650-1666 or **mad...@riyantech.com* 


 

 

*Candidate*

*Skills*

*Visa*

*Location*

*Relocation*

*Nitesh*

Java

H1-B

MO

Open

*Srivasthava*

Java J2EE

H1-B

MD

Open

*Jeswanth*

Qlikview

H1-B

TX

Open

*Snehitha*

Devops /Java

H1-B

NC

Open

*KK*

Oracle CC

H1-B

TX

Open

*Duranath*

Java/J2ee-UI

H1-B

NJ

Open

*Mahender*

Java/J2ee-UI

H1-B

CA

Open

*mm*

Oracle CC Tester

H1-B

   AZ

Open

 

I would highly appreciate if you can add me (*mad...@riyantech.com*) in 
your daily requirement mailing list and keep me posted with your daily 
requirements. 
  

*Thanks & Regards,*

 

*Madasu* | 

*Riyantech Software Solutions Inc**.*

Board:  (302)-650-1666 | Mobile: (302)-357-9938 | Fax: 972-521-8020 *|* 
*mad...@riyantech.com* 

*Corporate Office: 38731 Fremont Blvd Fremont, CA -94536*

Information Technology, Engineering Services, Outsourcing and Innovation| 
www.riyantech.com

 

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/29c5e2d3-eb30-4e47-b6fb-4715e37a8a08%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] EXCELLENT HOT LIST: ||JAVA || ORACLE CC || FULL STACK || JAVA J2EE/UI || DevOps || ORACLE CC TESTER ||

[madasu melody songs m]

 

Hi Partner!!!

 

I am *Madasu* from* Riyantech Software Solutions Inc *, Hope you are doing 
great today...

 

Please find the updated *HOT LIST *of my consultants.

Below is the list of Available Candidates for your requirements. Let me 
know if you have any requirements that match my list of available 
candidates and their criteria given below.

You can Contact me: *302-650-1666 or **mad...@riyantech.com* 


 

 

*Candidate*

*Skills*

*Visa*

*Location*

*Relocation*

*Nitesh*

Java

H1-B

MO

Open

*Srivasthava*

Java J2EE

H1-B

MD

Open

*Jeswanth*

Qlikview 

H1-B

TX

Open

*Snehitha*

Devops /Java

H1-B

NC

Open

*KK*

Oracle CC

H1-B

TX

Open

*Duranath*

Java/J2ee-UI

H1-B

NJ

Open

*Mahender*

Java/J2ee-UI

H1-B

CA

Open

*mm*

Oracle CC Tester

H1-B

   AZ

Open

 

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/c0efd15d-01e6-498a-9288-0a1de2aca232%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] EXCELLENT HOT LIST: ||JAVA || ORACLE CC || QLIKVIEW || JAVA J2EE/UI || DevOps || QA/SELENIUM||

[madasu melody songs m]

 

Hi Partner!!!

 

I am *Madasu* from* Riyantech Software Solutions Inc *, Hope you are doing 
great today...

 

Please find the updated *HOT LIST *of my consultants.

Below is the list of Available Candidates for your requirements. Let me 
know if you have any requirements that match my list of available 
candidates and their criteria given below.

You can Contact me: *302-650-1666 or **mad...@riyantech.com* 


 

 

*Candidate*

*Skills*

*Visa*

*Location*

*Relocation*

*Nitesh*

Java

H1-B

MO

Open

*Srivasthava*

Java J2EE

H1-B

MD

Open

*Jeswanth*

Qlikview

H1-B

TX

Open

*Snehitha*

Devops /Java

H1-B

NC

Open

*KK*

Oracle CC

H1-B

TX

Open

*Duranath*

Java/J2ee-UI

H1-B

NJ

Open

*Mahender*

Java/J2ee-UI

H1-B

CA

Open

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/b49b9554-c416-473f-97b3-095739489765%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Android Studio help

[melody laker]

Hi Everyone, 

I'm really new to developing and using Android Studio.

I wanted to ask for advice on something that has been bugging me. When I 
press the green play button to send the app to my phone, it doesnt work if 
Module settings/project structure/Build Tools Version/ is set to 24.0.1 (as 
it was by default).

Instead, I have to change it to 23.0.3.

Can anyone shed any light on why this might be? I dont really understand 
what these settings even are so stand very little chance of figuring this 
out!

All help much appreciated

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/08a24df0-9616-4259-ab24-b76f2a280d29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] App Developers - Participate in our Survey get a $10 Amazon Card!

[melody]

 

We are recruiting Android app creators and sellers to participate in an 
online survey. It’s all about a fresh, new, exciting product that helps you 
make more sales! The first 100 respondents will each receive a $10 Amazon 
Gift Card as a thank you. https://www.surveymonkey.com/r/HP28QT7

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/29517e2f-2c7c-46ba-a143-8f69596e2130%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Android App Developers - 15 minute phone survey $50 Amazon Gift Card

[melody]

We are recruiting Android app creators and sellers to participate in a 
15-minute live phone survey. It’s all about a fresh, new, exciting product 
that helps you make more sales! You will receive a *$50 Amazon Gift Card* 
as a thank you after you've completed the scheduled phone survey. 
https://www.surveymonkey.com/r/CR66ZPH

On Monday, January 18, 2016 at 3:25:13 PM UTC-8, 
mel...@regattamarketing.com wrote:
>
> We are recruiting Android app creators and sellers to participate in a 
> 15-minute live phone survey. You will receive a $50 Amazon Gift Card as a 
> thank you after you've completed the scheduled phone survey. 
> https://www.surveymonkey.com/r/CR66ZPH
>

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/8f1994ca-851b-4446-bce1-0ea26a56e82b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Android App Developers - 15 minute phone survey $50 Amazon Gift Card

[melody]

Thanks for the participants that have signed up so far.  We are still 
looking for more developers.

On Monday, January 18, 2016 at 3:25:13 PM UTC-8, 
mel...@regattamarketing.com wrote:
>
> We are recruiting Android app creators and sellers to participate in a 
> 15-minute live phone survey. You will receive a $50 Amazon Gift Card as a 
> thank you after you've completed the scheduled phone survey. 
> https://www.surveymonkey.com/r/CR66ZPH
>

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/0e4d9e31-2650-4da8-925a-fca6d96cc738%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Android App Developers - 15 minute phone survey $50 Amazon Gift Card

[melody]

We are recruiting Android app creators and sellers to participate in a 
15-minute live phone survey. You will receive a $50 Amazon Gift Card as a 
thank you after you've completed the scheduled phone survey. 
https://www.surveymonkey.com/r/CR66ZPH

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/d45d9aa9-080c-404c-bdcc-7237b7231319%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Get a $10 Starbucks gift card via email by completing a 2-min survey on Android app marketing.

[melody]

Take a 2-min  survey on Android app 
marketing. We'll email you a $10 Starbucks gift card as a thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/3f12c00b-f7fd-44c0-94be-03096c1d6529%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Compress recorded audio

[melody]

I was really excited to see the new media.AudioRecord class in the
latest SDK.  I am trying to build an application that requires that I
have real-time access to the audio as it's being recorded through the
microphone.  The AudioRecord class accomplishes this and I am able to
get it working as described in the docs.

However, I still have two more problems now:

1) I need to stream the audio to a server as it's being recorded.
Linear PCM is not ideal for this since it is too big.  I also want to
store these files on the phone so I really need them to be smaller.  I
found an example of compression throuh A-law but this is only a 2:1
reduction in size.  For all the other mobile platforms we've developed
for, speex compression is available (20:1) through very simple API
calls but that doesn't seem to be the case with Android.  Is there any
way to compress these audio files?  I can work with anything on the
server side (amr/speex/mp3/etc.).  I looked into Jspeex, but it
doesn't look like this can be used in Android because it relies on
javax.sound.  Please correct me if I am wrong.

2) I'd like to show a volume meter to the user to show him/her how
loud he is speaking.  I was able to do this with
MediaRecorder.getMaxAmplitude(), but there doesn't seem to be a
similar method for AudioRecord.  Will I have to just do this myself by
examining the audio data as it's recorded?

Thanks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Re: How to do an animated pie chart?

[melody]

I wasn't able to do this with the standard animation classes, but I
did manage to do it.

First I used the use of the ArcShape class to generate the slice of
the pie.  In order to acheive the animation, I set up a worker thread
to repeatedly change the sweepAngle and call invalidate() on the
containing view at an arbitrary refresh rate (50ms seems to look
smooth).  It seems to work fine, but again, if anyone knows of a
better way to do this, I'm all ears.



melody wrote:
 Hi,

 I tried asking this in the beginners forum but didn't get any
 responses so I thought I'd try here.

 I was wondering if someone could give me some guidance on how to do an
 animated pie chart. My initial idea is to have a circle background
 image as my pie, and then create a slice of the pie and animate the
 scale and rotation of the slice.  However I'm not really sure how to
 do that.

 Or if there is a completely different but better way to do this, that
 would be great to know too.

 Thanks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Re: HTTP compression lost when using 3G connection

[melody]

Hi Jean-Baptiste Queru,

Thanks for the info.  Just wanted to clarify a minor point.

When you say that the data is compressed when it is sent over the air,
are you saying that the compression and decompression happens at a
layer that I never see?  Is the Android OS handling the decompression
of the incoming data that so that when I look at it in the SDK, it's
already decompressed for me?

Thanks.



Jean-Baptiste Queru wrote:
 It's actually not uncommon in the cell world to turn off compression
 on the public Internet, so that the proxy can have an easier time
 looking at the data and processing it to send it over the air (where
 it is compressed), i.e. trading Internet bandwidth for some CPU time
 on the proxy.

 JBQ

 On Tue, Nov 25, 2008 at 10:53 AM, melody [EMAIL PROTECTED] wrote:
 
  Thanks. I ran the test in the emulator, and the http compression was
  kept.  So this does indeed seem to be a problem being caused by a
  proxy at T-Mobile.
 
  Not to be overly dramatic, but isn't this a pretty serious issue?  I
  would think that under 3G, T-Mobile would very much want us all to be
  using HTTP compression so that we don't flood their network.  Even on
  my home broadband connection, when I turn off http compression in my
  browser to do testing work, most websites load much more slowly,
  especially with the massive css/js files being transmitted these
  days.
 
  Something else that may or may not be related:
  I noticed that the T-Mobile proxy is also converting my http request
  to a HTTP 1.0 request, whereas I am actually trying to send a HTTP
  1.1 request.
 
 
 
 
  David Turner wrote:
  The best way to test this is try to run your test from the emulator, since
  the browser
  wouldn't then use an intermediate T-Mobile proxy.
 
  On Tue, Nov 25, 2008 at 12:27 AM, melody [EMAIL PROTECTED] wrote:
 
  
   I've been working on improving the speed of my application and noticed
   that when I turn off wifi and use the 3G connection, http requests no
   longer use http compression.
  
   Specifically, when using the 3G connection, the Accept-Encoding
   header (which I have set to gzip, deflate) are stripped off before
   the request arrives at my server.  I tested this with the HttpClient
   class, and with my own custom http client through java.net.Socket.
  
   I then also verified this using the native android web browser.  With
   wifi turned on, my server recieves a header Accept-Encoding: gzip.
   With wifi turned off, and using the 3G connection, my server does not
   receive that header.
  
   I initially thought this might be an intentional behavior as part of
   3G connections, but then I tested it with a 3G iphone (on ATT), and
   there was no such problem there.  So I'm guessing it's a problem
   specific to T-Mobile.  i wonder if there is some proxy that is
   intentionally stripping out this header.
  
   I'd appreciate any advice about this.  For an XML-based web service
   like mine where the response data has a high compression ratio, this
   behavior causes a significant speed hit.
  
   
  
  
 
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Re: HTTP compression lost when using 3G connection

[melody]

I was doing my testing with my own custom written http client (based
on Java.net.Socket).  In all tests, I sent a Accept-Encoding: gzip,
deflate header.

The data I was receiving back from my server was not compressed when
using 3G, but it was compressed when I was using wifi (which doesn't
cause any problems, I just have to decompress it manually as you
suggested).

This is why I was concerned that the data was not actually being
compressed over the air.  If I'm not using the Android HTTP stack,
and I see uncompressed data from the socket's inputstream, does that
mean the data was actually transmitted uncompressed over the air?

Or is there some other compression/decompression layer when using a 3G
connection that has been abstracted away from the SDK?



Jean-Baptiste Queru wrote:
 The compression is standard HTTP compression when seen from the client.

 As I understand (but I'm not an authority in this domain), if you use
 the Android HTTP stack, the decompression will happen transparently
 for you.

 If you're rolling out your own HTTP code you'll have to do the
 decompression yourself, but the proxy should only send you compressed
 data if you advertise that you support it (in your request headers),
 and you should advertise it if you don't support it.

 JBQ

 On Wed, Dec 3, 2008 at 2:16 PM, melody [EMAIL PROTECTED] wrote:
 
  Hi Jean-Baptiste Queru,
 
  Thanks for the info.  Just wanted to clarify a minor point.
 
  When you say that the data is compressed when it is sent over the air,
  are you saying that the compression and decompression happens at a
  layer that I never see?  Is the Android OS handling the decompression
  of the incoming data that so that when I look at it in the SDK, it's
  already decompressed for me?
 
  Thanks.
 
 
 
  Jean-Baptiste Queru wrote:
  It's actually not uncommon in the cell world to turn off compression
  on the public Internet, so that the proxy can have an easier time
  looking at the data and processing it to send it over the air (where
  it is compressed), i.e. trading Internet bandwidth for some CPU time
  on the proxy.
 
  JBQ
 
  On Tue, Nov 25, 2008 at 10:53 AM, melody [EMAIL PROTECTED] wrote:
  
   Thanks. I ran the test in the emulator, and the http compression was
   kept.  So this does indeed seem to be a problem being caused by a
   proxy at T-Mobile.
  
   Not to be overly dramatic, but isn't this a pretty serious issue?  I
   would think that under 3G, T-Mobile would very much want us all to be
   using HTTP compression so that we don't flood their network.  Even on
   my home broadband connection, when I turn off http compression in my
   browser to do testing work, most websites load much more slowly,
   especially with the massive css/js files being transmitted these
   days.
  
   Something else that may or may not be related:
   I noticed that the T-Mobile proxy is also converting my http request
   to a HTTP 1.0 request, whereas I am actually trying to send a HTTP
   1.1 request.
  
  
  
  
   David Turner wrote:
   The best way to test this is try to run your test from the emulator, 
   since
   the browser
   wouldn't then use an intermediate T-Mobile proxy.
  
   On Tue, Nov 25, 2008 at 12:27 AM, melody [EMAIL PROTECTED] wrote:
  
   
I've been working on improving the speed of my application and noticed
that when I turn off wifi and use the 3G connection, http requests no
longer use http compression.
   
Specifically, when using the 3G connection, the Accept-Encoding
header (which I have set to gzip, deflate) are stripped off before
the request arrives at my server.  I tested this with the HttpClient
class, and with my own custom http client through java.net.Socket.
   
I then also verified this using the native android web browser.  With
wifi turned on, my server recieves a header Accept-Encoding: gzip.
With wifi turned off, and using the 3G connection, my server does not
receive that header.
   
I initially thought this might be an intentional behavior as part of
3G connections, but then I tested it with a 3G iphone (on ATT), and
there was no such problem there.  So I'm guessing it's a problem
specific to T-Mobile.  i wonder if there is some proxy that is
intentionally stripping out this header.
   
I'd appreciate any advice about this.  For an XML-based web service
like mine where the response data has a high compression ratio, this
behavior causes a significant speed hit.
   

   
   
  
  
 
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Re: HTTP compression lost when using 3G connection

[melody]

Thanks for the suggestion.

Content-Type: text/xml; charset=utf-8 is what I get in the response
header.

Just as a test, I tried sending back Content-Type: text/html
instead, but that didn't change anything with regards to compression.




Jean-Baptiste Queru wrote:
 I'm not familiar enough with the low-level protocols used in 2G or 3G,
 so I don't know whether there's any compression happening at that
 level. It sounds like the data is indeed not recompressed by the proxy
 at the HTTP level (even though I believe that such compression would
 be beneficial).

 What is the MIME type of your response? It's possible that the proxy
 only compresses html, javascript and css and leaves everything else
 alone.

 JBQ

 On Wed, Dec 3, 2008 at 2:57 PM, melody [EMAIL PROTECTED] wrote:
 
  I was doing my testing with my own custom written http client (based
  on Java.net.Socket).  In all tests, I sent a Accept-Encoding: gzip,
  deflate header.
 
  The data I was receiving back from my server was not compressed when
  using 3G, but it was compressed when I was using wifi (which doesn't
  cause any problems, I just have to decompress it manually as you
  suggested).
 
  This is why I was concerned that the data was not actually being
  compressed over the air.  If I'm not using the Android HTTP stack,
  and I see uncompressed data from the socket's inputstream, does that
  mean the data was actually transmitted uncompressed over the air?
 
  Or is there some other compression/decompression layer when using a 3G
  connection that has been abstracted away from the SDK?
 
 
 
  Jean-Baptiste Queru wrote:
  The compression is standard HTTP compression when seen from the client.
 
  As I understand (but I'm not an authority in this domain), if you use
  the Android HTTP stack, the decompression will happen transparently
  for you.
 
  If you're rolling out your own HTTP code you'll have to do the
  decompression yourself, but the proxy should only send you compressed
  data if you advertise that you support it (in your request headers),
  and you should advertise it if you don't support it.
 
  JBQ
 
  On Wed, Dec 3, 2008 at 2:16 PM, melody [EMAIL PROTECTED] wrote:
  
   Hi Jean-Baptiste Queru,
  
   Thanks for the info.  Just wanted to clarify a minor point.
  
   When you say that the data is compressed when it is sent over the air,
   are you saying that the compression and decompression happens at a
   layer that I never see?  Is the Android OS handling the decompression
   of the incoming data that so that when I look at it in the SDK, it's
   already decompressed for me?
  
   Thanks.
  
  
  
   Jean-Baptiste Queru wrote:
   It's actually not uncommon in the cell world to turn off compression
   on the public Internet, so that the proxy can have an easier time
   looking at the data and processing it to send it over the air (where
   it is compressed), i.e. trading Internet bandwidth for some CPU time
   on the proxy.
  
   JBQ
  
   On Tue, Nov 25, 2008 at 10:53 AM, melody [EMAIL PROTECTED] wrote:
   
Thanks. I ran the test in the emulator, and the http compression was
kept.  So this does indeed seem to be a problem being caused by a
proxy at T-Mobile.
   
Not to be overly dramatic, but isn't this a pretty serious issue?  I
would think that under 3G, T-Mobile would very much want us all to be
using HTTP compression so that we don't flood their network.  Even on
my home broadband connection, when I turn off http compression in my
browser to do testing work, most websites load much more slowly,
especially with the massive css/js files being transmitted these
days.
   
Something else that may or may not be related:
I noticed that the T-Mobile proxy is also converting my http request
to a HTTP 1.0 request, whereas I am actually trying to send a HTTP
1.1 request.
   
   
   
   
David Turner wrote:
The best way to test this is try to run your test from the emulator, 
since
the browser
wouldn't then use an intermediate T-Mobile proxy.
   
On Tue, Nov 25, 2008 at 12:27 AM, melody [EMAIL PROTECTED] wrote:
   

 I've been working on improving the speed of my application and 
 noticed
 that when I turn off wifi and use the 3G connection, http requests 
 no
 longer use http compression.

 Specifically, when using the 3G connection, the Accept-Encoding
 header (which I have set to gzip, deflate) are stripped off 
 before
 the request arrives at my server.  I tested this with the 
 HttpClient
 class, and with my own custom http client through java.net.Socket.

 I then also verified this using the native android web browser.  
 With
 wifi turned on, my server recieves a header Accept-Encoding: 
 gzip.
 With wifi turned off, and using the 3G connection, my server does 
 not
 receive that header.

 I initially thought this might be an intentional behavior

[android-developers] audio recording issues

[melody]

I've been working on an application that requires the user to record
some audio, and for that audio to be sent my server.  On our end, we
then analyze that audio and return results to the user.  The percieved
performance of our application benefits greatly from being able to
start sending the audio data to our server while the user is still
recording.

My problem:

The MediaRecorder class only seems to support writing to a file at the
moment.  This audio data seems to be flushed to this output file in
4kB chunks, which works out to about 7 seconds of audio.  This means I
can't start sending any data to my server until after the first 7
seconds of recording (and then I can't send anything again for another
7 seconds, and so on).  Ideally I would like to start sending the
audio to the server much sooner, and in much smaller chunks than
that.  This is not only to minimize the potential impact of a slow
connection, but also so that I can start processing the chunks of
audio earlier.

The perfect situation would be that when the user stops recording
audio, I will have already received and processed almost all that he/
she recorded, with only a very small chunk leftover.

Thanks for your help.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] Re: HTTP compression lost when using 3G connection

[melody]

Thanks. I ran the test in the emulator, and the http compression was
kept.  So this does indeed seem to be a problem being caused by a
proxy at T-Mobile.

Not to be overly dramatic, but isn't this a pretty serious issue?  I
would think that under 3G, T-Mobile would very much want us all to be
using HTTP compression so that we don't flood their network.  Even on
my home broadband connection, when I turn off http compression in my
browser to do testing work, most websites load much more slowly,
especially with the massive css/js files being transmitted these
days.

Something else that may or may not be related:
I noticed that the T-Mobile proxy is also converting my http request
to a HTTP 1.0 request, whereas I am actually trying to send a HTTP
1.1 request.




David Turner wrote:
 The best way to test this is try to run your test from the emulator, since
 the browser
 wouldn't then use an intermediate T-Mobile proxy.

 On Tue, Nov 25, 2008 at 12:27 AM, melody [EMAIL PROTECTED] wrote:

 
  I've been working on improving the speed of my application and noticed
  that when I turn off wifi and use the 3G connection, http requests no
  longer use http compression.
 
  Specifically, when using the 3G connection, the Accept-Encoding
  header (which I have set to gzip, deflate) are stripped off before
  the request arrives at my server.  I tested this with the HttpClient
  class, and with my own custom http client through java.net.Socket.
 
  I then also verified this using the native android web browser.  With
  wifi turned on, my server recieves a header Accept-Encoding: gzip.
  With wifi turned off, and using the 3G connection, my server does not
  receive that header.
 
  I initially thought this might be an intentional behavior as part of
  3G connections, but then I tested it with a 3G iphone (on ATT), and
  there was no such problem there.  So I'm guessing it's a problem
  specific to T-Mobile.  i wonder if there is some proxy that is
  intentionally stripping out this header.
 
  I'd appreciate any advice about this.  For an XML-based web service
  like mine where the response data has a high compression ratio, this
  behavior causes a significant speed hit.
 
  
 
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---

[android-developers] HTTP compression lost when using 3G connection

[melody]

I've been working on improving the speed of my application and noticed
that when I turn off wifi and use the 3G connection, http requests no
longer use http compression.

Specifically, when using the 3G connection, the Accept-Encoding
header (which I have set to gzip, deflate) are stripped off before
the request arrives at my server.  I tested this with the HttpClient
class, and with my own custom http client through java.net.Socket.

I then also verified this using the native android web browser.  With
wifi turned on, my server recieves a header Accept-Encoding: gzip.
With wifi turned off, and using the 3G connection, my server does not
receive that header.

I initially thought this might be an intentional behavior as part of
3G connections, but then I tested it with a 3G iphone (on ATT), and
there was no such problem there.  So I'm guessing it's a problem
specific to T-Mobile.  i wonder if there is some proxy that is
intentionally stripping out this header.

I'd appreciate any advice about this.  For an XML-based web service
like mine where the response data has a high compression ratio, this
behavior causes a significant speed hit.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---