Re: [android-developers] Rating Hijacking !

[Bradley O'Hearne]

Hey Jose, 

I feel your pain. I've been an app developer since the beginning of smartphone 
app development, and have both experienced first-hand and watched others 
experience the really unfair treatment by people in ratings and reviews, and 
the unfortunate inability of the associated app market ratings system to 
basically facilitate consistent accurate and legitimate reviews. Alas, I am 
just another app developer, and cannot fix the problem for you. But what I can 
do is the following: 

- Let you know that I'm sure you put a lot of hard work into your app 
development, and would like to have that work and the product recognized and 
treated accordingly. So just know there's one person out there who appreciates 
whatever late nights and weekends you put in to make it happen. You SHIPPED 
PRODUCT. That's more than most big companies do well. 

- I'll check out your app and I'll give you a fair rating, provided it isn't 
expensive. If it isn't free, don't send me any kind of freebie or anything like 
that -- I'm happy to buy and review it. Maybe if a few devs out there help a 
brother out and perhaps Google straightens out whatever nefarious star-forces 
are at work, it can straighten out your rating. Just send me the link to the 
app, I'll check it out. 

Keep your chin up, and happy coding. 

Cheers, 

Brad

On Mar 27, 2014, at 12:29 PM, Jose_GD jose.gonzale...@gmail.com wrote:

 I've just sent feedback via the Developer's Console and captured this screen. 
 Cannot understand how suddenly a lot of people find my app is terrible... 
 I've lost 0.25 points of rating since this little help from Google to get 
 more people rating. Incredible.
 
 
 
 
 
 El miércoles, 26 de marzo de 2014 15:28:16 UTC-3, Jose_GD escribió:
 Any news regarding this issue?
 
 I don't know if I didn't pay attention before or if it's a brand new feature 
 of the Play app. Now you can rate an app immediately after tapping Install 
 (or Buy), *before* the install completes! How can you have an opinion for an 
 app you actually didn't use at all?
 
 No wonder my app 3 months ago had a 4.4 rate and now has a 4.16 rate. And the 
 last update was 4 months ago...
 
 Thanks for any clues
 
 José
 https://play.google.com/store/apps/developer?id=Jos%C3%A9+Gonz%C3%A1lez+D%27Amico
 
 
 El miércoles, 22 de enero de 2014 19:43:29 UTC-3, Nobu Games escribió:
 I got feedback today from Google Play support acknowledging my complaints 
 about that quick-rating widget:
 
 Thank you for contacting the Google Play developer support team. I sincerely 
 apologize for the inconvenience.
 
 We really appreciate your thoughtful feedback, and we'll be sure to take your 
 thoughts into consideration as we work to improve Google Play.
 
 Thanks for your understanding and continued support!
 
 Fingers crossed that this issue will get sorted out soon :-)
 
 On Tuesday, January 21, 2014 1:33:59 PM UTC-6, Nobu Games wrote:
 I'm still far from being top or even mid-tier in terms of app downloads but 
 this morning I also got my first 2-star mystery rating for a paid app of mine 
 - no comment and no Google+ name I could respond to. That didn't happen to me 
 so far since most users tried the free version first and then decided to buy 
 afterward.
 
 This wouldn't have bothered me that much but nevertheless I wanted to see for 
 myself how that recommendation rating widget looks like on my phone. So I 
 opened the Google Play store app and scrolled down the lengthy front page 
 with several swipe movements. And I suddenly saw that an image was flashing 
 and quickly changing to 1 star. I accidentally rated some random app while 
 swiping the screen.
 
 This bug 100% reproducible:
 Touch one of the stars
 Move your finger up or down outside the recommendation box
 Lift finger
 App gets rated
 This can happen quickly and accidentally while scrolling down the screen. 
 Since I am right-handed (as the majority of people), my thumb naturally 
 reaches to the left side of the screen, where the worse rating options are (1 
 and 2 stars). I bet this happens thousands of times every day without people 
 even realizing what they just did. I sent a bug report to Google Play support 
 about that issue.
 
 I also have to agree that the phrasing of the recommendation is completely 
 misleading. If it weren't for this thread here I would have thought that I'd 
 be rating recommendations and not apps. If I were asked to rate my favorite 
 scanner app with the question rate this item to get recommendations, I 
 would give that recommendation a bad rating because I am already 100% happy 
 with my scanner app and I'm absolutely not interested in more apps like that. 
 I guess something along these lines may have happened with my paid app this 
 morning.
 
 Google Play really has to fix that as quick as possible. This new 
 recommendation widget is a substantial change in the overall rating system 
 Google had no experience with before. Stuff like that should be extensively 
 

