[android-developers] In-app billing - ITEM_ID limitations
I've just finished reading the preliminary documentation for in-app billing. If I've understood correctly, as part of the billing request you can supply: * ITEM_ID which is limited to a small number of pre-registered product ids * DEVELOPER_PAYLOAD unconstrained - but with caveats? and these are the only two pieces of data you can send to identify the product being purchased. But even the DEVELOPER_PAYLOAD appears to be off-limits; the documentation contains the following (rather cryptic) advice: We recommend that you do not use this field to send data or content. I take this to mean product data/content, but that's no more than a guess, and if that's the correct interpretation, why? The result seems to be that you can't sell individuated items. I was hoping to use the in-app billing system to allow purchases of dynamically generated designs from my forthcoming Metaglow application, but this doesn't appear to be possible without operating some sort of 'credits purchase' system which I think would provide a very poor user experience and which isn't what I want to give users. Can anyone shed light on this? -- 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] App widgets and remote views
I've just spent the last few hours nosing around to see what's new in this 1.5 pre-release. I decided to implement an app widget to try out the new package. From the provider end it's very straightforward, but I'm not certain about the performance implications. Specifically, I decided to implement a clock (see http://www.tomgibara.com/android/babilo for a screenshot). In my implementation I render the clock image into a bitmap and have a very simple remote view that consists of a single image view to display it. This means that the bitmap must be marshalled on every update and the process must be in memory too of course. That's a lot of memory for a clock. Is there a better approach? Or is a non-digital clock ill suited as a widget? Also is there a way for the widget provider to know (receive a hint for) the size at which the widget will be rendered? This is useful in this instance since one doesn't want to make the bitmap any larger than necessary. A final question: is there a way for a provider to request that a wedget be 'oversized' (like the search bar or media control)? Answers to any of these questions would help me to get a better idea of what widgets might be effective. Tom. --~--~-~--~~~---~--~~ 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] BitmapShader performance
I'm experimenting with tiling a fullscreen image (480x320px ARGB
bitmap) with a square image (160x160px ARGB bitmap). My initial
implementation was naive:
public void render(Canvas canvas) {
final int size = tile.getWidth();
final int w = canvas.getWidth();
final int h = canvas.getHeight();
for (int y = 0; y h; y += size) {
for (int x = 0; x w; x += size) {
canvas.drawBitmap(tile, x, y, null);
}
}
}
Then I remembered that Paint supports a Shader, so I swapped this
implementation for something much more satisfying:
public void render(Canvas canvas) {
canvas.drawPaint(paint);
}
Where paint is initialized outside this method with:
paint = new Paint();
paint.setShader(new BitmapShader(tile, Shader.TileMode.REPEAT,
Shader.TileMode.REPEAT));
I expected that using a BitmapShader would be competitive with the
first implementation and probably slightly faster. But initial
benchmarking indicates that the first method is more than twice as
fast (almost 3x as fast if PorterDuff.Mode.SRC is used for both). I
found that surprising.
Is there a good reason that the BitmapShader is necessarily much
slower, or does it point to a deficiency in its implementation?
--~--~-~--~~~---~--~~
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: BitmapShader performance
Romain, Thanks for the explanation.
On Feb 5, 10:26 pm, Romain Guy romain...@google.com wrote:
Tom,
A shader is a per-pixel operation, which lets you apply it to any
shape, respecting alpha blending as well. As such it is not surprising
that your first method is faster.
On Thu, Feb 5, 2009 at 2:08 PM, tomgibara m...@tomgibara.com wrote:
I'm experimenting with tiling a fullscreen image (480x320px ARGB
bitmap) with a square image (160x160px ARGB bitmap). My initial
implementation was naive:
public void render(Canvas canvas) {
final int size = tile.getWidth();
final int w = canvas.getWidth();
final int h = canvas.getHeight();
for (int y = 0; y h; y += size) {
for (int x = 0; x w; x += size) {
canvas.drawBitmap(tile, x, y, null);
}
}
}
Then I remembered that Paint supports a Shader, so I swapped this
implementation for something much more satisfying:
public void render(Canvas canvas) {
canvas.drawPaint(paint);
}
Where paint is initialized outside this method with:
paint = new Paint();
paint.setShader(new BitmapShader(tile, Shader.TileMode.REPEAT,
Shader.TileMode.REPEAT));
I expected that using a BitmapShader would be competitive with the
first implementation and probably slightly faster. But initial
benchmarking indicates that the first method is more than twice as
fast (almost 3x as fast if PorterDuff.Mode.SRC is used for both). I
found that surprising.
Is there a good reason that the BitmapShader is necessarily much
slower, or does it point to a deficiency in its implementation?
--
Romain Guy
Android framework engineer
romain...@android.com
Note: please don't send private questions to me, as I don't have time
to provide private support. All such questions should be posted on
public forums, where I and others can see and answer them
--~--~-~--~~~---~--~~
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: Java IO is super-slow in Android -- why?
And I even managed to forget the code:
try {
final int bs = 8192;
final byte[] buffer = new byte[bs];
long startTime = System.currentTimeMillis();
OutputStream writer = openFileOutput(speedtest,
MODE_PRIVATE);
final int size = 100;
for (int i = 0; i size; i += buffer.length)
writer.write(buffer, 0, Math.min(bs, size-i));
writer.close();
Log.i(speedtest, speed test a: +
(System.currentTimeMillis() -
startTime));
startTime = System.currentTimeMillis();
InputStream in = openFileInput(speedtest);
int r = 0;
while (r = 0) {
r = in.read(buffer);
}
in.close();
Log.i(speedtest, speed test b: +
(System.currentTimeMillis() -
startTime));
startTime = System.currentTimeMillis();
} catch (IOException e) {
Log.e(test, oops, e);
}
On Nov 28, 9:08 pm, Tom Gibara [EMAIL PROTECTED] wrote:
Hi Luke,
Sorry, I did miss your follow-up post. When I got your email I dug out the
modified code. I'm even more sorry to say that I introduced a dumb bug which
artificially increased the speed. I accidentally put i += size, instead of i
+= buffer.length. That artificially boosted the speed hugely by outputting a
small file duh.
Anyway with my modified code (posted below) I get:
11-28 20:58:09.859: INFO/speedtest(850): speed test a: 1370
11-28 20:58:09.889: INFO/speedtest(850): speed test b: 31
which I think is in keeping with your figures (I wouldn't my mental
arithmetic). I do note however that this idiom in your code:
FileInputStream fis = openFileInput(speedtest);
fis.read(array);
fis.close();
is unreliable and only works by chance - in general there is no guarantee
that any read will fill a buffer unless otherwise noted in the
documentation.
Hope you didn't waste too much time on my mistake!
Tom.
2008/11/28 __ [EMAIL PROTECTED]
I ran some more extensive tests and got the following:
WRITING:
one byte at a time written to BufferedOutputStream: 155kb/sec
whole array written to BufferedOutputStream: 450kb/sec
one byte at a time written to FileOutputStream: 8kb/sec
whole array written to FileOutputStream: 453kb/sec
READING:
one byte at a time read from BufferedInputStream: 221kb/sec
whole array read from BufferedInputStream: 47850kb/sec
one byte at a time read from FileInputStream: 9kb/sec
whole array read from FileInputStream: 31604kb/sec
(The reading results are a little artificial as I didn't attempt any
sort of buffer flush between tests...)
This shows that (in the writing case) writing single bytes to a
BufferedOutputStream has about a 3x overhead over writing an array to
a BufferedOutputStream or FileOutputStream, but writing whole arrays
to either buffered or unbuffered streams still does not come close to
the numbers you gave. (My arrays are much larger than the default
buffer size of 8kb, but that shouldn't make much difference if you
were reading actual IO throughput numbers...)
Anyway the overall result is still an order of magnitude slower than
it should be, in the fastest case (using arrays).
The code is as follows. (The two slowest cases are commented-out.) I
get similar numbers using NIO channels. What am I doing differently
from you?
--
int size = 5 * 1024 * 1024;
byte[] array = new byte[size];
long startTime = System.currentTimeMillis();
BufferedOutputStream bos = new
BufferedOutputStream(openFileOutput
(speedtest, MODE_PRIVATE));
for (int i = 0; i size; i++)
bos.write((byte) 0);
bos.close();
Log.i(speedtest, one byte at a time written to
BufferedOutputStream: + ((size / 1024.0) / ((System.currentTimeMillis
() - startTime) / 1000.0)) + kb/sec);
// startTime = System.currentTimeMillis();
// FileOutputStream fos = openFileOutput(speedtest,
MODE_PRIVATE);
// for (int i = 0; i size; i++)
// fos.write((byte) 0);
// fos.close();
// Log.i(speedtest, one byte at a time written to
FileOutputStream: + ((size / 1024.0) / ((System.currentTimeMillis()
- startTime) / 1000.0)) + kb/sec);
startTime = System.currentTimeMillis();
bos = new
BufferedOutputStream(openFileOutput(speedtest,
MODE_PRIVATE));
bos.write(array);
bos.close();
Log.i(speedtest, whole array
[android-developers] Restoration of SMS reading capability.
Will the capability for applications to observe incoming SMS messages be restored in future releases? (There's a permission, but no public API which is incongruous) I am already aware that the Intents of former SDK releases continue to work but I'm interested in whether there is a commitment to support equivalent functionality in the future. Tom. --~--~-~--~~~---~--~~ 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: Android Source Code Now Available
Al, Android requires three (extrinsic) things: users, carriers and developers. Any particular feature/restriction may be independently regarded as good or bad by the members of these three groups. Seeing particular security related restrictions only within the narrow context of what suits developers and some users, ignores the importance of carriers in cementing Android as a widely deployed mobile platform. Historically, for reasons I'm not knowledgeable enough to describe, carriers have wielded a great deal of power over the devices and applications that operate on their networks and as a consequence developers are rightly wary of any constraints put on their applications. Nevertheless, it's difficult to see Android as anything but a huge leap forward in terms of open mobile application development; criticisms over the simplifications used to describe elements of this hugely complex technology, don't change that. Tom. On Oct 22, 6:50 pm, Al Sutton [EMAIL PROTECTED] wrote: It's not necessarily what hasn't been released in documentation/source form, it's the measures which could be seen as steps taken to deliberately ensure that competitors can't access the same functionality as is available to approved applications which have been signed by the platform certificate. From what you've said it is impossible for anyone else to deliver an updater which will allow the user to install an updated version of the application without having to go through the system UI (Does Marketplace have to do that?) . It would be impossible for a third party to write a comprehensive dialling interface because it would be blocked from making emergency services calls (Is the shipped dialler blocked from doing that?). It took a lot of complaints to get the anti-trust suits started, and they were all based around functionality which wasn't available to third parties, isn't that what you've just said Android has? Al. hackbod wrote: On Oct 22, 12:49 am, Al Sutton [EMAIL PROTECTED] wrote: Friendly suggestion, read up on the lawsuits against Microsoft for not releasing API details (here's a recent onehttp://www.theregister.co.uk/2008/02/21/microsoft_goes_open/) http://git.source.android.com/ Exactly what details haven't been released? -- Al Sutton W:www.alsutton.com B: alsutton.wordpress.com T: twitter.com/alsutton --~--~-~--~~~---~--~~ 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] Changing the gravity of titles in Activity themes
It doesn't appear to be possible to change text alignment (gravity) using android:windowTitleStyle or any of the related properties. Can anyone tell me if this is an intentional limitation, a bug, or a mistake on my part? Thanks, Tom. --~--~-~--~~~---~--~~ 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] Using the battery state
The scenario is that I am writing a small app that I want to run in the background only when the device is charging. My problem is that this appears to impossible to achieve. The documentation helpfully informs me that ACTION_BATTERY_CHANGED intents cannot be received through components declared in manifests (Why this is this? I'm interested), instead Context.registerReceiver() must be used. But this method cannot be called from a BroadcastReceiver - again the documentation is clear on this point. I am assuming that any dynamically registered BroadcastReceiver is bound to the lifetime of the Component that registered it (Is this correct? The documentation appears to be silent on this point). And since I don't want my application running unless the device is being powered, I don't have a suitably long-lived component to register it under. The result is that I can't seem to obtain battery state notifications in any way that is useful for starting the work of my application. My next thought was to poll: use the AlarmManager to periodically run the BroadcastReceiver, poll the state of the battery, and only do the work when the battery is in the desired state. But (and this was a surprise) there doesn't appear to be any method in the API for polling the battery state. So I can't see that approach working either. Now it's seems quite possible to me that I'm missing something very simple and obvious which can resolve this (please put me out of my misery), but apart from obvious half-arsed approaches that run a service in the background to monitor the battery state - a total waste of resources for something that is intended to run just a couple of minutes a day - I just can't see any way of doing this. Is it really the case that it's impossible to start an application in response to a change in battery state? Tom. --~--~-~--~~~---~--~~ 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] Settings Application and Preferences
Could someone who knows (probably a Google engineer) kindly confirm that the Settings application (which has never been available on the emulator) aggregates preference Activities from installed apps?. And if so, do they need an intent filter containing the CATEGORY_PREFERENCE. And if this guess is correct, exactly what needs to be put into the IntentFilter for this to work? Thanks, Tom. --~--~-~--~~~---~--~~ 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: Possible bug in ListPreference
Okay, I think this probably isn't a bug in the preferences now, but I'm still a little in the dark. One issue is that (as far as I can tell) the array resource type isn't documented, at least it doesn't appear in: http://code.google.com/android/reference/available-resources.html Looking at the ApiDemos I see that string-array elements are supported, in addition to plain array elements; a little investigation showed that integer-array elements are also supported. Changing the array to string-array seems to fix the problem. But it's not documented that this required. I'm left guessing that array resources defined with an array element are automatically coerced into types in a way that causes ListPreference instances to fail. Tom. On Sep 19, 11:57 pm, tomgibara [EMAIL PROTECTED] wrote: This is probably a bug in the Preferences framework, but I'm not particularly familiar with the API and the documentation is a little sparse, so I thought I'd check first... Is there a restriction on the strings that can be used in the entryValues array for a ListPreference? I define the following two arrays: array name=pref_delay_entries item30 minutes/item item1 hour/item item2 hours/item item4 hours/item item12 hours/item itemday/item /array array name=pref_delay_values item180/item item360/item item720/item item1440/item item4320/item item8640/item /array For use in the following ListPreference: ListPreference android:key=delay android:defaultValue=360 android:title=@string/pref_delay_title android:summary=@string/pref_delay_summary android:entries=@array/pref_delay_entries android:entryValues=@array/pref_delay_values android:dialogTitle=@string/pref_delay_dialog_title / That's it, very simple. Running my PreferenceActivity and attempting to open the dialog (SDK 0.9 beta) results in the following exception: java.lang.NullPointerException at android.preference.ListPreference.findIndexOfValue(ListPreference.java: 169) at android.preference.ListPreference.getValueIndex(ListPreference.java: 178) at android.preference.ListPreference.onPrepareDialogBuilder(ListPreference.jav a: 190) at android.preference.DialogPreference.showDialog(DialogPreference.java: 289) at android.preference.DialogPreference.onClick(DialogPreference.java: 260) at android.preference.Preference.performClick(Preference.java:804) at android.preference.PreferenceScreen.onItemClick(PreferenceScreen.java: 182) ... Changing the elements of the pref_delay_values to something other than numbers removes the exception. --~--~-~--~~~---~--~~ 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] Possible bug in ListPreference
This is probably a bug in the Preferences framework, but I'm not particularly familiar with the API and the documentation is a little sparse, so I thought I'd check first... Is there a restriction on the strings that can be used in the entryValues array for a ListPreference? I define the following two arrays: array name=pref_delay_entries item30 minutes/item item1 hour/item item2 hours/item item4 hours/item item12 hours/item itemday/item /array array name=pref_delay_values item180/item item360/item item720/item item1440/item item4320/item item8640/item /array For use in the following ListPreference: ListPreference android:key=delay android:defaultValue=360 android:title=@string/pref_delay_title android:summary=@string/pref_delay_summary android:entries=@array/pref_delay_entries android:entryValues=@array/pref_delay_values android:dialogTitle=@string/pref_delay_dialog_title / That's it, very simple. Running my PreferenceActivity and attempting to open the dialog (SDK 0.9 beta) results in the following exception: java.lang.NullPointerException at android.preference.ListPreference.findIndexOfValue(ListPreference.java: 169) at android.preference.ListPreference.getValueIndex(ListPreference.java: 178) at android.preference.ListPreference.onPrepareDialogBuilder(ListPreference.java: 190) at android.preference.DialogPreference.showDialog(DialogPreference.java: 289) at android.preference.DialogPreference.onClick(DialogPreference.java: 260) at android.preference.Preference.performClick(Preference.java:804) at android.preference.PreferenceScreen.onItemClick(PreferenceScreen.java: 182) ... Changing the elements of the pref_delay_values to something other than numbers removes the exception. --~--~-~--~~~---~--~~ 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] Passing Bitmaps via Intents (redux)
How does the following documentation for MediaPlayer.ACTION_IMAGE_CAPTURE: Standard Intent action that can be sent to have the media application capture an image and return it. The image is returned as a Bitmap object in the extra field. square with hackbod's informed commentary here: http://groups.google.com/group/android-developers/msg/a0ae2e6455684245 Quoting hackbod: Currently if you put a bitmap in an Intent, it will get copied to the other process. In fact, it is worse than that: it needs to first go through the system process before being sent to the target process, so it gets copied twice. This is definitely not something you want to do with anything but a small bitmap. Has something changed which now makes passing Bitmaps via Bundles acceptable? --~--~-~--~~~---~--~~ 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] Announcing the new Android 0.9 SDK beta! http://android-developers.blogspot.com/2008/08/announcing-beta-release-of-android-sdk.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Passing Bitmaps via Intents (redux)
Doesn't the presence of this action on the MediaPlayer suggest that it will be returning large images? Or am I misunderstanding the intention of this action? On Aug 20, 11:13 pm, Romain Guy [EMAIL PROTECTED] wrote: Bitmaps can be passed as extras in Intents. That's how Home can create shortcuts with custom icons (for instance the photo of your contact.) However, it is expensive to do so and you should really not pass large bitmaps through Intents (Home uses 48x48 bitmaps.) On Wed, Aug 20, 2008 at 2:57 PM, tomgibara [EMAIL PROTECTED] wrote: How does the following documentation for MediaPlayer.ACTION_IMAGE_CAPTURE: Standard Intent action that can be sent to have the media application capture an image and return it. The image is returned as a Bitmap object in the extra field. square with hackbod's informed commentary here: http://groups.google.com/group/android-developers/msg/a0ae2e6455684245 Quoting hackbod: Currently if you put a bitmap in an Intent, it will get copied to the other process. In fact, it is worse than that: it needs to first go through the system process before being sent to the target process, so it gets copied twice. This is definitely not something you want to do with anything but a small bitmap. Has something changed which now makes passing Bitmaps via Bundles acceptable? -- Romain Guywww.curious-creature.org --~--~-~--~~~---~--~~ 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] Announcing the new Android 0.9 SDK beta! http://android-developers.blogspot.com/2008/08/announcing-beta-release-of-android-sdk.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Accessing the IMEI in 0.9
Just in case anyone else is looking to get the IMEI: I was being a klutz and had overlooked TelephonyManager not realizing that getDeviceId() returns the IMEI. Also TelephonyManager.getDefault() seems to provide a context free way of accessing the service. Tom. On Aug 20, 11:12 pm, Romain Guy [EMAIL PROTECTED] wrote: Use Context.getSystemService(TELEPHONY_SERVICE) to get access to the TelephonyManager. On Wed, Aug 20, 2008 at 3:05 PM, tomgibara [EMAIL PROTECTED] wrote: The changes overview for 0.9 states that: Several GSM subscriber and device-related system properties are moved to new permission-checked API. You can now access these phone/ subscriber properties through the new PhoneSubInfoManager, using the IPhoneSubInfo interface. PhoneSubInfoManager doesn't exist and the PhoneSubInfo and IPhoneSubInfo classes reside in the internal telephony package. So how do we access the IMEI? -- Romain Guywww.curious-creature.org --~--~-~--~~~---~--~~ 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] Announcing the new Android 0.9 SDK beta! http://android-developers.blogspot.com/2008/08/announcing-beta-release-of-android-sdk.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Taking care of proxy Internet access for Dev Challenge?
It shows how much I have to learn :) Thanks for setting me straight. I think my comments regarding the ADC still stand though. Warning: more ill informed follows. I always had the impression that mobile phones and their like would use gateways (yes proxies I guess) that would be determined and controlled by the operator, but (naively I'm sure) thought that this would be baked into the network stack below the application level. I can imagine ways in which my simplistic thinking might break down for J2ME, but with a unified stack like Android, surely requiring every application to address proxying individually is silly. Tom. On Apr 10, 5:30 pm, Stefan Handschuh [EMAIL PROTECTED] wrote: Proxies are the STANDARD-way for you mobile device to connect to the internet. I have never owned a device that doesn't use a proxy server. But: Android makes no devision into HTTP and HTTPS which is a huge disadvantage I'm becoming confused with all of the guidance being given to entrants of the ADC. One the one hand, the flavour of the posts in the Challenge group is that we are not permitted to instruct the user to do anything to their emulator. This seems to include pushing files to it, installing an supplied SD Card image or even installing more than one application package. But unless I have been totally left behind (and its quite possible), this is just what you need to do to Android's own browser to use a proxy: http://groups.google.com/group/android-developers/browse_frm/thread/e... Further to this, there is even no way to make the built-in Google Maps application to work: http://groups.google.com/group/android-developers/browse_frm/thread/b... Perhaps I'm mistaken in this, I don't have much experience with mobile phone development, but isn't a proxy configuration something of an abnormality for a mobile device? Tom. On Apr 9, 10:43 pm, David McLaughlin (Android Advocate) [EMAIL PROTECTED] wrote: Yes; just as your end-user may end up using your app from behind a proxy, you should assume that your judges may also. Thanks, David On Apr 8, 8:54 am, joos [EMAIL PROTECTED] wrote: Hello, I am building a client/server application for the Developer Challenge where my Android Client accesses some Server to retrieve information. Does anyone know if I have to take care handling Internet access through a firewall/proxy within my application? (I would have to read the proxy values from the settings.db and add the values to my openConnection call - I guess) Greetings, Joos --~--~-~--~~~---~--~~ 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] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Slow Bitmap operations
Doing pixel-level processing in within the Dalvik VM will necessarily incur the overhead of copying the pixel data into the VM heap. As others have suggested, this needs be done to gain fast access to the pixel data. But I doubt that this is the bottleneck, it's certainly the interpreted nature of the Dalvik VM. There's a useful detailed post about the overhead here: http://groups.google.com/group/android-developers/browse_frm/thread/60e00ab2de9abb2d/9ee69bafad211e87#9ee69bafad211e87 If my understanding is correct, this means that an operation like an integer add costs 1 CPU cycle, but the VM adds an overhead of approximately 20 cycles to every instruction, so code which has a performs a large number of fast operations (such as image processing) is going to be very badly penalized. To put this more clearly, lets hypothesize that a method call takes 20 CPU cycles (I've plucked that figure out of mid-air) then the interpreter overhead means that an integer add is only twice as fast as a method call. This is going to skew performance characteristics dramatically away from the norms that developers expect. But I think there are reasons to be hopeful. In this post, Dan Morrill indicates that a just-in-time compiler is definitely on the Dalvik roadmap: http://groups.google.com/group/android-developers/browse_frm/thread/c4a8b4d97f408b17/6574e60b4add1fc4 I don't know where on the roadmap, that might be. Also the potential benefits of a JIT are probably very difficult to prejudge (due to issues that are beyond my experience, such as cache considerations). Nevertheless I did a very quick analysis using the data here: http://shootout.alioth.debian.org/ I compared, Sun's interpreter against Sun's hotspot compiler and chose the median of the execution-time ratios. This (totally ridiculous) procedure gave me a figure of about 8x speed improvement (of course this figure will differ dramatically based on the application and many other factors). It was just a very quick way to get an estimate without actually needing to write an AOT or JIT compiler which would be the only reliable way. I've gone a bit off topic, but I just thought some background might help. Tom. On Mar 30, 12:19 pm, saurabh [EMAIL PROTECTED] wrote: Hi, I am working on an image processing application. The job is simple: 1. read an image into a Bitmap object A, 2. create a new Bitmap object B of the same dimensions, 3. iterate over Bitmap A examining each pixel and copying it to B if it satisfies some conditions, 4. display Bitmap B using ImageView. The trouble is that though the application is working correctly, it is too slow to use. For a JPEG image of 547x450 resolution, the application takes 66 seconds to produce the final output. The getPixel function seems to be taking approx 1/100 of a second. Similarly, checking whether each pixel satisfies the condition and then copying it to Bitmap B also takes approx 1/100 second. Therefore, performing these 2 operations for 547*450 = 246150 pixels takes a lot of time. Is there any way to do this faster? I hope to use this for processing each frame of a video in real-time. So, processing each picture must not take more than a 1/20 of a second. --~--~-~--~~~---~--~~ 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] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
