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
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 implemen
t; On Thu, Feb 5, 2009 at 2:08 PM, tomgibara 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) {
>
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 = c
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);
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
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 develo
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 rec
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
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
I've noticed that there is an android.security package in the android
jar which is not listed in the package index:
http://code.google.com/android/reference/packages.html
It appears to contain wrappers for native MessageDigest
implementations. Is there any chance that these could be added to the
s defined with an 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
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 followi
n 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:
>
> &g
ntents. 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
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
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://
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
c
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
supplie
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 o
20 matches
Mail list logo
