[android-developers] Re: Proxy related code changes needed in Apps
I'm doing HTTPClient (Through the API's) on a carrier proxy just fine
without needing to fiddle with anything. Are you attempting to do
HTTPClient or socket programming or what? My carrier doesn't use
authentication, so maybe its something to do with authenticated
proxies. *Shrugs*
Just briefly reading over the socket implementation, it has a
workaround to enable explicit proxy access.
public Socket (Proxy proxy)
Since: API Level 1
Creates a new unconnected socket using the given proxy type. When a
SocketImplFactory is defined it creates the internal socket
implementation, otherwise the default socket implementation will be
used for this socket.
Example that will create a socket connection through a SOCKS proxy
server:
Socket sock = new Socket(new Proxy(Proxy.Type.SOCKS, new
InetSocketAddress("test.domain.org", 2130)));
Parameters
proxythe specified proxy for this socket.
The proxyselector class is designed to allow for the system to
enumerate the available proxies that the system is using, and as long
as android is passing the APN proxy settings down to your application,
you should just implement a proxyselector / socket shim if you needed
to do proxy passthrough. If I recall in java, one such proxy instance
was DIRECT which was always available as a 'no proxy' option.
--
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: Emulator performance
> Is this a common trend? I find the emulator to be pretty slow in comparison to my NexusOne sitting right next to my PC. The factor is probably around 0.5x - 0.75x the speed. The PC is a Core2Duo 5400 3Ghz so no slouch by any means. I suppose that if they bothered to accelerate the GFX / etc.. and better utilize the virtualization functions they could squeeze out some more into the emulator. That said, having the emulator slower than most devices is a good (though incidental) test of how your app will run in the real world. I don't know if its related, but in the last tooling update the debugger is killing my processing performance, like horribly. Try running the app stand-alone vs. debugging and make sure it isn't just debugging/profiling cutting into emulator performance. > And regarding memory - I am loading Eclipse with close to 1G to be > able to > run the emulator and its basic services - is that normal? The emulator runs in its own process. If you mean to actually get your app to launch then well Eclipse is a ram heavy platform. You get a ton of features for that investment. If you really need a slimmer eclipse, try to find features you don't use and remove them. Personally I peg my eclipse at heap 1.5g and permgen 256 and it never blinks (Even with the J2EE tools which eats resources like crazy). -- 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: requestLocationUpdates / non-UI-thread / getMainLooper()
I could be wrong about this due to inexperience, but due to the nature
of the looper, if you put it on the main looper and the GPS decides to
randomly disappear for seconds then the GUI freezes along with it. I
don't know if that really happen in reality, but I imagine the
possibility could occur. If you want to make sure that the location
updates don't mess up your UI you could always do something like:
class MyLocThread extends Thread
{
public MyLocThread ()
{
setDaemon(true);
setName("LocationThread");
}
public void run()
{
Looper.prepare();
lm.requestLocationUpdates(
LocationManager.GPS_PROVIDER,
0L,
0L,
locListenerGPS,
Looper.getLooper()
);
Looper.loop();
}
}
On Sep 29, 8:35 am, Pent wrote:
> Is there anything wrong with specifying the main thread looper to
> handle messages about location update like this:
>
> lm.requestLocationUpdates(
> LocationManager.GPS_PROVIDER,
> 0L,
> 0L,
> locListenerGPS,
> Looper.getMainLooper()
> );
>
> (call is made from a non-UI thread)
>
> Am I going to start getting weird unexplicable errors in other places
> due to the looper voodoo ?
>
> Thanks,
>
> Pent
--
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] New SDK causes Slow Debugging on N1
I've got a Nexus One running a debug version of my application, and I just today downloaded and installed the 0.9.8 version of the SDK tools, and I swear that Debugging latency has increased incredibly. I never bothered to measure the overhead before the upgrade because I always found the phone's debugging overhead to be small enough to not affect matter. Well, now I have AI code which runs at ~10 MS standalone taking 300-400MS through debugging. A 40X performance loss is not something to cough at. Is it just me not seeing the performance loss previously, or has something broken? -- 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
