[android-developers] Re: cost of view instantiation versus memory bloat
Thanks for the reply - sorry for the delay (apparently I wasn't subscribed to this thread). I'm not familiar with the practices necessary to analyze memory usage at this point, but I'll look into it. For reference, the widget is a scaling tiled layer, similar to iOS CATiledLayer, which allows the user to use arbitrarily sized tiles, scales, etc - also a previous tile set needs to stay displayed until the new one is rendered. So generally there are only maybe 4-16 tiles (Views) being displayed, but for a moment, at a small scale, with a previous set in place (before that set is destroyed), there could be as many as 60-70 views. The views themselves are just ImageViews, so nothing special about instantiation. I'm not familiar enough with the platform to know if the memory used by having references to those views (pooled, for recycling) outweigh the benefit gained in not having to repeatedly re-instantiate. On Tuesday, March 5, 2013 1:50:10 AM UTC-6, Piren wrote: Your best bet is to just analyze your app memory and processing wise... see how long it takes you to initialize a view and how much memory they all use.. then find a proper balance between the two that makes sure your app is both responsive and without a risk of memory issues. My guess - unless initializing your views is something very complicated that takes a while (which might mean you'll need to redesign them since they might not be done the best), re-using will be the proper way to go. On Tuesday, March 5, 2013 6:57:24 AM UTC+2, momo wrote: I have a widget that potentially uses many Views. In looking at the source for other view-intensive widgets (like ListView), I understand that it's a fairly computationally expensive process to instantiate Views. I see they're recycling children - creating them on demand, then caching them, and re-using them with updated properties when one is required. My concern is that in my case (with so many potential Views) that the cost of keeping references to them in memory might be worse than the cost of instantiating them. I'm tracking the total number of Views in the cache and see it reach as much as 60-70 at times. The requirement is such that I can't reduce the number of Views used. When the number is as high as I've mentioned, is caching and recycling Views still a better prospect than new instantiation on-demand? I believe that if I did not cache, the unused Views would be garbage-collected properly (there shouldn't be any references that I'm not catching). TYIA. -- -- 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] cost of view instantiation versus memory bloat
I have a widget that potentially uses many Views. In looking at the source for other view-intensive widgets (like ListView), I understand that it's a fairly computationally expensive process to instantiate Views. I see they're recycling children - creating them on demand, then caching them, and re-using them with updated properties when one is required. My concern is that in my case (with so many potential Views) that the cost of keeping references to them in memory might be worse than the cost of instantiating them. I'm tracking the total number of Views in the cache and see it reach as much as 60-70 at times. The requirement is such that I can't reduce the number of Views used. When the number is as high as I've mentioned, is caching and recycling Views still a better prospect than new instantiation on-demand? I believe that if I did not cache, the unused Views would be garbage-collected properly (there shouldn't be any references that I'm not catching). TYIA. -- -- 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: When and how are LayoutParams examined, aside from onLayout and onMeasure
Thanks for the reply.
The custom layout isn't doing *just* that - it's doing a lot of other
stuff, and I figured it'd be more practical to just have it layout all it's
children as they should be, instead of using a more traditional layout
(like RelativeLayout or FrameLayout) and just omitting rules and margins.
It's trivial to use traditional layouts to achieve the net result, but
when I ran into the issue, it made me curious why the LayoutParams were
being queried at all, since my overriden onMeasure and onLayout didn't
examine them. I believe that they're still being looked at in the various
measure methods, as called by parent containers.
On Sunday, March 3, 2013 2:35:07 AM UTC-6, Piren wrote:
I'm no expert on the layout machenism of android, but you dont really need
a reference to the LayoutParams to do these calculations since onMeasure
gets the processed values of these params. the width and height
MeasureSpecs contain the size and mode as recommended by the layout params.
What you're doing might be working in the instance you're testing on, but
might fail on others.
P.S - Maybe its because of there's missing code here, but it seems like
you're just having the parent layout having the same size as the child
layout (basically both have wrap_content on width and height)... why do you
need a custom class for that?
On Saturday, March 2, 2013 8:10:17 AM UTC+2, momo wrote:
I have a custom ViewGroup that's only ever managing the size and position
of one child. I've override onMeasure and onLayout so that LayoutParams
are never examined, yet it fails unless I do provide LayoutParams. Here
are abbreviated summaries of the relevant portions of the class:
public class SomeSpecialLayoutManager extends ViewGroup {
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec)
{
measureChildren(widthMeasureSpec, heightMeasureSpec);
int w = mChild.getMeasuredWidth();
int h = mChild.getMeasuredHeight();
w = Math.max(w, getSuggestedMinimumWidth());
h = Math.max(h, getSuggestedMinimumHeight());
w = resolveSize(w, widthMeasureSpec);
h = resolveSize(h, heightMeasureSpec);
setMeasuredDimension(w, h);
}
@Override
protected void onLayout(boolean changed, int l, int t, int r, int b) {
mChild.layout( 0, 0, mWidth, mHeight );
}
}
Using the above, the following *does* work:
LayoutParams lp = mChild.getLayoutParams();
lp.width = mWidth;
lp.height = mHeight;
mChild.setLayoutParams( lp );
But since neither `onMeasure` nor `onLayout` even makes reference to
`LayoutParams`, I wonder why it's required, or even how it's referenced at
all. I would assume that since the layout pass grabs `mWidth` and
`mHeight` directly, there'd be no need for the `LayoutParams` at all - and
that a call to requestLayout would update it appropriately.
However, when I isolate the above in a small program outside of a
complicated View tree with scrolling layers that exceed normal container
sizes, it *does* work as expected, so I have to assume the issue is in the
measure pass.
I've read as much documentation as I can find about what's going on
during the measure and layout passes, and examined the source, but I
believe I must be missing something.
TYIA.
--
--
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] When and how are LayoutParams examined, aside from onLayout and onMeasure
I have a custom ViewGroup that's only ever managing the size and position
of one child. I've override onMeasure and onLayout so that LayoutParams
are never examined, yet it fails unless I do provide LayoutParams. Here
are abbreviated summaries of the relevant portions of the class:
public class SomeSpecialLayoutManager extends ViewGroup {
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
measureChildren(widthMeasureSpec, heightMeasureSpec);
int w = mChild.getMeasuredWidth();
int h = mChild.getMeasuredHeight();
w = Math.max(w, getSuggestedMinimumWidth());
h = Math.max(h, getSuggestedMinimumHeight());
w = resolveSize(w, widthMeasureSpec);
h = resolveSize(h, heightMeasureSpec);
setMeasuredDimension(w, h);
}
@Override
protected void onLayout(boolean changed, int l, int t, int r, int b) {
mChild.layout( 0, 0, mWidth, mHeight );
}
}
Using the above, the following *does* work:
LayoutParams lp = mChild.getLayoutParams();
lp.width = mWidth;
lp.height = mHeight;
mChild.setLayoutParams( lp );
But since neither `onMeasure` nor `onLayout` even makes reference to
`LayoutParams`, I wonder why it's required, or even how it's referenced at
all. I would assume that since the layout pass grabs `mWidth` and
`mHeight` directly, there'd be no need for the `LayoutParams` at all - and
that a call to requestLayout would update it appropriately.
However, when I isolate the above in a small program outside of a
complicated View tree with scrolling layers that exceed normal container
sizes, it *does* work as expected, so I have to assume the issue is in the
measure pass.
I've read as much documentation as I can find about what's going on during
the measure and layout passes, and examined the source, but I believe I
must be missing something.
TYIA.
--
--
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] Reacting once after initial layout is complete
This question has been asked several times in various forms but I haven't found a definitive answer. I need to be able to get dimensions and positions of descendant Views after the initial layout of a container (a contentView). The dimensions required in this case are of a View(Group) that is not predictable - might have multiple lines of text, minimum height to accommodate decoration, etc. I don't want to do it every on every layout pass (onLayout). The measurement I need is a from a deeply nested child, so overriding the onLayout/onMeasure of each container in between seems a poor choice. I'm not going to do anything that'll cause a loop (trigger-event-during-event). Romain Guy hinted once that we could just .post a Runnable in the constructor of a View (which AFAIK would be in the UI thread). This seems to work on most devices (on 3 of the 4 I have personally), but fails on Nexus S. Looks like Nexus S doesn't have dimensions for everything until it's done one pass per child, and does not have the correct dimensions when the posted Runnable's run method is invoked. I tried counting layout passes (in onLayout) and comparing to getChildCount, which again works on 3 out of 4, but a different 3 (fails on Droid Razr, which seems to do just one pass - and get all measurements - regardless of the number of children). I tried various permutations of the above (posting normally; posting to a Handler; casting getContext() to an Activity and callingrunOnUiThread... same results for all). I ended up using a horrible shameful no-good hack, by checking the height of the target group against its parent's height - if it's different, it means it's been laid out. Obviously, not the best approach - but the only one that seems to work reliably between various devices and implementations. I know there's no built-in event or callback we can use, but is there a better way? TYIA -- 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] Simple touch event management
I've got a component that I want to make various changes to content and
display when touched, and revert when the finger goes back up. The
following works in general, but if the user's finger wanders out off the
component itself before lifting, ACTION_UP never fires, so it never reverts
to the up state.
public class MyComponent extends SomeLayout {
// ... stuff
@Override
public boolean onTouchEvent(MotionEvent event) {
final int action = event.getAction() MotionEvent.ACTION_MASK;
switch (action) {
case MotionEvent.ACTION_DOWN :
// do something...
break;
case MotionEvent.ACTION_UP :
// do something else...
break;
}
return super.onTouchEvent(event);
}
}
This ViewGroup has complex content, and is not something that'd be
appropriate for StateDrawables.
Any suggestions?
TYIA
--
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: Simple touch event management
... and the answer is ACTION_CANCEL... every time i post to this list I find the answer 10 minutes later. sorry! -- 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] removing image data from memory
I have to believe there's a way to clear image data from memory once it's no longer required, but despite exhaustive searching I can't find a solution. Both this list and stack are full of questions regarding OOM errors, specifically bitmap size exceeds VM budget, but I still don't see a clear answer. I understand there are hard memory limits on devices, and I understand it's not realistic to load up and display or cache large amounts of image data, but there should be away to discard data that's no longer required. For example, imagine this very basic hypothetical app, that emulates a lot of the behavior of the native gallery app: 1. An image gallery that allows the user to peruse images from a remote server. 2. There might be any number of images on that server. 3. The app displays 1 image at a time, and allows a user to go back or forward 1 image at a time through button presses or swiping. 4. There'd be a maximum of 3 images rendered at any one time (so the user can see the one immediately to the left or right of the current image when swiping). All other image data should be discarded. 5. Images are loaded using URL.openStream and Drawable.createFromStream or BitmapFactory.decodeStream. Streams are closed appropriately. 6. Images are sized appropriately *on the server* before being fetched. 7. Loading happens in AsyncTasks. Tasks that are no longer needed (due to moving away from an image with an incomplete task) are cancelled. Any references in the AyncTask are WeaklyReferenced. 8. When any image is no longer required, it's cleared via: A) getBackground().setCallback(null) B) Listeners are set to null C) setImageDrawable/Bitmap(null) D) removeView This simple construct, that takes into account all the suggest practices I'm aware of, will inevitably crash with an OOM error at some point. Using BitmapFactory.Options inSampleSize and inPreferredConfig will delay the inevitable, but not forever, and at the cost of image quality. In this example, I've used remote images, but the issue exists with images stored in /assets/ or in internal memory, etc. My feeling is that if we can display X amount of image data at one point, and we take all steps to remove that image data from memory, we should be able to display that same amount of data later, without having to compensate for what has happened before. With the sheer quantity of questions about this very issue, I'd hope to have a standard solution documented, but if there is one, I can't find it. I've seen answers posted by Romain Guy, who otherwise seems very generous with his knowledge and active in the community, that say something like Simple. Don't use so much memory. OK. Tell me how. Am I missing something fundamental? Is there a way to discard image data once it's no longer being used? What is missing from the above to create a simple photo gallery? Assuming the built-in gallery app uses the FW, I imagine there has to be a way... TYIA. -- 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] Fetching remote image data - byteArray vs createFromStream vs decodeStream
I've been looking at the source for several open-source image loaders, and am comparing the approaches. Looks like when processing the image data, most involve URL.openStream, but from there it looks like there are a couple different ways of decoding that stream to a Bitmap: 1. URL.openStream, then BitmapFactory.decodeStream 2. URL.openStream, then Drawable.createFromStream 3. URL.openConnection().getInputStream() then convert to byteArray, then BitmapFactory.decodeByteArray I see there's a slight difference between #2 and the others - you get a Drawable, but you don't get to specify decoding or sampling, so this seems less preferable (you can always wrap the bitmap in BitmapDrawable later, and inPreferredConfig can be critical). Anything else? What about the difference between #1 and #3 - is there any benefit to converting to a byteArray first, then decoding that? And as regards the first part - is there any difference between URL.openStream and URl.openConnection().getInputStream()? They both just return the same InputStream, no? TYIA. -- 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] Event propagation
The Android FW event model is a little confusing. Since we're generally limited to a single listener, I've run into a couple issues I'm not sure how to handle correctly. In both cases, I was able to eventually get the net result to work, but generally with some hacky workarounds. I wonder if I'm missing some fundamental concepts. The first and most common example would be a widget with default touch event handler, yet still accept other listeners normally. E.g., let's say I have a class that has several views. On the main container (layout), I either add an onTouchListener or override onTouchEvent to perform visual feedback while the finger is down. If I return false, ACTION_UP doesn't fire since it didn't handle ACTION_DOWN. If I return true, ACTION_UP fires, but listeners assigned with setOnClickListener never fire, since the event was already consumed. What's the best practice here? -- 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: Event propagation
It looks like returning super.onTouchEvent(event); works. -- 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
Re: [android-developers] TabHost widget causes FC after upgrade
Here's the basics of the tabhost:
public class ChooserView extends TabHost {
public FrameLayout tabContent;
public TabWidget tabs;
public ChooserView(Context context) {
super(context);
setId(android.R.id.tabhost);
setBackgroundResource(R.drawable.cobblestone);
LinearLayout ll = new LinearLayout(context);
ll.setLayoutParams(new LayoutParams(LayoutParams.FILL_PARENT,
LayoutParams.FILL_PARENT));
ll.setOrientation(LinearLayout.VERTICAL);
addView(ll);
tabContent = new FrameLayout(context);
tabContent.setId(android.R.id.tabcontent);
tabContent.setLayoutParams(new
LinearLayout.LayoutParams(LayoutParams.FILL_PARENT,
LayoutParams.WRAP_CONTENT, 1f));
ll.addView(tabContent);
tabs = new TabWidget(context);
tabs.setId(android.R.id.tabs);
tabs.setStripEnabled(false);
tabs.setBackgroundDrawable(new
GradientDrawable(GradientDrawable.Orientation.TOP_BOTTOM, new int[] {
0x8800, 0x } ));
tabs.setLayoutParams(new LayoutParams(LayoutParams.FILL_PARENT,
LayoutParams.WRAP_CONTENT));
ll.addView(tabs);
And adding tabs with this:
public void registerTab(String label, int icon, Intent target){
Drawable drawable = getResources().getDrawable(icon);
TabSpec spec = newTabSpec(label)
.setIndicator(label, drawable)
.setContent(target);
addTab(spec);
called in the activity like so...
intent = new Intent().setClass(this, SitesActivity.class);
tabHost.registerTab(Sites, R.drawable.ic_tab_sites, intent);
The exact contents of the res folder is pretty long, but it definitely does
contain all the referenced files.
Again, this works fine in my device, and has worked for months on their
device...
Thanks for taking the time to help with this.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] TabHost widget causes FC after upgrade
I wrote a small app for a colleague, that uses a TabHost widget. He said he upgraded his phone's OS recently and the app now crashes when attempting to access the Activity containing the TabHost. After some remote support, I was able to get little of the log: Caused by: android.content.res.Resources$NotFoundException: Resource ID #0x0 at android.content.res.Resources.getValue(Resources.java:1018) at android.content.res.Resources.loadXmlResourceParser(Resources.java:2105) at android.content.res.Resources.getLayout(Resources.java:857) at android.view.LayoutInflater.inflate(LayoutInflater.java:394) at android.widget.TabHost$LabelAndIconIndicatorStrategy.createIndicatorView(TabHost.java:565) at android.widget.TabHost.addTab(TabHost.java:223) All resources are in there. It works fine on my device. I'm not sure about the specifics of the upgrade he made - he's trying to find out but I won't have that information for at least a day I notice the line regarding LayoutInflater.inflate - not sure if it matters (I kind of doubt it), but the TabHost was instantiated dynamically (Java, not XML)... I wonder if a newer version of TabHost requires an XML-based instantiation...? Any ideas? TYIA. -- 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] Prevent a click from being consumed, to pass to containers onTouchEvent
I've got a container that allows 2-d scrolling, fling, pinch etc. This has several layers within it - a viewgroup for image tiles, another for path drawing, another for markers, etc. This all works fine. However, in one particular implementation I have several invisible buttons to indicate hotspots (which are basically ImageViews with transparent backgrounds). When tapped, an action occurs. The problem is that with these hotspots (which cover a good deal of the entire area), the touch event is consumed and not passed to the container's TouchEvent, so the container does not scroll. My first attempt was to create a custom view for the hotspots, and override onTouchEvent, returning false on ACTION_DOWN and true on ACTION_UP (so the event fires when the finger goes up, which is fine). However, it seems that when returning false on ACTION_DOWN prevents ACTION_UP from ever firing. I also tried overriding onInterceptTouchEvent on the scrolling container, and stealing the ACTION_DOWN event from child views - this had the same result. How can I continue to drag the container (whether or not the down event happened on a hotspot/child view), and react on ACTION_UP when a hotspot is clicked? TYIA. -- 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
Re: [android-developers] Prevent a click from being consumed, to pass to containers onTouchEvent
Thanks for the reply. Imagine that over 75% of the scrollable area was covered by these hotspots - I need the ACTION_DOWN to return true so that the click event does fire when the finger goes up (on that same child view), but *also* pass the event to the scrolling container's onTouchEvent - so it's not really a question of either/or, but rather do both. The catch-22 here seems to be that if I return true, the event is consumed, and therefore not passed to the container. If I return false, the event is not consumed, so the container does scroll, but when the finger goes up no event fires. In looking at the source you linked, it looks like they're intercepting ACTION_DOWN only if it's currently flinging, so I'm not sure how they get it to work... -- 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] Android, SQLite, massive (5000%+) loss of performance on a certain query, on a certain device
I'm rewriting a simple translation app with a SQLite db. There is an extreme hit to performance between two queries, but only on certain devices. One query lists the english words in a ListView, the other lists the secondary language in a list view. The data is structured differently, and is from a remote server. Both are single SQL statements, run via db.rawQuery. Both use AsyncTask to keep heavy lifting in another thread. On both devices, the english query returns almost instantly (less than 1 second, every time): return db.rawQuery(select _id as id, english as label from english_words order by english collate nocase, null); On one device, the secondary_langauge query returns almost instantly as well. No problem there, ever. This is a Samsung Galaxy SII. On another device (Samsung Nexus S), this query takes around 30 seconds. This query has some joins, as follows: return db.rawQuery(select definitions._id as id, secondary_language as label from english_words join definition_bridge on english_words._id=definition_bridge.word_id join definitions on definitions._id=definition_bridge.definition_id order by secondary_language, null); I ran it in the emulator once, and got the same result as the Nexus S (the 30 second hang). It took a little 1.5 hours to download and parse the returns from the server on the emulator (which takes a few seconds on either device), so I gave up on further debug with the emulator at that point. This is the only difference between the two operations. The listView is the same, the adapter is the same, the AsyncTask is the same. The number of rows returned is different - there are about 2000 english words, and a little over 3000 words in the other language. I don't think this explains the vast difference in performance. I took the query out of the AsyncTask to see if I could get some more debug info, and did get an ANR: at android.database.sqlite.SQLiteQuery.native_fill_window(Native Method) at android.database.sqlite.SQLiteQuery.fillWindow(SQLiteQuery.java:73) at android.database.sqlite.SQLiteCursor.fillWindow(SQLiteCursor.java:287) at android.database.sqlite.SQLiteCursor.getCount(SQLiteCursor.java:268) at com.whatever.adapters.WordListAdapter.getCount(WordListAdapter.java:39) I rewrote the adapter's getCount method to return a cached count (determined during instantiation). After, I didn't get an ANR again, but otherwise the performance was not improved and the query still took around 30 seconds. I'm totally at a loss. As mentioned, everything but the queries is identical. And on the Galaxy SII, there is no problem at all - less than a second to populate the ListView, even under abuse (touching the button that launches the request as fast as I could). At this point, I'm wondering if it'd be better to abandon SQLite entirely, and using a Java model to manage data. Assuming I can't get the SQLite version to perform reasonably, what could I expect in terms of performance using Collections (with the number of entries mentioned above), when I need to do a search for example (which I imaging would require iterating over the whole thing on each key event). Any advice? TYIA. -- 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: Android, SQLite, massive (5000%+) loss of performance on a certain query, on a certain device
that was it - i had forgotten to pk one id column in one of the join tables - adding that and it's night-and-day - under 1 second, compared with ~30 before. thanks all for reinforcing that concept. very glad i didn't try to convert the whole thing to a Java model. -- 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: Window, WindowManager, PolicyManager classes - or - implementing a custom overlay
So the solution to adding a new layer via WindowManager is pretty simple: WindowManager.LayoutParams wlp = new WindowManager.LayoutParams(); // ... position, dimension, ets WindowManager wm = (WindowManager) getSystemService(window); wm.addView(someView, wlp); However, I'm unable to apply any programmatic animations to a view added in this manner. WindowManager.LayoutParams accepts animation resources, but this is not as flexible as I need. Is there a trick to using animation to views added to a WindowManager, or is this not possible? TYIA -- 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
Re: [android-developers] Re: Window, WindowManager, PolicyManager classes - or - implementing a custom overlay
And animating child views is similarly limited? -- 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] Window, WindowManager, PolicyManager classes - or - implementing a custom overlay
I'm creating a component that needs to appear above (and separate from) the existing UI, similar to the Dialog, PopupWindow and ContextMenu widgets. I'd like it to be modular and portable (again like those widgets I just mentioned), so pre-supposing a particular type of layout for the Activity's contentView isn't realistic. The component is similar in function to iOS's ActionSheet (I should stress similiar - I'm not trying for a direct port or emulation). Using the PopupWindow class I got close, but haven't found a way to animate outside of setAnimationStyle which requires an XML animation resource (which I'd like to avoid). I figured it wouldn't take a direction startAnimation invocation, but did think that I could use programmatic animations on the contentView or child views, but those fail without errors as well. In looking at the source for the Dialog and PopupWindow classes, it looks like they accomplish this using the Window and WindowManager classes, but I'm not able to find much in the way of documentation on them. In trying to clone Dialog and PopupWindow as a jumping-off point, I get errors - specifically as regards com.android.internal.policy.PolicyManager (which seems to be a core requirement, as the window is provided by the makeNewWindow method), which is entirely absent from the docs. Is there a way to leverage the approach used in those classes to accomplish what I'm describing? If not, is there another way? TYIA. -- 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: application failing on similar devices
The adapter takes a Cursor that's a product of a single SQLite query. On my device I can toggle between the two adapters almost instantly, with virtually no wait time - I can touch each button alternately as quickly as I can physically with no problems in rendering (dozens of times in a few seconds), yet on his device a single touch creates the issue. Can there really be that much difference in the two devices (mine is a Samsung Galaxy SII on 2.3.6, his is a Samsung Nexus S on 2.3.7)? On Saturday, March 17, 2012 8:49:34 AM UTC-5, Chris Mawata wrote: Looks like it is taking too long to populate the ListView. You are probably doing work on the UI thread that takes more than a few seconds. On Mar 16, 7:34 pm, momo dun...@gmail.com wrote: I debug with a Samsung Galaxy SII, running 2.3.6. I created an app that runs fine, every time, even under stress, on this device. I uploaded for a colleague in another state, using a device with 2.3.7 (I believe it's a Nexus One). On his device, the app gives a Not responding - Force Close or Wait dialog when clicking a button that switches a ListView's adapter between 2 DB Cursors. I tried on the emulator. Literally an hour and 45 minutes later (most of this time was spent converting JSON from a remote server to a local SQLite DB on the device, which happens only once during install, and I don't believe has any bearing on the issue I'm describing), I was able to recreate the problem, but nothing was reported in logcat. Any ideas why I'm seeing this different results? My device works every time, his fails every time. I've tried targetting 2.1 and 2.2 - both have the same results on both devices and the emulator. TYIA -- 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
Re: [android-developers] Re: application failing on similar devices
I think the only real chance of success is for me to go find the device locally. More generally, do you see anything especially problematic with this: 1. a single sqlite query joining 2 tables via a 3rd bridge table, selecting 2 colums with an order by and collate unicode, that'll return 3000-4000 rows. invoked with db.rawQuery. 2. pass that to a simple custom adapter (BaseAdapter extension, getView creates a single textview, recycles views when possible) 3. a single ListView gets the adapter updated via setAdapter (not using notifyDataSetChanged because the cursors are from two different datasets). Thanks for your help. -- 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
Re: [android-developers] Re: application failing on similar devices
thanks all - good info. -- 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] application failing on similar devices
I debug with a Samsung Galaxy SII, running 2.3.6. I created an app that runs fine, every time, even under stress, on this device. I uploaded for a colleague in another state, using a device with 2.3.7 (I believe it's a Nexus One). On his device, the app gives a Not responding - Force Close or Wait dialog when clicking a button that switches a ListView's adapter between 2 DB Cursors. I tried on the emulator. Literally an hour and 45 minutes later (most of this time was spent converting JSON from a remote server to a local SQLite DB on the device, which happens only once during install, and I don't believe has any bearing on the issue I'm describing), I was able to recreate the problem, but nothing was reported in logcat. Any ideas why I'm seeing this different results? My device works every time, his fails every time. I've tried targetting 2.1 and 2.2 - both have the same results on both devices and the emulator. TYIA -- 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] positioning a view based on it's calculated dimensions
I've got a tiled pan-n-zoom component that uses several FrameLayouts to position image tiles (that scale), markers (that move, but don't scale) and controls (which neither move nor scale). It works fine. Markers are positioned in a FrameLayout with topMargin and leftMargin. So far so good. When a marker is touched, I need to open a little popup, at the same position as the marker that was touched *but offset by the dimensions of the popup*. That's to say that if the popup is 100 pixels wide and 50 pixels tall, and the marker touched was at 800 x and 1100 y, the popup should be at 750 x (postion of marker minus half the width of the popup) and 1050 y (position of the marker minus the full height of the popup). The effect is like a tooltip - a little nub points down at the marker, etc. the ideal logic would be x position is layoutParams.leftMargin - (getWidth() / 2), y position is layoutParams.topMargin - getHeight() - but obviously that wouldn't work. the popups should be in a separate layer (viewgroup) than the markers. The popup dimensions are flexible, based on the text to be displayed, and need to be calculated. Obviously the dimensions aren't available until after layout happens. It looks like I can get the dimensions of the children during onLayout and the second pass of onMeasure, but if I update and re-assign LayoutParams (with modified top/leftMargins), during onLayout, sounds like an infinite loop. I tried setting a flag so I could catch just the first pass, but this failed - I don't really expect this to be the right approach in any case. I also tried getting the dimensions during onLayout, then in onDraw using canvas.translate(offsetX, offsetY), but this caused it to be clipped and drawn outside the available region. What's the best way to get these dimensions and position these views accordingly? (should mention that a RelativeLayout is not an option - the popups should be in a different viewgroup than the markers). TYIA. -- 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: positioning a view based on it's calculated dimensions
the answer is to manage positioning by override onLayout of the containing
ViewGroup, rather than the View itself.
E.g.,
@Override
protected void onLayout(boolean changed, int l, int t, int r, int b) {
int count = getChildCount();
for (int i = 0; i count; i++) {
View child = getChildAt(i);
if (child.getVisibility() != GONE) {
MyCustomLayout.LayoutParams lp = (MyCustomLayout.LayoutParams)
child.getLayoutParams();
int w = child.getMeasuredWidth();
int h = child.getMeasuredHeight();
int x = lp.left - (int) (w / 2f);
int y = lp.top - h;
child.layout(x, y, x + w, y + h);
}
}
}
(note that the above example specifically is untested, but i've tested the
basic premise and it works)
--
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] Custom layout - why is behavior different when laying out a ViewGroup (vs View) as a child
I've got a custom layout for positioning tooltips on a pan-n-zoom tiled map
(also custom), in reaction to touch events. The tooltips should appear
above and centered to the marker that fired it.
Everything works perfectly when using normal Views (ImageView, TextView) as
children. However, when trying to use a ViewGroup (e.g., a RelativeLayout),
the child does not appear at all.
I added some logging to onLayout, and it was reporting 0 for
child.getMeasuredWidth()/Height(), so I extended RelativeLayout and
overrode onMeasure in order to supply the correct dimensions. The
dimensions are now logging correctly, but still the child ViewGroup does
not appear. This doesn't seem like it's a necessary step in any case - I'd
expect to be able to use layouts as children normally.
Why is there a difference? Why would a simple View appear and position
exactly as expected, but child layouts fail to render at all?
Here's a summarized version of the custom layout:
public class TooltipLayout extends ViewGroup {
public TooltipLayout(Context context) {
super(context);
}
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
//...
}
@Override
protected void onLayout(boolean changed, int l, int t, int r, int b) {
int count = getChildCount();
for (int i = 0; i count; i++) {
View child = getChildAt(i);
if (child.getVisibility() != GONE) {
TooltipLayout.LayoutParams lp =
(TooltipLayout.LayoutParams) child.getLayoutParams();
child.layout(lp.x, lp.y, lp.x + child.getMeasuredWidth(),
lp.y + child.getMeasuredHeight());
}
}
}
public static class LayoutParams extends ViewGroup.LayoutParams {
public int x;
public int y;
public LayoutParams(int width, int height, int left, int top) {
super(width, height);
x = left;
y = top;
}
}
}
TYIA.
--
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] unable to find source of dispatchDraw / drawChild error
In a custom component that displays a small-scale tiled map (similar to iOS CATiledLayer), I'm rendering tiles on-demand based on the scale level the user has supplied (via pinch events or zoom controls). I'm using an AsyncTask to load up the bitmaps and rendering them with publishProgress. This generally works fine, but if a user initiates a pinch event (and triggers a scale action) while an tile set (that's no longer valid because a new one qualifies) is transitioning out, I get a force-close. Logcat mentions a NullPointerException in a call to dispatchDraw, but I can't find out where the issue is happening specifically. I know that there's no enough info here to determine the specific issue or a fix, and the code is too long to be appropriate in a list discussion, but any insight as to where I could find the source of the error specifically would be great. I've tried try/catches all over the place, and sending the exception to the output with a note as to the source, but haven't yet caught anything. I'll paste a copy of the log: 02-28 21:03:40.385: W/dalvikvm(3978): threadid=1: thread exiting with uncaught exception (group=0x4001e578) 02-28 21:03:40.385: E/AndroidRuntime(3978): FATAL EXCEPTION: main 02-28 21:03:40.385: E/AndroidRuntime(3978): java.lang.NullPointerException 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.ViewGroup.dispatchDraw(ViewGroup.java:1372) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.ViewGroup.drawChild(ViewGroup.java:1644) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.ViewGroup.dispatchDraw(ViewGroup.java:1373) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.View.draw(View.java:7022) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.widget.FrameLayout.draw(FrameLayout.java:357) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.ViewGroup.drawChild(ViewGroup.java:1646) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.ViewGroup.dispatchDraw(ViewGroup.java:1373) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.ViewGroup.drawChild(ViewGroup.java:1644) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.ViewGroup.dispatchDraw(ViewGroup.java:1373) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.View.draw(View.java:7022) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.widget.FrameLayout.draw(FrameLayout.java:357) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.ViewGroup.drawChild(ViewGroup.java:1646) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.ViewGroup.dispatchDraw(ViewGroup.java:1373) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.ViewGroup.drawChild(ViewGroup.java:1644) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.ViewGroup.dispatchDraw(ViewGroup.java:1373) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.View.draw(View.java:7022) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.widget.FrameLayout.draw(FrameLayout.java:357) 02-28 21:03:40.385: E/AndroidRuntime(3978): at com.android.internal.policy.impl.PhoneWindow $DecorView.draw(PhoneWindow.java:1917) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.ViewRoot.draw(ViewRoot.java:1562) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.ViewRoot.performTraversals(ViewRoot.java:1298) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.view.ViewRoot.handleMessage(ViewRoot.java:1900) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.os.Handler.dispatchMessage(Handler.java:99) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.os.Looper.loop(Looper.java:130) 02-28 21:03:40.385: E/AndroidRuntime(3978): at android.app.ActivityThread.main(ActivityThread.java:3691) 02-28 21:03:40.385: E/AndroidRuntime(3978): at java.lang.reflect.Method.invokeNative(Native Method) 02-28 21:03:40.385: E/AndroidRuntime(3978): at java.lang.reflect.Method.invoke(Method.java:507) 02-28 21:03:40.385: E/AndroidRuntime(3978): at com.android.internal.os.ZygoteInit $MethodAndArgsCaller.run(ZygoteInit.java:907) 02-28 21:03:40.385: E/AndroidRuntime(3978): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:665) 02-28 21:03:40.385: E/AndroidRuntime(3978): at dalvik.system.NativeStart.main(Native Method) TYIA -- 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] ADB with docking station
I would like to debug on my device while it's attached to a docking station, but ADB does not recognize the device when connected that way. ADB works fine when the device is connected directly to my computer. Is there a workaround? TYIA. -- 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: ADB with docking station
I hadn't heard of it until your reply - I googled it and found an app for it - installed but when I tried to run it, said my phone must be rooted. Is there a way to do what you're describing without the above? On Feb 21, 1:29 pm, Chrystian Vieyra chrys.vie...@gmail.com wrote: Have you tried wireless adb? -- 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] Application Pc-Android
je besoin d'une application qui me permet d'envoyer des message de Pc vers Android :) -- 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: Android custom tween - Timer vs ScheduledThreadPoolExecutor, or alternative
On Feb 11, 4:35 am, skink psk...@gmail.com wrote: forgot to mention that built-in animations run with no delay - in short they just call invalidate() in drawing phase in order to make next frame of animation pskink interesting - before reading this, i spent some time looking around for the exact mechanism and wasn't able to find it. i did override Animation and was able to get interpolatedTime back during the update process (which is really the only thing that matters - everything can be handled with just that number), but for reasons I still don't understand some of the visual effects are a little off. perhaps it has something to do with that? briefly, i'm zooming into a map (not a MapView - imagine a map of a building's interior). when this happens, lots of things besides a scale effect need to be updated - position of markers (which are not scaled, just repositioned), the layout dimensions of several layers need adjusted, scroll position is maintained or updated, etc. I've written a simple coordinate (lat/lng) to point (x/y) translater, and before the zoom animation goes i find the coordinate at the center of the screen, and after each frame I scrollTo the x/y of the equivalent point, so the center point stays consistent. when using a Timer/TimeTask, or Thread/Thread.sleep (or during pinch events, or with no animation at all), this works perfectly - but when i use an extended Animation with interpolatedTime, it tends to wander before finally settling on the correct position. it's confusing because it really looks like it should be the same thing - with the thread or timer versions, I just get back an interpolated time very similar to the output of the extended Animation, and pass that to a method that handles scaling, positioning, etc. unless there's an obvious answer why this happens, i suppose i'll move on to the timer-less straight Handler approach you mentioned initially (the timer/thread version uses a handler too, but in response run()). -- 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: Android custom tween - Timer vs ScheduledThreadPoolExecutor, or alternative
hey pskink, i tried that pure-Handler approach you first suggested, and it works a treat - in fact i was able to omit the delay entirely, just sendEmptyMessage (and use a simple time keeper class to determine the delta) - very smooth, very simple. thanks a lot for your help. -- 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: Android custom tween - Timer vs ScheduledThreadPoolExecutor, or alternative
i had tried something very similar:
package com.whatever.tests;
import android.view.animation.Animation;
import android.view.animation.Transformation;
public class MapScaleAnimation extends Animation {
private OnUpdateListener onUpdateListener;
public void setOnUpdateListener(OnUpdateListener listener){
onUpdateListener = listener;
}
@Override
protected void applyTransformation(float interpolatedTime,
Transformation t) {
if(onUpdateListener != null){
onUpdateListener.onUpdate(interpolatedTime);
}
}
public interface OnUpdateListener {
public void onUpdate(float interpolatedTime);
}
}
then I just implemented OnUpdateListener, gave it an onUpdate method
to handle the delta, and ran it on a dummy view. It looked like it
should be perfect - logged the interpolatedTime (delta) that I
expected, scaled correctly, etc. - there was just this strange
wandering effect when attempting to re-center the map to the same
pivot point (center of viewport) that was visible when the tween was
initiated. I used the same re-centering logic with each approach
(Timer, Thread, Handler, and Animation), and only the Animation
version created that wandering effect - I assume it probably has
something to do with the sequence of onDraw and invalidate, but no
matter what I tried I couldn't suppress it. While the Handler
approach is short, sweet and logical (and doesn't require the dummy
view), I'd still be interested to know what might have caused it.
I've only been working with Android and Java for a couple weeks and am
probably missing something fundamental...
--
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: Android custom tween - Timer vs ScheduledThreadPoolExecutor, or alternative
hmm, seems OK to me, anyway you have working (not bad) solution w/
Handler :)
what i like in Animation approach is that interpolatedTime [0..1] but
if it doesn't work... tough luck
pskink
I just created a custom class to get interpolatedTime...
package com.whatever.utils;
public class TimeTracker {
private long startTime;
private long duration;
private boolean complete;
public TimeTracker(){
mark();
}
public TimeTracker(long len){
setDuration(len);
mark();
}
public void setDuration(long len){
duration = len;
}
public void mark(){
startTime = System.currentTimeMillis();
complete = false;
}
public long getEllapsed(){
return System.currentTimeMillis() - startTime;
}
public boolean atEnd(){
return complete;
}
public double getProgress(){
double ellapsed = (double) getEllapsed();
double total = (double) duration;
double factor = ellapsed / total;
factor = Math.min(1, factor);
factor = Math.max(0, factor);
complete = (factor == 1);
return factor; // i can apply easing here with standard penner
equations...
}
}
one last question though - since the Handler is running in the main UI
thread, are there potential issues? The animation is brief (500ms)
and I'll probably try to disable any other interactions while it's
happening, but I'm pretty new to multithreaded environments and wonder
if there's a likely problem with how I've got it set up now:
private Handler handler = new Handler() {
@Override
public void handleMessage(final Message message) {
switch (message.what) {
case TWEEN:
try {
double progress = timeKeeper.getEasedProgress(5);
float position = (float) originalValue +
((destinationValue - originalValue) * progress));
setValue(position);
if(!timeKeeper.atEnd()){
sendEmptyMessage(TWEEN);
}
} catch (Exception e) {
}
}
}
};
--
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: Android custom tween - Timer vs ScheduledThreadPoolExecutor, or alternative
On Feb 11, 4:35 pm, Kostya Vasilyev kmans...@gmail.com wrote: This is not a multithreaded environment you've got here. Your code most likely creates the Handler object on the UI thread, and if so, that's where it receives messages. This is correct, since the Android UI framework is not thread-safe and your code should only be touching views from the UI thread. Here is a suggestion for choosing the animation frame rate: you can use View#postInvalidate to mark a view as dirty, and update animation state inside the next onDraw, using actual elapsed time (seems like you already have a class that tracks that). UI rendering is locked to the hardware frame rate, so you won't be redrawing more often than necessary -- and on the other hand, you won't be computing animations that never get drawn. -- K Hi Kostya - thanks for the info - so from what I've presented so far, it sounds stable? For the one particular View that is actually transformed, I am using onDraw and calling invalidate - the other operations based on delta are handled elsewhere. When I said multithreaded environment, I didn't mean the tween specifically - I have other threads doing other things elsewhere in the app occassionally (e.g., requesting data over HTTP), so was referring to the general setup, not this particular task, and wanted to make sure that it wasn't going to bump - am I using the verbiage incorrectly? Thanks again. -- 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] Android custom tween - Timer vs ScheduledThreadPoolExecutor, or alternative
I'm working on a custom tween effect targeting Android 2.2. This is not a straight View animation (many things are happening based on the progress of the tween), so the Animation classes available in 2.2 aren't sufficient (apparently Animator does this but is not available). I've implemented the basic logic (porting JS and AS tweening engines I'd written earlier), and it seems to work fine, but is a little slow. For example, running an interval of 25ms in JS or AS produces a smooth visual effect, but seems chunky in the Android implementation - reducing the interval to 10ms seemed to help some but it certainly isn't as smooth as the built-in animations. I'm using Timer and Timer task - I've read that ScheduledThreadPoolExecutor is preferred but from what I've read the advantages seem to be more to do with exception handling and multiple tasks (I'll only ever have the one tween running). Is Timer particularly slow? If ScheduledThreadPoolExecutor more efficient? Is there another, better alternative that I'm not aware of? TYIA -- 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: Android custom tween - Timer vs ScheduledThreadPoolExecutor, or alternative
thanks for the reply. you'd suggest just using sendMessageDelayed? Would you call each interval as a reaction in handleMessage, or just send a batach of delayedMessages at once with the delay incremented? Would you expect the performance gains to be significant enough to compare to the built-in Animation effects, or is that not realistic? thanks again -- 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: Android custom tween - Timer vs ScheduledThreadPoolExecutor, or alternative
awesome, i'll look into both approaches. thanks for the info -- 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] Constraining FrameLayout dimensions (greater than viewport) using LayoutParams after scaling children
Sorry about the poor title - it's hard to summarize the issue in one line. I'm working on a map tiling system for small-scale maps (imagine building interiors), with zoom and pan functionality. Most of this is working properly, but after a scale operation I try to limit the scrollable area using LayoutParams and think I'm doing it wrong, as the behavior is unpredictable (to me, at least). There's a main container (FrameLayout). On the top layer are the controls and other elements that don't move or scale. The bottom layer is another a FrameLayout with scrolling enabled on both axes (a slightly modified version of http://blog.gorges.us/2010/06/android-two-dimensional-scrollview/). This layer has 2 layers - an ImageView that displays a low-res version of the map on bottom, and another FrameLayout with a grid of ImageView tiles positioned with top/leftMargin. Tiles are rendered on-demand based on what tiles would be visible (on screen), so the low-res bottom layer is visible when scrolling or zooming (before the final viewable area is calculated and the appropriate tiles are rendered). Markers and other elements are contained in another FrameLayout in the scrollable View, above the one that has the 2 map layers (which scale, together) So the heirarchy looks like this: main container scrollable layer maps layer low-res image tile container markers layer controls layer During a pinch event, I zoom the maps layer (inclusive) by overriding onDraw and using canvas.scale, and maintain scroll position using getFocusX/Y. This all works fine. The issue is that I need to re-assign the total scrollable width and height of the scrollable layer, so that scrolling stops at the edge of the (scaled) maps. Initially this works properly, but after a scale operation everything goes haywire. I've tried using LayoutParams(originalMapWidth * scale, originalMapHeight * scale) on every possible combination of the layers to be affected (scrollable, maps, low-res, tiles), but it never lays out correctly - the closest I've gotten is that the width does get properly constrained by the height does not. If I just apply the new LayoutParams to the maps layer, clipping occurs (it looks like the scale factor is being applied twice - this appears to be a red herring and I tried to compensate with simple math (dividing the width/height by the scale, etc) and it never got to a usable point. In looking at the source of the one 3rd-party component I'm using (the 2D scrollview linked above), it looks like the issue might be in there, but my attempts to force it to work with my setup have failed, and I'm not eager to tackle recreating that feature (but I will if I have to). I've got a fairly slimmed down version where I'm trying to target just this issue (no controls, no markers, a single tile set, etc), but it's still pretty long and didn't seem appropriate for a post, but I'm glad to share whatever code would be helpful. Am I missing something obvious about how layouts work? I've been beating up on this one (seeming small) issue for days now, and am making no progress. Any insight would be very much appreciated. TYIA -- 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] Android User Experience and UI refinements
I think Android has a ton of functionalities and that's definitely wonderful. I am not trying to be overally critical since I know the Android team has been working hard and this is highly appreciated. However in all systems, there are rooms for improvement and here are a few areas where I think Android can improve upon: 1) UI refinements - Currently it's actually pretty hard to create good- looking UI in android. This is one of the main reasons why UIs in android look like childplay compared to IPhone apps. Any of the base/ core UI components in android (to be blunt) are not that pretty. To customize and add in the appropriate gradient and create the kind of sophisticated UIs that are comparable to Iphone apps is twice as hard. Having done development in both, this is something Android should target. Overall the android UI is too blocky, too funky, and not stylish. And in some cases, they are moving backwards. The new tabs in Android 2.0 look worse than Android 1.6. The new spinner is also not doing justice either. A focus in this area will be helpful in order to create better UI for android applications. 2) User Experience - Instead of constantly just adding new functionalities, focus on user experience. For example, always having to click the menu key to bring up a menu requires additional clicks that are not necessary. Having to click a back key and guess where the current application UI will take me back to is also not great. Possibly provide a built-in on-screen menu in the framework? Provide a breadcrumb component as part of the framework as well? --~--~-~--~~~---~--~~ 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: Google: please change your release process
I can't agree more. Release beta SDKs for each of your releases for developers or any developers who already has an application in the Market. As changes are being implemented, update the beta SDKs to new versions. This way developers are GIVEN MORE TIME to verify that their apps work. Sigh sometimes I feel the Android team is run very poorly. On Oct 26, 4:22 pm, JP joachim.pfeif...@gmail.com wrote: If this is true... insulting to those that conduct open source development truly open source. Makes me consider to change the licensing of the stuffs I've released on Apache 2.0 back to GPL. On Oct 26, 2:30 pm, wimbet wim...@gmail.com wrote: If Google likes your app, you can get early access to the Android 2.0 code. http://androidandme.com/2009/10/news/google-hand-picks-developers-for... --~--~-~--~~~---~--~~ 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: Alarm is canceled if app is stopped
Maybe make another API call that allows killing the service, notifications, and etc of an application except for alarms? I think other applications are affected the most by their alarms getting totally wiped out by another application. Too many task killing applications are using this API call. I am sure if a safer call is available, most of them will switch to it. On Oct 12, 4:12 pm, Dianne Hackborn hack...@android.com wrote: *sigh* I knew I shouldn't have made that API public. :} On Mon, Oct 12, 2009 at 4:09 PM, Lazarus 101 lazarus...@gmail.com wrote: Thanks Dianne for the quick answer. Actually TasKiller is not automatically killing apps, but it has a widget that allows users to kill (almost) all apps with one click. Most of the Android users that I know are using something similar to TasKiller so this is a tricky problem, users will blame my app for not doing what it says it does. I saw there is a PACKAGE_RESTARTED broadcast but obviously the restarted package does not receive the notification so there's not much I can do to fix this problem... Having applications that can affect the functionality of every other apps installed on the system is not such a good idea IMHO. A Task Manager is needed but the user should be clearly informed that the apps he choses to kill are not working anymore because that's exactly what he wanted. Also the permission is called restart other application it should be kill other applications, that's why I thought alarms are not affected by this and that services are getting restarted (I saw services being restarted after crashes or after being killed due to lack of memory so I though it's the same behaviour when calling ActivityManager.restartPackage). On Oct 12, 11:22 pm, Dianne Hackborn hack...@android.com wrote: That is intentional. Stopping an application is there for the user to stop everything associated with it -- processes, alarms, services, notifications, etc. They will not be restarted until someone explicitly does so (typically this would be the user re-launching the app and having it do the appropriate thing). It sounds like TasKiller is abusing this API. The API is there for the user to explicitly stop an app from running without going to the most extreme measure of uninstalling the app. Trying to use it to automatically stop things behind the user's back seems... questionable, and probably not what the user actually wants. On Mon, Oct 12, 2009 at 1:00 PM, Lazarus 101 lazarus...@gmail.com wrote: I have an app that does some polling every 2 hours. I set a repeating alarm that starts a service but I have noticed that if I use some task manager (e.g. TasKiller) to kill my app then the polling will not be performed from that moment on. I know this because I store the time of the last poll, I have also checked the server logs and there are no requests received from the client after I force close my app. Is this the way alarms work or should I look somewhere else for a crash or smth? because if alarms really get canceled then how should we implement the polling? I'm also interested in what happens with a running service if it gets killed from another app (I assume all task managers are using ActivityManager.restartPackage() to kill other apps), does it get restarted? -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] How to prevent Failed Binder Transaction
I have a small piece of code that does this Process process = Runtime.getRuntime().exec(COMMAND); InputStream in = process.getInputStream(); InputReader inr = new InputStreamReader(in); BufferedReader br = new BufferedReader(inr); Then I go through a while loop to read the content of the inputStream using the BufferedReader. This works fine but every now and then it will throw a Failed Binder Transaction and hang my application. Is there any ways of getting around this? I am guessing the inputstream is returning too big of a chunk and the app can't handle it? I tried doing stuff like BufferedReader br = new BufferedReader(inr, 1000) to make it read smaller chunks but it didn't help. Please help me. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