Re: [android-developers] Video streaming plus UI control update thread

[Bradley O'Hearne]

Piren, 

Thanks for taking the time to respond. I was able to figure out the problem…but 
I can confirm that Thread with sleep is bad. Handler is the right approach — I 
had something (not obvious) several layers deep in the call chain which was 
causing the problem. 

Thanks again for your help. 

Cheers, 

Brad

On Nov 10, 2013, at 12:55 AM, Piren gpi...@gmail.com wrote:

 I've done it and have had no issues what so ever (using a surfaceview).
 
 Regarding your code, your first approach (thread with sleep) is horrible, 
 don't ever do that for any reason :) The second approach is the correct one 
 which i have used myself with no issues.
 
 Since i see no reason why it would affect your playback like so, i suggest 
 you just profile your app and see exactly what calls cause the slowdown. 
 
 On Saturday, November 9, 2013 5:03:07 AM UTC+2, Brad OHearne wrote:
 Wasn’t able to get a response on this after a few days, so perhaps I’ll try 
 to frame it another way. If you: 
 
 - Have created custom controls for a video player 
 
 - Are familiar with the proper / conventional approach to updating UI 
 controls every second / sub-second as in these kinds of apps: stopwatch, 
 clock with second hand, video player with seek bar, music player, etc. 
 
 - Have done any background threading with regular updates to UI controls 
 
 I would love to hear from you on what worked for you, or even if you couldn’t 
 get it working, what did not work for you. Any information at this point will 
 help narrow down the problem — the use case is very simple — update the play 
 time on a video player every second without killing the streaming video 
 performance. 
 
 I would love to hear from you. 
 
 Thanks, 
 
 Brad 
 
 On Nov 4, 2013, at 2:56 PM, Bradley O'Hearne br...@bighillsoftware.com 
 wrote: 
 
  Hey there, 
  
  I hope everyone’s week is off to a good start! 
  
  I have a pretty simple use case: I am playing video streamed across the 
  network in an app, and I need to update two SeekBars every second, one 
  which tracks the video’s timecode while playing, and the other which tracks 
  the device volume. Simple enough, gun up a background thread, and update 
  both every second (given that to my knowledge, I can’t have the system call 
  a listener specific to either of those functions. In a nutshell, the video 
  streams just fine when this control-updating thread isn’t running, but when 
  it is running, the video is so chunky and slow, and audio garbled, that it 
  isn’t watchable. 
  
  First, the video display is accomplished using a TextureView in combination 
  with a MediaPlayer (the reason is that the TextureView allows scrolling / 
  movement, SurfaceView does not). Second, I have tried a couple of different 
  approaches for the background thread: 
  
  a) I have tried a Runnable in a new Thread which updates the SeekBar 
  controls inside of a runOnUIThread — this keeps a looping background thread 
  and updates the controls on the UI thread, as such: 
  
  new Thread(new ManagementRunnable()).start(); 
  ... 
  public class ManagementRunnable implements Runnable 
  { 
 public void run() 
 { 
 try 
 { 
 updateControlState(); 
  Thread.sleep(1000); 
 } 
 catch (Exception ex) 
 { 
 ex.printStackTrace(); 
 } 
 } 
  } 
  ... 
  public void updateControlState() 
  { 
runOnUiThread(new Runnable() 
{ 
 public void run() 
 { 
  // update the timecode SeekBar 
  ... 
 // update the volume SeekBar 
  ... 
 } 
  } 
  } 
  
  b) I have also tried using a Handler, where it runs on the UI thread, as 
  such: 
  
  new Handler().post(new ManagementRunnable()); 
  ... 
  public class ManagementRunnable implements Runnable 
  { 
 public void run() 
 { 
 try 
 { 
 updateControlState(); 
 handler.postDelayed(this, 1000); 
 } 
 catch (Exception ex) 
 { 
 ex.printStackTrace(); 
 } 
 } 
  } 
  
  public void updateControlState() 
  { 
  // update the timecode SeekBar 
  ... 
 // update the volume SeekBar 
  ... 
  } 
  
  The problem is, the result is the same regardless of which approach is 
  taken — the video is unwatchable. I have tested this on a Samsung Galaxy S2 
  Skyrocket, and in the simulator. I’ve Googled this a fair amount, and it 
  appears that the approaches above are generally the recommended approach. 
  While video decoding and playing isn’t exactly a cheap operation, I’m a 
  little surprised that accommodating a once-per-second update brought the 
  app to its knees, given nothing else taking place in the app. 
  
  If anyone has any insight, I would really appreciate

Re: [android-developers] Video streaming plus UI control update thread

[Bradley O'Hearne]

Wasn’t able to get a response on this after a few days, so perhaps I’ll try to 
frame it another way. If you: 

- Have created custom controls for a video player

- Are familiar with the proper / conventional approach to updating UI controls 
every second / sub-second as in these kinds of apps: stopwatch, clock with 
second hand, video player with seek bar, music player, etc. 

- Have done any background threading with regular updates to UI controls

I would love to hear from you on what worked for you, or even if you couldn’t 
get it working, what did not work for you. Any information at this point will 
help narrow down the problem — the use case is very simple — update the play 
time on a video player every second without killing the streaming video 
performance. 

I would love to hear from you. 

Thanks, 

Brad 

On Nov 4, 2013, at 2:56 PM, Bradley O'Hearne br...@bighillsoftware.com wrote:

 Hey there, 
 
 I hope everyone’s week is off to a good start! 
 
 I have a pretty simple use case: I am playing video streamed across the 
 network in an app, and I need to update two SeekBars every second, one which 
 tracks the video’s timecode while playing, and the other which tracks the 
 device volume. Simple enough, gun up a background thread, and update both 
 every second (given that to my knowledge, I can’t have the system call a 
 listener specific to either of those functions. In a nutshell, the video 
 streams just fine when this control-updating thread isn’t running, but when 
 it is running, the video is so chunky and slow, and audio garbled, that it 
 isn’t watchable. 
 
 First, the video display is accomplished using a TextureView in combination 
 with a MediaPlayer (the reason is that the TextureView allows scrolling / 
 movement, SurfaceView does not). Second, I have tried a couple of different 
 approaches for the background thread: 
 
 a) I have tried a Runnable in a new Thread which updates the SeekBar controls 
 inside of a runOnUIThread — this keeps a looping background thread and 
 updates the controls on the UI thread, as such: 
 
 new Thread(new ManagementRunnable()).start();
 ...
 public class ManagementRunnable implements Runnable
 {
public void run()
{
try
{
updateControlState();
   Thread.sleep(1000);
}
catch (Exception ex)
{
ex.printStackTrace();
}
}
 }
 ...
 public void updateControlState()
 {
   runOnUiThread(new Runnable()
   {
public void run()
{
   // update the timecode SeekBar
   ...
// update the volume SeekBar
   ...
}
   }
 }
 
 b) I have also tried using a Handler, where it runs on the UI thread, as 
 such: 
 
 new Handler().post(new ManagementRunnable());
 ...
 public class ManagementRunnable implements Runnable
 {
public void run()
{
try
{
updateControlState();
handler.postDelayed(this, 1000);
}
catch (Exception ex)
{
ex.printStackTrace();
}
}
 }
 
 public void updateControlState()
 {
   // update the timecode SeekBar
   ...
// update the volume SeekBar
   ...
 }
 
 The problem is, the result is the same regardless of which approach is taken 
 — the video is unwatchable. I have tested this on a Samsung Galaxy S2 
 Skyrocket, and in the simulator. I’ve Googled this a fair amount, and it 
 appears that the approaches above are generally the recommended approach. 
 While video decoding and playing isn’t exactly a cheap operation, I’m a 
 little surprised that accommodating a once-per-second update brought the app 
 to its knees, given nothing else taking place in the app.
 
 If anyone has any insight, I would really appreciate it. 
 
 Thanks, 
 
 Brad 
 
 -- 
 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.

-- 
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

[android-developers] Video streaming plus UI control update thread

[Bradley O'Hearne]

Hey there, 

I hope everyone’s week is off to a good start! 

I have a pretty simple use case: I am playing video streamed across the network 
in an app, and I need to update two SeekBars every second, one which tracks the 
video’s timecode while playing, and the other which tracks the device volume. 
Simple enough, gun up a background thread, and update both every second (given 
that to my knowledge, I can’t have the system call a listener specific to 
either of those functions. In a nutshell, the video streams just fine when this 
control-updating thread isn’t running, but when it is running, the video is so 
chunky and slow, and audio garbled, that it isn’t watchable. 

First, the video display is accomplished using a TextureView in combination 
with a MediaPlayer (the reason is that the TextureView allows scrolling / 
movement, SurfaceView does not). Second, I have tried a couple of different 
approaches for the background thread: 

a) I have tried a Runnable in a new Thread which updates the SeekBar controls 
inside of a runOnUIThread — this keeps a looping background thread and updates 
the controls on the UI thread, as such: 

new Thread(new ManagementRunnable()).start();
...
public class ManagementRunnable implements Runnable
 {
public void run()
{
try
{
updateControlState();
Thread.sleep(1000);
}
catch (Exception ex)
{
ex.printStackTrace();
}
}
 }
...
public void updateControlState()
{
   runOnUiThread(new Runnable()
   {
public void run()
{
// update the timecode SeekBar
...
// update the volume SeekBar
...
}
}
}

b) I have also tried using a Handler, where it runs on the UI thread, as such: 

new Handler().post(new ManagementRunnable());
...
public class ManagementRunnable implements Runnable
 {
public void run()
{
try
{
updateControlState();
handler.postDelayed(this, 1000);
}
catch (Exception ex)
{
ex.printStackTrace();
}
}
 }

public void updateControlState()
{
// update the timecode SeekBar
...
// update the volume SeekBar
...
}

The problem is, the result is the same regardless of which approach is taken — 
the video is unwatchable. I have tested this on a Samsung Galaxy S2 Skyrocket, 
and in the simulator. I’ve Googled this a fair amount, and it appears that the 
approaches above are generally the recommended approach. While video decoding 
and playing isn’t exactly a cheap operation, I’m a little surprised that 
accommodating a once-per-second update brought the app to its knees, given 
nothing else taking place in the app.

If anyone has any insight, I would really appreciate it. 

Thanks, 

Brad 

-- 
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] dex issues with Latest SDK

[Bradley O'Hearne]

On Oct 31, 2013, at 2:56 PM, Dan dan.schm...@gmail.com wrote:

 So, I upgraded my SDK today and tried to rebuild all my stuff (command
 line from scons file.)  First 2 projects went fine, the 3rd is now failing
 with:
 
 [dex] Converting compiled files and external libraries into 
 /snip.../bin/classes.dex...
 [dx] 
 [dx] UNEXPECTED TOP-LEVEL EXCEPTION:
 [dx] java.nio.BufferOverflowException
 [dx] at java.nio.Buffer.nextPutIndex(Buffer.java:499)
 [dx] at java.nio.HeapByteBuffer.putShort(HeapByteBuffer.java:296)
 [dx] at com.android.dex.Dex$Section.writeShort(Dex.java:818)
 [dx] at com.android.dex.Dex$Section.writeTypeList(Dex.java:870)
 [dx] at com.android.dx.merge.DexMerger$3.write(DexMerger.java:437)
 [dx] at com.android.dx.merge.DexMerger$3.write(DexMerger.java:423)
 [dx] at 
 com.android.dx.merge.DexMerger$IdMerger.mergeUnsorted(DexMerger.java:317)
 [dx] at com.android.dx.merge.DexMerger.mergeTypeLists(DexMerger.java:423)
 [dx] at com.android.dx.merge.DexMerger.mergeDexes(DexMerger.java:163)
 [dx] at com.android.dx.merge.DexMerger.merge(DexMerger.java:187)
 [dx] at 
 com.android.dx.command.dexer.Main.mergeLibraryDexBuffers(Main.java:439)
 [dx] at com.android.dx.command.dexer.Main.runMonoDex(Main.java:287)
 [dx] at com.android.dx.command.dexer.Main.run(Main.java:230)
 [dx] at com.android.dx.command.dexer.Main.main(Main.java:199)
 [dx] at com.android.dx.command.Main.main(Main.java:103)
 
 Anybody pointers on how to get it to not fail this way (or more info that 
 would help
 folks fix it?)

Dan, 

I literally just worked through this error — mine was caused by adding the 
Facebook SDK as a module dependency to a project in the latest version of 
Android Studio. In my case, I saw a stack trace very similar to yours, but the 
actual exception was further upstream, and the error was due to the fact that 
the Facebook SDK uses a different version of the android support jar than my 
primary project. I had to go into the Facebook SDK’s build.gradle file and 
comment out its jar and use the other one that my primary project was using, as 
follows: 

dependencies {
//compile files('libs/android-support-v4.jar')
compile 'com.android.support:support-v4:18.0.0'
}

After fixing that, all problems disappeared. I don’t know if this is going to 
help you even a little, but I’ve spent the day stumbling around in the spooky 
Halloween land of undocumented tools and APIs, and thought I’d at least try to 
lend a hand. Good luck, and let me know if you are able to make it through. 

Cheers, 

Brad

-- 
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] Indeterminate Progress Bar not animating

[Bradley O'Hearne]

On Oct 21, 2013, at 2:56 AM, Dusk Jockeys Android Apps duskjock...@gmail.com 
wrote:

 I had a similar issue before.. seems to do with Window display timing, I 
 couldn't work out.
  
 However, I found if I wrapped the ProgressBar in a Layout, and applied the 
 Hide/Show logic to the Layout instead, that worked fine, the progress bar was 
 hidden and displayed when required.
  
 Worth a try, maybe.

Finally got a moment to give this a try -- no worky -- same result as before. 
I'm starting to suspect something with the device or the adaption of the 
Android OS to it. 

Thanks, 

Brad

-- 
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] Indeterminate Progress Bar not animating

[Bradley O'Hearne]

I have an  indeterminate ProgressBar in an XML layout for a fragment. When I 
display this fragment the first time, the ProgressBar visibility is set to 
VISIBLE, and the activity circle spins until a loading operation is complete, 
at which time the ProgressBar visibility is set to INVISIBLE, and it 
disappears. All good so far. 

However, when conditions occur that causing the loading operation to happen 
again, the ProgressBar visibility is set to VISIBLE, but it does not animate 
(spin), it stays static. I can reinitiate that loading operation as many times 
as I want, and reset the ProgressBar visibility ad naseum, but it never spins 
again. 

First, the code is being invoked already on the UI thread, so it should work 
(it is actually downstream from the onReceive callback of a BroadcastReceiver, 
which at least with the references I've been able to dig up, is supposed to 
happen on the UI thread). However, just to be safe, I tried two other means of 
putting the changing of ProgressBar visibility on the UI thread, via: 

1. Explicitly running on the UI thread: 

getActivity().runOnUiThread(new Runnable()
{
@Override
public void run()
{
progressBar.setVisibility(View.VISIBLE);
}
});

2. Using an AsyncTask, where onPostExecute() is guaranteed to be on the UI 
thread.: 

public static class ProgressBarTask extends AsyncTaskVoid, Void, Bitmap
{
private ImageLoader loader;

@Override
protected Bitmap doInBackground(Void... params)
{
return true
}

@Override
protected void onPostExecute(Bitmap result)
{
 
ImportantWrappingClass.this.progressBar.setVisibility(View.VISIBLE);
}
}

In addition to this, I also tried resetting the ProgressBar's progress to 0 
(even though it was indeterminate). None of the above had any effect, the 
ProgressBar still doesn't spin the second (or third, or n time it is 
displayed). 

So my question -- how can I get an indeterminate ProgressBar to spin when 
hidden/displayed again after the first time? 

Your answers are appreciated. 

Thanks, 

Brad

-- 
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] Indeterminate Progress Bar not animating

[Bradley O'Hearne]

On Oct 18, 2013, at 10:40 AM, TreKing treking...@gmail.com wrote:

 
 On Fri, Oct 18, 2013 at 10:56 AM, Bradley O'Hearne 
 br...@bighillsoftware.com wrote:
 So my question -- how can I get an indeterminate ProgressBar to spin when 
 hidden/displayed again after the first time?
 
 I tried a simple example of showing / hiding a progress bar (on click of a 
 button) and it continues to spin as expected. I would assume your issue is 
 due to a bug somewhere in your code that is not shown here.

TreKing -- thanks for the reply. Your assertion is probably correct, however 
finding what it is -- easier said than done. However, I've done everything I 
know how to guarantee this thing is on the UI thread, so I'm curious as to what 
in principle would block animation if the change WAS on the UI thread, and the 
method returned immediately. Since you apparently have an example which works, 
would you mind posting your code? Then I could examine what deltas there were 
and perhaps narrow down the culprit. 

 I would boil your issue down to it's simplest form: hide and show the 
 progress bar with a button and make sure that works. Then incrementally add 
 code to get back to where it is now. Somewhere along the way you're doing 
 something that's causing the animation to stop.

Thanks for the advice….been doing that for hours, but perhaps I need to take a 
bigger scalpel to it. 

 Also double check logcat for any warnings or errors that might be buried in 
 there.

No errors….just weird behavior.

Thx, 

Brad

-- 
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] Getting the top fragment in the backstack

[Bradley O'Hearne]

It's been a few days and I've gotten no response on the questions below, so I 
suppose I'll assume there is no way to to accomplish getting the fragment 
associated with a BackStackEntry off the backstack without a specific name or 
ID for it. In my code, I have had to manage a separate true java.util.Stack in 
parallel with the backstack to properly manage things (which is complete 
redundancy of processing, but required due to the API). 

If anyone close to the Android API dev team is reading this, I would strongly 
suggest a change to the API here which would allow you to get the Fragment 
associated with the BackStackEntry popped off the stack. As a measure of 
sensible protocol, if a caller pushes A onto a stack, it doesn't make sense 
that they are handed back B on a pop operation, and worse, can't directly get 
A. If it is important to have B in the mix at all (which in this case would be 
BackStackEntry), then then the API needs to do one of the following: 

1. Push A, pop - A (this is the best idea, if B is needed internally, fine, 
then have B wrap A while it is on the stack, and unwrap A from B when popped). 

2. Push A, pop - B, but then B needs an explicit getA() method, not a 
getAById() or getAByName(), but just getA(). One note on B, if you are going to 
pop an object off the stack which is different than the object pushed onto the 
stack, it needs to have specific relevance to the caller, and direct access to 
the original object pushed. If B is not directly relevant to the caller, then 
popping off B essentially represents a propagation of internal implementation 
out of its black box. The point of reuse with fragments and when it comes to 
stacks in general is that you aren't concerned about asking for stack objects 
in specific manner, you are only interested in what's on top. And in that 
regard, the backstack really ought to have a peek() or top() convenience method 
which doesn't require getting the backstack entry count minus one. 

I hope that contribution helps -- this is a question that has gotten some 
considerably mileage on other forums, so it would appear that a number of 
others have traveled the same terrain. 

Onward and upward, 

Brad 

On Oct 13, 2013, at 11:25 AM, Brad O'Hearne br...@bighillsoftware.com wrote:

 Hello all, 
 
 I am trying to manage the pushing and popping of fragments on a fragment 
 manager's backstack. I have discovered that while I can  easily get the 
 backstack's top BackStackEntry (suggestion: a top() method would be nice), I 
 cannot very easily get the fragment associated with it. 
 
 I understand that the quick answer is going to be something like use the 
 BackStackEntry's ID to find the fragment, as in:
 
 Fragment topFragment = 
 fragmentManager.findFragmentById(backStackEntry.getId());
 
 or to use the BackStackEntry's tag to find the fragment, as in: 
 
 Fragment topFragment = 
 fragmentManager.findFragmentByTag(backStackEntry.getName());
 
 but I don't believe I can do either, and the reason is that there may be more 
 than one fragment in the backstack of the same type. Imagine a fragment that 
 is displaying details on a car, and displays with it a list of other 
 suggested cars. Selecting one of those suggested cars will create another 
 fragment of the same type, and push it onto the same backstack. This can 
 happen any number of times. 
 
 The problem is that all car fragments would have the same ID, and managing 
 separate names for all of them -- what a complete nuisance, and duplicated 
 effort. The whole point behind fragments is reuse, and the whole point behind 
 a stack data structure is dealing with the top item as it appears. So 
 questions: 
 
 1. How can I get the fragment associated with the top item in the backstack 
 by a means other than an ID or a name? (I am hoping that I'm not going to 
 have to manually manage a fragment stack in parallel to the backstack -- 
 surely there has to be a way to do this easily). 
 
 2. Any idea why when adding something to the backstack, you can't just get it 
 back when you ask for it? At the API level, the caller isn't adding a 
 BackStackEntry, they are directly pushing their fragment. If internally it 
 needs to be wrapped in a BackStackEntry to provide additional metadata, fine, 
 but why isn't there a getFragment() method on the BackStackEntry? If that 
 entry is a direct result of the fragment being added, why all the 
 loose-coupling and indirection? This is one instance where loose-coupling is 
 not a good thing. 
 
 Your insight and answers are appreciated. 



-- 
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