- Horizontal ListView Adapter [3 Updates]
- 9.png file not spanning the LinearLayout when android:paddingBottom is specified [1 Update]
- In-app purchase problems resulting from accidental Public Key swap in update? [2 Updates]
- Knet Payment Integration [1 Update]
- heatmap using TileOverlay on Google Maps v2 [1 Update]
- Home button not working as it is supposed to. [2 Updates]
- Charx <firstname.lastname@example.org> Jun 29 12:52AM -0700
- Piren <email@example.com> Jun 29 11:51PM -0700
Ironically, your own reply also answers your question... obviously, others
have missed it as well.
On Saturday, June 29, 2013 10:52:54 AM UTC+3, Charx wrote:
- "Παύλος-Πέτρος Τουρνάρης" <firstname.lastname@example.org> Jun 30 10:20AM +0300
If you are so smartass then Google before asking here!
*Android & Software Developer*
- Piren <email@example.com> Jun 29 11:54PM -0700
Part of what 9patches do is define padding... if you define them on your
own you'll overwrite the settings provided by the 9patch.
On Saturday, June 29, 2013 2:10:36 AM UTC+3, Shri wrote:
- kadmos <firstname.lastname@example.org> Jun 29 02:29PM -0700
We have been having serious problems with an app of ours since an update in
May - many reports/complaints of failure at in-app purchase point of sale -
something which had preciously been working fine. While attempting to
resolve the issue it was discovered that the app update, which was a major
code overhaul, was published with the wrong Public Key - the Public Key
from another of our apps from which code was ported. After updating again
with the correct Public Key, there were still problems with in-app
purchases working correctly on some devices. When a new account/new credit
card was used however, in-app purchases worked flawlessly on a 'problem'
device, which has me now thinking that the swapped Public Key has caused
problems with peoples' Play accounts who attempted to make purchases with
the build installed that had the incorrect Public Key - one used in another
Trying to get feedback to see if I am on the right track with this and how
the issue could possibly be resolved (i.e. removing current in-app purchase
items and creating new ones perhaps?) or if I am wrong and need to be
examining my code more throughly against different brand devices/OS
Any advice appreciated.
- kadmos <email@example.com> Jun 29 11:22PM -0700
It had *previously been working fine, not 'preciously' ...
- "Ali S. Rangwala" <firstname.lastname@example.org> Jun 30 06:42AM +0300
We have our shopping cart application in android and want to integrate with
Knet payment gateway.
Can someone share some pointers or references on how to achieve this.
Looked around for php based solution but could not find specific to
android. Would like to hear your experience if in similar requirement.
Thanks for your time.
- raj <email@example.com> Jun 29 05:58PM -0700
Thanks for the response.
I am exactly using the same method, as in using shapes(gradient circles) .
And I know that zooming the map will auto zoom the images as well, but that
will be against the kind of heatmap I need. My heatmap's density is based
on the number of adjoining points, and so if a cluster was initially
red(high density), then zooming in will move the markers farther, reducing
the density and so will have to redraw based on the current zoom layout.
I am okay with redrawing when the zoom changes(i don't see any other way
either, unless we create and store all images), but my main problem is that
the overlayed layer is restricted based on the screen size(match-parent,
and parent's size is fixed based on map container size), and so the image
created on the overlayed layer is only for the markers currently visible on
screen. Drawing circles directly on map will not work, as I don't think we
can change the colors by pixel(the way we can do on a bitmap)
On Friday, 28 June 2013 07:16:52 UTC-4, gjs wrote:
- vani reddy <firstname.lastname@example.org> Jun 29 01:27PM +0530
When i touch the Home button and open my app , my app doesn't open the
screen where it closed.How to get this ?
For all the actiivties I have given android:noHistory="true"
and HomeScreen to be android:noHistory="true"
in the manifest.
- RichardC <email@example.com> Jun 29 05:19AM -0700
Remove android:noHistory="true" see:
My emphasis below
android:noHistoryWhether or not the activity should be removed from the
activity stack and finished (its finish()<http://developer.android.com/reference/android/app/Activity.html#finish()>method
called) when the user navigates away from it and it's no longer visible on
screen — "true" if it should be finished, and "false" if not. The default
value is "false".
*A value of "true" means that the activity will not leave a historical
trace. It will not remain in the activity stack for the task, so the user
will not be able to return to it*.
On Saturday, June 29, 2013 8:57:46 AM UTC+1, vani wrote:
You received this message because you are subscribed to the Google Group android-developers.
You can post via email.
To unsubscribe from this group, send an empty message.
For more options, visit this group.
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to
For more options, visit this group at
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 email@example.com.
For more options, visit https://groups.google.com/groups/opt_out.