[android-developers] post data not re-submitted on webview "back" in 4.4.4
Anyone run into this? Activity creates a WebView and sets cache mode = LOAD_NO_CACHE, then calls WebView.postUrl() with a URL and some POST data. The resulting webpage has a hyperlink, which the user tap to access a second page. He then taps the device back button, which I intercept and turn into a goBack() call on the WebView. On a 4.2.2 device this results in the original POST request being re-sent along with the original data supplied to WebView.postUrl(). On a 4.4.4 device the device still makes a POST request, but without the POST data. Verified this is this case by way of server logs. -- 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 --- 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. For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: manifestpackage property of AaptExecTask removed?
Disregard. Problem was on my end. On Monday, May 19, 2014 3:44:59 PM UTC-5, Jay Howard wrote: > > Am I imagining things, or was support for the "manifestpackage" property > AaptExecTask removed in 22.6.3? This used to map to the command line > option "--rename-manifest-package". > > If I'm not imagining things, any reason it was removed? I found it very > helpful. > > Here's the functionality I'm referring to: > > https://code.google.com/p/android/issues/detail?id=21336 > -- 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 --- 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. For more options, visit https://groups.google.com/d/optout.
[android-developers] manifestpackage property of AaptExecTask removed?
Am I imagining things, or was support for the "manifestpackage" property AaptExecTask removed in 22.6.3? This used to map to the command line option "--rename-manifest-package". If I'm not imagining things, any reason it was removed? I found it very helpful. Here's the functionality I'm referring to: https://code.google.com/p/android/issues/detail?id=21336 -- 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 --- 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. For more options, visit https://groups.google.com/d/optout.
[android-developers] listview item layout change in SDK 18?
The layout of ListView items seems to have changed in SDK 18. I've created an example project that highlights the different behavior when targetSdkVersio = 17 vs. 18: https://drive.google.com/file/d/0B6DvDY2BvxUTZHUxTHkzNUZvVDg Additionally I've started a thread on StackOverflow (with screen shots) here: http://stackoverflow.com/questions/21442381/how-to-work-around-change-in-list-item-layout-behavior-change-between-sdk-17-and Previously another StackOverflow user posted a similar question but got no response: http://stackoverflow.com/questions/17993415/listview-item-layout-differs-between-targetsdkversion-17-and-targetsdkversion My question: is there a workaround that would allow me to target SDK 18+ but keep the layout behavior from 17? Maybe manually calling layout-related methods on the views in question? -- 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 --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[android-developers] Re: buggy legacy options menu on Samsung S4
First of all, thanks for taking the time to build the demo app. It's
frustrating that I'm no closer to figuring out why this is happening, but
at least it doesn't seem to be an issue on *all* S4 devices.
I wonder if the trait that triggers the behavior isn't hardware, but some
configurable option that just happens to have one value on your phone and a
different value on mine. I can't think of what it might be, though. When
the options menu is in the "bad" state it's as if the taps aren't even
registered by the device. I enabled "Show Pointer Location" from developer
options, though, and I see visual feedback to indicate that taps are
occurring inside the bounds of the menu items I'm attempting to select.
On Thursday, August 8, 2013 5:19:54 AM UTC-5, gjs wrote:
>
> Hi,
>
> I downloaded, unzipped & built you app in Eclipse from the source, without
> any alterations. It did run OK on my Samsung Galaxy S4 (Android V4.2.2).
>
> It did *not* exhibit the issues you originally mentioned, all menu items
> working ok with the text for each item showing up ok & immediately for the
> various key combinations include selecting 'more' and pressing that
> hardware back button then pressing the original menu options, all was ok.
>
> I have attached a screenshot showing the device details used for this
> test. It's a 4G LTE 'international' version and is an 'unlocked' device,
> not rooted & not from a carrier, it came out of Hong Kong, I am using it in
> Australia.
>
> Perhaps the issue is specific to some subset of these devices?
>
> Regards
> ,
> On Wednesday, August 7, 2013 11:48:28 PM UTC+10, Jay Howard wrote:
>>
>> How frustrating. Though, I'm glad to know it works for someone else; it
>> gives me some hope that a workaround can be found.
>>
>> Couple questions about the app that's working correctly:
>>
>> 1. What's the value of "targetSdkVersion" in your manifest? (Mine is
>> "9").
>> 2. What's the value of "target" in your project.properties file? (Mine
>> is "Google Inc.:Google APIs:14").
>> 3. Do you use a default theme for your app? If so, which? (Mine is
>> "Theme.NoTitleBar").
>>
>> Is there any chance I could impose on you to build and run my demo app
>> ("OptionsMenu.zip" shared on Google Drive) on your S4? The zip file
>> contains a complete Eclipse project minus the "bin" and "gen" dirs, which
>> are auto-generated. The app is trivial and does nothing but demonstrate
>> the bad behavior.
>>
>> If possible, I'd like to determine whether this is an issue on all S4s or
>> if the device I'm using is "special" in some way.
>>
>> On Wednesday, August 7, 2013 3:51:02 AM UTC-5, gjs wrote:
>>>
>>> Hi,
>>>
>>> I have a Samsung Galaxy S4 with Android 4.2.2 plus an app & activities
>>> that have legacy option menus with more than six items, including "more"
>>> that uses onCreateOptionsMenu() as well as onPrepareOptionsMenu() and
>>> onOptionsItemSelected().
>>>
>>> When I try to reproduce your steps I do *not* get the same issues you
>>> mention, all menu options work OK when using the key combinations you
>>> mention.
>>>
>>> The main difference I can see when looking at your code sample on SO, is
>>> that I do *not* use an inflator to inflate the menu items from a static xml
>>> file in onCreateOptionsMenu().
>>>
>>> Instead I am creating the menu (& sub menu) items in java code
>>> dynamically at runtime, within onCreateOptionsMenu() & also
>>> onPrepareOptionsMenu(), adding & removing menu items to & from the menu
>>> object 'by hand', the reason I'm doing this is that the menu items need to
>>> vary according to the current context of the activity, perhaps you could
>>> try the same & see if that works ok on an S4.
>>>
>>> Another suggestion, instead of creating menu items dynamically at
>>> runtime in java code - which is probably not a recommended practice, is to
>>> try your inflator code within onPrepareOptionsMenu(), remembering to
>>> call menu.clear() before the inflator and see if that works any better.
>>>
>>> See for details
>>> http://developer.android.com/reference/android/app/Activity.html#onPrepareOptionsMenu(android.view.Menu)
>>>
>>> Good luck.
>>>
>>> On Wednesday, Au
[android-developers] Re: buggy legacy options menu on Samsung S4
The "next" version of my employer's app ditches the options menu and uses the navigation drawer for most things. Unfortunately, that version isn't going to be rolled out for a few months. I was hoping to find a fix for the current version that still uses a legacy options menu. On Wednesday, August 7, 2013 3:30:36 PM UTC-5, Nobu Games wrote: > > Sorry, I did not realize, there was a ZIP file. I was thinking the > download button is just some big graphic and my "visual parser" in my head > discarded it :-D > > Your activity is as simple as it can get and I cannot spot any mistake. It > really may be just some rare firmware glitch and nothing much to worry > about. Unfortunately we have to deal with these random device-specific > oddities all the time. > > If you really want to work around that issue you could make use of an > action bar and move the most important and relevant menu options there. > > > On Tuesday, August 6, 2013 11:01:17 AM UTC-5, Jay Howard wrote: >> >> I'm seeing the following behavior (on a Samsung S4, but potentially also >> on other Samsung devices) in an app that uses a "legacy" options menu: >> >> 1. User taps hardware menu button to bring up options menu. There are >> more than six items in the menu. >> 2. User taps the bottom-right "more" button to access the overflow menu >> items. >> 3. User taps the hardware back button to return to the initial options >> menu. >> 4. User taps any combination of menu items, potentially multiple times >> each. Nothing happens. onOptionsItemSelected() is never called. >> 5. User taps the hardware back button to close the options menu. >> 6. User taps the hardware menu button to display the options menu again. >> At this point, onOptionsItemSelected() is called in quick succession for >> each menu item the user tapped when the menu was previously displayed. >> >> Can anyone advise? >> >> I've created a simple demo app to demonstrates the behavior along with a >> video that shows exactly what I'm talking about. There's also a screenshot >> with device info for the device I tested on. I've shared them here: >> >> https://drive.google.com/folderview?id=0B6DvDY2BvxUTRUNxWFVUNDl4QlU >> >> The demo app implements onCreateOptionsMenu() and onOptionsItemSelected() >> nearly identically to the examples given here: >> >> http://developer.android.com/guide/topics/ui/menus.html#options-menu >> >> I posted this question on StackOverflow a while back, but none of the >> responses were helpful: >> >> >> http://stackoverflow.com/questions/17180909/options-menu-locks-up-on-galaxy-s4 >> > -- 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 --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[android-developers] Re: buggy legacy options menu on Samsung S4
It's part of that zip file, but here is the contents of my activity, my
app's manifest and the xml for the menu items:
MainActivity.java:
package com.example.optionsmenu;
import android.app.Activity;
import android.os.Bundle;
import android.view.Menu;
import android.view.MenuInflater;
import android.view.MenuItem;
import android.view.ViewGroup;
import android.widget.TextView;
public class MainActivity extends Activity {
private ViewGroup mContainer;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mContainer = (ViewGroup) findViewById(R.id.container);
}
@Override
public final boolean onCreateOptionsMenu(Menu menu) {
MenuInflater inflater = getMenuInflater();
inflater.inflate(R.menu.main, menu);
return true;
}
@Override
public boolean onOptionsItemSelected(MenuItem item) {
switch (item.getItemId()) {
case R.id.action_a:
case R.id.action_b:
case R.id.action_c:
case R.id.action_d:
case R.id.action_e:
case R.id.action_f:
case R.id.action_g:
case R.id.action_h:
final TextView textview = new TextView(this);
textview.setText(item.getTitle());
mContainer.addView(textview);
return true;
default:
return super.onOptionsItemSelected(item);
}
}
}
AndroidManifest.xml:
http://schemas.android.com/apk/res/android";
package="com.example.optionsmenu"
android:versionCode="1"
android:versionName="1.0" >
main.xml:
http://schemas.android.com/apk/res/android"; >
On Wednesday, August 7, 2013 2:40:37 PM UTC-5, Nobu Games wrote:
>
> Could you post your Activity code?
>
> On Tuesday, August 6, 2013 11:01:17 AM UTC-5, Jay Howard wrote:
>>
>> I'm seeing the following behavior (on a Samsung S4, but potentially also
>> on other Samsung devices) in an app that uses a "legacy" options menu:
>>
>> 1. User taps hardware menu button to bring up options menu. There are
>> more than six items in the menu.
>> 2. User taps the bottom-right "more" button to access the overflow menu
>> items.
>> 3. User taps the hardware back button to return to the initial options
>> menu.
>> 4. User taps any combination of menu items, potentially multiple times
>> each. Nothing happens. onOptionsItemSelected() is never called.
>> 5. User taps the hardware back button to close the options menu.
>> 6. User taps the hardware menu button to display the options menu again.
>> At this point, onOptionsItemSelected() is called in quick succession for
>> each menu item the user tapped when the menu was previously displayed.
>>
>> Can anyone advise?
>>
>> I've created a simple demo app to demonstrates the behavior along with a
>> video that shows exactly what I'm talking about. There's also a screenshot
>> with device info for the device I tested on. I've shared them here:
>>
>> https://drive.google.com/folderview?id=0B6DvDY2BvxUTRUNxWFVUNDl4QlU
>>
>> The demo app implements onCreateOptionsMenu() and onOptionsItemSelected()
>> nearly identically to the examples given here:
>>
>> http://developer.android.com/guide/topics/ui/menus.html#options-menu
>>
>> I posted this question on StackOverflow a while back, but none of the
>> responses were helpful:
>>
>>
>> http://stackoverflow.com/questions/17180909/options-menu-locks-up-on-galaxy-s4
>>
>
--
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
---
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.
For more options, visit https://groups.google.com/groups/opt_out.
[android-developers] Re: buggy legacy options menu on Samsung S4
I tried the following with no success: 1. Recreating the menu in onPrepareOptionsMenu() each time it's called and making onCreateOptionsMenu() into a no-op. 2. Programmatically instantiating all the MenuItems (in onPrepareOptionsMenu()) instead of inflating them from XML. 3. Varying targetSdkVersion from "9" to "17". 4. Setting no default theme for my app in the manifest. Got the same buggy behavior every time. Maybe my phone is cursed. On Wednesday, August 7, 2013 3:51:02 AM UTC-5, gjs wrote: > > Hi, > > I have a Samsung Galaxy S4 with Android 4.2.2 plus an app & activities > that have legacy option menus with more than six items, including "more" > that uses onCreateOptionsMenu() as well as onPrepareOptionsMenu() and > onOptionsItemSelected(). > > When I try to reproduce your steps I do *not* get the same issues you > mention, all menu options work OK when using the key combinations you > mention. > > The main difference I can see when looking at your code sample on SO, is > that I do *not* use an inflator to inflate the menu items from a static xml > file in onCreateOptionsMenu(). > > Instead I am creating the menu (& sub menu) items in java code dynamically > at runtime, within onCreateOptionsMenu() & also onPrepareOptionsMenu(), > adding & removing menu items to & from the menu object 'by hand', the > reason I'm doing this is that the menu items need to vary according to the > current context of the activity, perhaps you could try the same & see if > that works ok on an S4. > > Another suggestion, instead of creating menu items dynamically at runtime > in java code - which is probably not a recommended practice, is to try your > inflator code within onPrepareOptionsMenu(), remembering to call > menu.clear() before the inflator and see if that works any better. > > See for details > http://developer.android.com/reference/android/app/Activity.html#onPrepareOptionsMenu(android.view.Menu) > > Good luck. > > On Wednesday, August 7, 2013 2:01:17 AM UTC+10, Jay Howard wrote: >> >> I'm seeing the following behavior (on a Samsung S4, but potentially also >> on other Samsung devices) in an app that uses a "legacy" options menu: >> >> 1. User taps hardware menu button to bring up options menu. There are >> more than six items in the menu. >> 2. User taps the bottom-right "more" button to access the overflow menu >> items. >> 3. User taps the hardware back button to return to the initial options >> menu. >> 4. User taps any combination of menu items, potentially multiple times >> each. Nothing happens. onOptionsItemSelected() is never called. >> 5. User taps the hardware back button to close the options menu. >> 6. User taps the hardware menu button to display the options menu again. >> At this point, onOptionsItemSelected() is called in quick succession for >> each menu item the user tapped when the menu was previously displayed. >> >> Can anyone advise? >> >> I've created a simple demo app to demonstrates the behavior along with a >> video that shows exactly what I'm talking about. There's also a screenshot >> with device info for the device I tested on. I've shared them here: >> >> https://drive.google.com/folderview?id=0B6DvDY2BvxUTRUNxWFVUNDl4QlU >> >> The demo app implements onCreateOptionsMenu() and onOptionsItemSelected() >> nearly identically to the examples given here: >> >> http://developer.android.com/guide/topics/ui/menus.html#options-menu >> >> I posted this question on StackOverflow a while back, but none of the >> responses were helpful: >> >> >> http://stackoverflow.com/questions/17180909/options-menu-locks-up-on-galaxy-s4 >> > -- 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 --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[android-developers] Re: buggy legacy options menu on Samsung S4
How frustrating. Though, I'm glad to know it works for someone else; it
gives me some hope that a workaround can be found.
Couple questions about the app that's working correctly:
1. What's the value of "targetSdkVersion" in your manifest? (Mine is "9").
2. What's the value of "target" in your project.properties file? (Mine is
"Google Inc.:Google APIs:14").
3. Do you use a default theme for your app? If so, which? (Mine is
"Theme.NoTitleBar").
Is there any chance I could impose on you to build and run my demo app
("OptionsMenu.zip" shared on Google Drive) on your S4? The zip file
contains a complete Eclipse project minus the "bin" and "gen" dirs, which
are auto-generated. The app is trivial and does nothing but demonstrate
the bad behavior.
If possible, I'd like to determine whether this is an issue on all S4s or
if the device I'm using is "special" in some way.
On Wednesday, August 7, 2013 3:51:02 AM UTC-5, gjs wrote:
>
> Hi,
>
> I have a Samsung Galaxy S4 with Android 4.2.2 plus an app & activities
> that have legacy option menus with more than six items, including "more"
> that uses onCreateOptionsMenu() as well as onPrepareOptionsMenu() and
> onOptionsItemSelected().
>
> When I try to reproduce your steps I do *not* get the same issues you
> mention, all menu options work OK when using the key combinations you
> mention.
>
> The main difference I can see when looking at your code sample on SO, is
> that I do *not* use an inflator to inflate the menu items from a static xml
> file in onCreateOptionsMenu().
>
> Instead I am creating the menu (& sub menu) items in java code dynamically
> at runtime, within onCreateOptionsMenu() & also onPrepareOptionsMenu(),
> adding & removing menu items to & from the menu object 'by hand', the
> reason I'm doing this is that the menu items need to vary according to the
> current context of the activity, perhaps you could try the same & see if
> that works ok on an S4.
>
> Another suggestion, instead of creating menu items dynamically at runtime
> in java code - which is probably not a recommended practice, is to try your
> inflator code within onPrepareOptionsMenu(), remembering to call
> menu.clear() before the inflator and see if that works any better.
>
> See for details
> http://developer.android.com/reference/android/app/Activity.html#onPrepareOptionsMenu(android.view.Menu)
>
> Good luck.
>
> On Wednesday, August 7, 2013 2:01:17 AM UTC+10, Jay Howard wrote:
>>
>> I'm seeing the following behavior (on a Samsung S4, but potentially also
>> on other Samsung devices) in an app that uses a "legacy" options menu:
>>
>> 1. User taps hardware menu button to bring up options menu. There are
>> more than six items in the menu.
>> 2. User taps the bottom-right "more" button to access the overflow menu
>> items.
>> 3. User taps the hardware back button to return to the initial options
>> menu.
>> 4. User taps any combination of menu items, potentially multiple times
>> each. Nothing happens. onOptionsItemSelected() is never called.
>> 5. User taps the hardware back button to close the options menu.
>> 6. User taps the hardware menu button to display the options menu again.
>> At this point, onOptionsItemSelected() is called in quick succession for
>> each menu item the user tapped when the menu was previously displayed.
>>
>> Can anyone advise?
>>
>> I've created a simple demo app to demonstrates the behavior along with a
>> video that shows exactly what I'm talking about. There's also a screenshot
>> with device info for the device I tested on. I've shared them here:
>>
>> https://drive.google.com/folderview?id=0B6DvDY2BvxUTRUNxWFVUNDl4QlU
>>
>> The demo app implements onCreateOptionsMenu() and onOptionsItemSelected()
>> nearly identically to the examples given here:
>>
>> http://developer.android.com/guide/topics/ui/menus.html#options-menu
>>
>> I posted this question on StackOverflow a while back, but none of the
>> responses were helpful:
>>
>>
>> http://stackoverflow.com/questions/17180909/options-menu-locks-up-on-galaxy-s4
>>
>
--
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
---
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.
For more options, visit https://groups.google.com/groups/opt_out.
[android-developers] Re: Writing file to app folder
This may be a complete red herring, but I've noticed that certain Motorola phones don't behave well unless you use the Motorola-branded USB cable that shipped with the phone. For whatever reason, those particular phones don't work well with generic cables. On Tuesday, August 6, 2013 12:59:21 PM UTC-5, dashman wrote: > > I'm writing a data file to my app folder > > /Android/data//files > > and the file is visible from my android phone file explorer app. > > But when I use the desktop Windows file explorer - it's not visible. > > > This is how i'm writing the file out: > > File storageFolder = mContext.getExternalFilesDir(null); > > java.io.BufferedWriter out = new java.io.BufferedWriter( > new java.io.FileWriter( storageFolder.getAbsolutePath() + "/temp.txt") ); > > > As written above - the file is written out - verified. > > > > -- 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 --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[android-developers] buggy legacy options menu on Samsung S4
I'm seeing the following behavior (on a Samsung S4, but potentially also on other Samsung devices) in an app that uses a "legacy" options menu: 1. User taps hardware menu button to bring up options menu. There are more than six items in the menu. 2. User taps the bottom-right "more" button to access the overflow menu items. 3. User taps the hardware back button to return to the initial options menu. 4. User taps any combination of menu items, potentially multiple times each. Nothing happens. onOptionsItemSelected() is never called. 5. User taps the hardware back button to close the options menu. 6. User taps the hardware menu button to display the options menu again. At this point, onOptionsItemSelected() is called in quick succession for each menu item the user tapped when the menu was previously displayed. Can anyone advise? I've created a simple demo app to demonstrates the behavior along with a video that shows exactly what I'm talking about. There's also a screenshot with device info for the device I tested on. I've shared them here: https://drive.google.com/folderview?id=0B6DvDY2BvxUTRUNxWFVUNDl4QlU The demo app implements onCreateOptionsMenu() and onOptionsItemSelected() nearly identically to the examples given here: http://developer.android.com/guide/topics/ui/menus.html#options-menu I posted this question on StackOverflow a while back, but none of the responses were helpful: http://stackoverflow.com/questions/17180909/options-menu-locks-up-on-galaxy-s4 -- 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 --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [android-developers] Re: perform atomic message send/remove on a handler
Here's what I ended up doing:
1. Ensure that my timer class, which creates a Handler in its method
on the caller's thread, is always instantiated on the main thread.
2. My class is also a BroadcastReceiver, but onReceive() is guaranteed to
be called by the main thread so it can access the handler directly.
2. Structure each external method that accesses the handler (and that could
potentially be called from multiple threads) as follows:
private void doSomethingWithHandlerSync() {
// access the handler directly
}
public void doSomethingWithHandler() {
if (Thread.currentThread().equals(mHandler.getLooper().getThread())) {
doSomethingWithHandlerSync();
} else {
mHandler.post(new Runnable() {
@Override
public void run() {
doSomethingWithHandlerSync();
}
});
}
}
Does that thread check look right? Seems like it should be sufficient to
guarantee that doSomethingWithHandlerSync(), handleMessage() and
onReceive() will never execute concurrently.
On Tue, Oct 30, 2012 at 10:09 AM, Jay Howard wrote:
> Thanks so much for the response! If you'll indulge me with a few more
> questions...
>
> So I instantiate the handler in the onCreate() method of my Application,
> which I assume means it's tied to the UI thread.
>
> The method that removes and re-sends messages is called primarily on the
> UI thread, but can also be called from an IntentService that I use to
> handle network communication. Since the service is executed by a thread
> other than the UI thread it appears that I do need to synchronize.
>
> To give some more detail on my goals for this: I'm attempting to use the
> handler to track both user inactivity and server session expiration. The
> Service calls a "session refreshed" method to remove session-related
> delayed messages and re-add them with a new delay. The UI thread calls an
> "user activity occurred" method to indicate the user "did something"; that
> method removes inactivity-related delayed messages and re-adds them with a
> new delay.
>
> One other kink: I also have code to respond to SCREEN_ON and SCREEN_OFF.
> At screen off I remove all messages from the handler; at screen on I
> re-send each message that was queued at the point at which screen off
> occurred, albeit with a revised delay to account for the time that elapsed
> while the screen was off.
>
>
>
> On Tue, Oct 30, 2012 at 9:43 AM, Streets Of Boston <
> flyingdutc...@gmail.com> wrote:
>
>> It depends which thread is callling the code-snippet you show above (the
>> one calling 'removeMessage').
>>
>> If your code, calling 'removeMessage', is run on the same thread that is
>> tied to the *handler*, you're fine. The message you sent will not be
>> handled/run until your code finishes first. No extra work necessary.
>>
>> If your code, calling 'removeMessage' is run on another thread than the
>> one tied to the *handler*, you need to sync it up. This could be as
>> simple as send another message on that handler that will call
>> 'removeMessage': E.g.:
>> handler.post(new Runnable() {
>> public void run() {
>> // Right now, calling 'removeMessages', etc. is done
>> // on the handler's thread as well.
>> handler.removeMessages(MSG_**ONE);
>> handler.removeMessages(MSG_**TWO);
>> ...
>>
>> if (conditionOne)
>> handler.**sendEmptyMessageDelayed(MSG_**ONE, timeoutOne);
>>
>> if (conditionTwo)
>> handler.**sendEmptyMessageDelayed(MSG_**TWO, timeoutTwo);
>> }
>> });
>>
>> Since both the 'removeMessages' and 'sendEmptyMessageDelayed' are called
>> on 'handler' the Runnable needs to finish first before any other message
>> sent to 'handler' can be executed.
>>
>>
>> On Tuesday, October 30, 2012 9:17:39 AM UTC-4, Jay Howard wrote:
>>>
>>> I'm using a timer to manage timeout events, and would like to ensure
>>> that a particular method runs atomically without the handler issuing
>>> messages while the method is executing. Its basic form is:
>>>
>>> handler.removeMessages(MSG_**ONE);
>>> handler.removeMessages(MSG_**TWO);
>>> ...
>>>
>>> if (conditionOne)
>>> handler.**sendEmptyMessageDelayed(MSG_**ONE, timeoutOne);
>>>
>>> if (conditionTwo)
>>> handler.**sendEmptyMessageDelayed(MSG_**TWO, timeoutTwo);
>>>
>>> ...
>>>
>>> What I want to avoid is a situation where, before the removeMessages()
>>> calls execute, one of the messages
Re: [android-developers] Re: perform atomic message send/remove on a handler
Thanks so much for the response! If you'll indulge me with a few more
questions...
So I instantiate the handler in the onCreate() method of my Application,
which I assume means it's tied to the UI thread.
The method that removes and re-sends messages is called primarily on the UI
thread, but can also be called from an IntentService that I use to handle
network communication. Since the service is executed by a thread other
than the UI thread it appears that I do need to synchronize.
To give some more detail on my goals for this: I'm attempting to use the
handler to track both user inactivity and server session expiration. The
Service calls a "session refreshed" method to remove session-related
delayed messages and re-add them with a new delay. The UI thread calls an
"user activity occurred" method to indicate the user "did something"; that
method removes inactivity-related delayed messages and re-adds them with a
new delay.
One other kink: I also have code to respond to SCREEN_ON and SCREEN_OFF.
At screen off I remove all messages from the handler; at screen on I
re-send each message that was queued at the point at which screen off
occurred, albeit with a revised delay to account for the time that elapsed
while the screen was off.
On Tue, Oct 30, 2012 at 9:43 AM, Streets Of Boston
wrote:
> It depends which thread is callling the code-snippet you show above (the
> one calling 'removeMessage').
>
> If your code, calling 'removeMessage', is run on the same thread that is
> tied to the *handler*, you're fine. The message you sent will not be
> handled/run until your code finishes first. No extra work necessary.
>
> If your code, calling 'removeMessage' is run on another thread than the
> one tied to the *handler*, you need to sync it up. This could be as
> simple as send another message on that handler that will call
> 'removeMessage': E.g.:
> handler.post(new Runnable() {
> public void run() {
> // Right now, calling 'removeMessages', etc. is done
> // on the handler's thread as well.
> handler.removeMessages(MSG_**ONE);
> handler.removeMessages(MSG_**TWO);
> ...
>
> if (conditionOne)
> handler.**sendEmptyMessageDelayed(MSG_**ONE, timeoutOne);
>
> if (conditionTwo)
> handler.**sendEmptyMessageDelayed(MSG_**TWO, timeoutTwo);
> }
> });
>
> Since both the 'removeMessages' and 'sendEmptyMessageDelayed' are called
> on 'handler' the Runnable needs to finish first before any other message
> sent to 'handler' can be executed.
>
>
> On Tuesday, October 30, 2012 9:17:39 AM UTC-4, Jay Howard wrote:
>>
>> I'm using a timer to manage timeout events, and would like to ensure that
>> a particular method runs atomically without the handler issuing messages
>> while the method is executing. Its basic form is:
>>
>> handler.removeMessages(MSG_**ONE);
>> handler.removeMessages(MSG_**TWO);
>> ...
>>
>> if (conditionOne)
>> handler.**sendEmptyMessageDelayed(MSG_**ONE, timeoutOne);
>>
>> if (conditionTwo)
>> handler.**sendEmptyMessageDelayed(MSG_**TWO, timeoutTwo);
>>
>> ...
>>
>> What I want to avoid is a situation where, before the removeMessages()
>> calls execute, one of the messages reaches its timeout and is delivered to
>> the message queue, then I send a duplicate one immediately after. My goal
>> is to guarantee that there is never more than one of each message type "in
>> flight" on the handler at any given time.
>>
>> Does the Handler class synchronize on MessageQueue when delivering its
>> messages? If so, then could I just synchronize on the MessageQueue? Or
>> would that be a terrible idea, since it's used by entities other than just
>> my Handler?
>>
> --
> 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
>
--
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] perform atomic message send/remove on a handler
I'm using a timer to manage timeout events, and would like to ensure that a particular method runs atomically without the handler issuing messages while the method is executing. Its basic form is: handler.removeMessages(MSG_ONE); handler.removeMessages(MSG_TWO); ... if (conditionOne) handler.sendEmptyMessageDelayed(MSG_ONE, timeoutOne); if (conditionTwo) handler.sendEmptyMessageDelayed(MSG_TWO, timeoutTwo); ... What I want to avoid is a situation where, before the removeMessages() calls execute, one of the messages reaches its timeout and is delivered to the message queue, then I send a duplicate one immediately after. My goal is to guarantee that there is never more than one of each message type "in flight" on the handler at any given time. Does the Handler class synchronize on MessageQueue when delivering its messages? If so, then could I just synchronize on the MessageQueue? Or would that be a terrible idea, since it's used by entities other than just my Handler? -- 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: parceling bitmaps pre and post honeycomb
Hmm. Good point. Some info I found online (forget where) suggested that Bitmap instances are fairly small since the pixel is stored externally on the native heap and the Bitmap instance only contains a reference to this externally allocated storage. I thought this would imply that, during parceling, only the reference to this external storage would be parceled rather than its entire contents. Some other info I found talked about how, with Honeycomb, this pixel storage was allocated on the VM heap rather than in native-land. My question was trying to get at whether this change would affect how Bitmaps are parceled. Does parceling a Bitmap *really* involve string-ifying the entire contents of its pixel data? On Wednesday, September 26, 2012 10:57:08 AM UTC-5, RichardC wrote: > > Not sure where you are getting your info from can you post a reference > please? > > Bitmap.writeToParcel > http://developer.android.com/reference/android/graphics/Bitmap.html#writeToParcel(android.os.Parcel, > > int) > > Has no change notes against it and says it writes the pixels (from API > level 1) > > On Wednesday, September 26, 2012 4:22:04 PM UTC+1, Jay Howard wrote: >> >> With the changes to how bitmap data is stored that came in with Honeycomb >> affect the efficiency of parceling bitmap objects? >> >> I'm assuming the actual bitmap data wasn't ever parceled pre-Honeycomb. >> Is that accurate? If so, then my question is basically whether this >> behavior (not parceling the bitmap data) was carried forward into Honeycomb >> when the behind-the-scenes memory changes were made. >> > -- 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] parceling bitmaps pre and post honeycomb
With the changes to how bitmap data is stored that came in with Honeycomb affect the efficiency of parceling bitmap objects? I'm assuming the actual bitmap data wasn't ever parceled pre-Honeycomb. Is that accurate? If so, then my question is basically whether this behavior (not parceling the bitmap data) was carried forward into Honeycomb when the behind-the-scenes memory changes were made. -- 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 create time-lapse video from existing pictures?
I'm in a similar situation, Alex. Did you ever find a solution to your problem? I found third-party libraries that support creating AVI and MOV (Quicktime) files from a series of JPEG images, but the compression isn't nearly as good as H.264. On Saturday, June 30, 2012 5:26:41 PM UTC-5, Alex Cunha wrote: > > Hi all. I have the duty of making a code to read a path on the > external storage containing some taken pictures and create a time- > lapse video from them. > > Since I must use Android SDK 2.1, I have no access to the system > codecs. Therefore, I cannot directly create the video from the > pictures. > > One possible solution is to inherit from the Camera class, override > takePicture method to read sequentially the pictures from the External > Storage and use the class MediaRecorder to record the video file > (passing the inherited new Camera class). However, I don't really know > how to do this. > > Other solution is to write my own video codec to convert a bunch of > pictures to HD H264 video. However, this is way too much code to do... > > Any suggestions? > > Thanks in advance. -- 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: jar blues
Guessing you need to have it in the lib directory in your Android project.
Adding it as an external library in eclipse adds it to your eclipse
classpath, so the build errors disappear in eclipse, but the android build
process only packages the jars it finds in your project's lib dir.
On Friday, September 21, 2012 10:41:42 AM UTC-5, bob wrote:
>
> Eventually, I want to create a JAR library with my Android routines in it.
>
> So, I tried this test:
>
> package com.jar_test;
>
> public class Jar_Test {
> public static void jar_test()
> {
> System.out.println("This is a JAR test");
> }
>
> }
>
>
> I exported that to a JAR.
>
>
>
>
> Then, I made this test app:
>
> package com.jar_test2;
>
> import com.jar_test.Jar_Test;
>
> import android.app.Activity;
> import android.os.Bundle;
>
> public class MainActivity extends Activity {
> /** Called when the activity is first created. */
> @Override
> public void onCreate(Bundle savedInstanceState) {
> super.onCreate(savedInstanceState);
> setContentView(R.layout.main);
> Jar_Test.jar_test();
> }
> }
>
> However, I got this error when I ran it.
>
>
> 09-21 10:33:57.710: E/AndroidRuntime(3366): FATAL EXCEPTION: main
> 09-21 10:33:57.710: E/AndroidRuntime(3366):
> java.lang.NoClassDefFoundError: com.jar_test.Jar_Test
> 09-21 10:33:57.710: E/AndroidRuntime(3366): at
> com.jar_test2.MainActivity.onCreate(MainActivity.java:14)
> 09-21 10:33:57.710: E/AndroidRuntime(3366): at
> android.app.Activity.performCreate(Activity.java:4469)
> 09-21 10:33:57.710: E/AndroidRuntime(3366): at
> android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1052)
> 09-21 10:33:57.710: E/AndroidRuntime(3366): at
> android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1932)
> 09-21 10:33:57.710: E/AndroidRuntime(3366): at
> android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1993)
> 09-21 10:33:57.710: E/AndroidRuntime(3366): at
> android.app.ActivityThread.access$600(ActivityThread.java:127)
> 09-21 10:33:57.710: E/AndroidRuntime(3366): at
> android.app.ActivityThread$H.handleMessage(ActivityThread.java:1159)
> 09-21 10:33:57.710: E/AndroidRuntime(3366): at
> android.os.Handler.dispatchMessage(Handler.java:99)
> 09-21 10:33:57.710: E/AndroidRuntime(3366): at
> android.os.Looper.loop(Looper.java:137)
> 09-21 10:33:57.710: E/AndroidRuntime(3366): at
> android.app.ActivityThread.main(ActivityThread.java:4507)
> 09-21 10:33:57.710: E/AndroidRuntime(3366): at
> java.lang.reflect.Method.invokeNative(Native Method)
> 09-21 10:33:57.710: E/AndroidRuntime(3366): at
> java.lang.reflect.Method.invoke(Method.java:511)
> 09-21 10:33:57.710: E/AndroidRuntime(3366): at
> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:978)
> 09-21 10:33:57.710: E/AndroidRuntime(3366): at
> com.android.internal.os.ZygoteInit.main(ZygoteInit.java:745)
> 09-21 10:33:57.710: E/AndroidRuntime(3366): at
> dalvik.system.NativeStart.main(Native Method)
>
> Anyone know what's wrong?
>
> I added the jar using 'Add External JARs…'
>
>
--
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: Best Practive in Passing Objects through an Intent to either Activity, BroadcastRecievers or Services
For simplicity's sake I like Serializable because it frees you from the work of implementing Parcelable. It's possible Parcleable could perform better, but if you're worried about performance when passing objects between activities then you should probably be storing them in a global location anyway. One approach could be to have a global, synchronized Map. Each activity just adds an entry pair with a unique key, e.g. getClass().getCanonicalName() + "." + SystemClock.elapsedRealtime(), then passes the key to child activities. One caveat: when using that approach you need to be extremely careful to avoid leaking global storage. On Friday, September 21, 2012 10:17:24 AM UTC-5, LemonCodes wrote: > > What is the best practices in passing Object? is it serializable or > parceable? kinda confused which one to use, i'm just planning passing a > single object not an array of Objects > -- 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] consistent jpeg compression when using the camera api?
My app uses the Camera to take high-res images, which are then jpeg
compressed and sent over the network. Initially I relied on the jpeg
quality setting in the Camera API:
final Camera.Parameters params = mCamera.getParameters();
params.setPictureFormat(PixelFormat.JPEG);
params.setJpegQuality(mQuality);
mCamera.setParameters(params);
...but the results are highly inconsistent. The size of the resulting jpeg
file can vary by a factor of four, even when the scene, dimensions and jpeg
quality are held constant. I gather this is because the compression is
performed in firmware and some devices do a better job than others. As a
workaround, I tried using Android's Bitmap classes to perform the
compression in a way that would be consistent across devices:
public static byte[] compress(byte[] data, CompressFormat format, int
quality) {
final ByteArrayOutputStream baos = new ByteArrayOutputStream();
final Bitmap bm = BitmapFactory.decodeByteArray(data, 0,
data.length);
try {
bm.compress(format, quality, baos);
} finally {
bm.recycle();
}
return baos.toByteArray();
}
When this works it works great, but it results in OutOfMemoryErrors when
the dimensions are sufficiently large. Certainly some of the resolutions
supported by newer cameras are too large for this method to work reliably.
So my questions are:
1. Is there a way to make the Camera API perform jpeg compression in a way
that's consistent across devices?
2. If not, then are is there a way in which I can use the Bitmap classes
differently so as to avoid or mitigate the OutOfMemoryErrors?
3. If not, then can anyone recommend a different method of achieving
consistent jpeg compression (possibly via third-party jar)? Something
that's pure java and does byte[] -> byte[] conversion (without having to
materialize the image in a intermediate form) would be ideal.
Thanks in advance.
--
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 send vector from one activity to another
I'll assume you have a Vector. 1. Make sure Foo implements Serializable or Parcelable. 2. Call toArray(Foo[]) on the Vector to get a Foo[]. 3. Set the Foo[] as an extra using Intent.putExtra(Serializable) or intent.putExtra(Parcelable[]). 4. In the resulting activity, get the array back using Intent.getSerializableExtra() or Intent.getParcelableArrayExtra(). 5. The former returns a Serializable which is actually an Object[]. The latter returns a Parcelable[]. Even though each element in the array is an instance of Foo, you can't cast either directly to Foo[]. 6. Create a new Vector of the same size as your array. 7. Iterate over the array and add each element to the new vector, casting each to Foo. Serialization can be expensive when the amount of data is large. So, if the vector or its elements are very large, store it somewhere global and hard-code the child activity to look in that global location. You'll probably want to erase this global reference (so the Vector can be garbage collected) when the calling activity is destroyed. This approach can also be problematic when it's possible for multiple instances of the child activity to exist on simultaneously on the stack. On Friday, September 21, 2012 7:51:53 AM UTC-5, rauf qureshi wrote: > > hello friends > I am trying to send Vector one activity to another activity how to do this > can any body tell me. > > > 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
