Re: [android-developers] Can you send parcelable across processes without aidl ?
Yes but only if the receiving process knows how to unparcel the object. On Jul 9, 2012 11:29 AM, "Agus" wrote: > Can you send parcelable across processes without aidl ? > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] EventQueue.peekMessage
You can use a Canvas to draw an image into a Bitmap on a background
thread. Then when that's finished, draw the Bitmap into the View (in
onDraw) on the main thread.
I'd be worried about a drawing function that takes several seconds to
run. We like to keep drawing well under 16ms in order to ensure a
good framerate and smooth animations.
Jeff.
On Thu, Jul 7, 2011 at 9:53 AM, andrei-dmitriev
wrote:
> The longRoutine is the drawing procedure which may take up to several
> seconds.
>
> Yep, I tried to relay that onto another thread and draw into the SurfaceView
> but the problem I've faced is that
> the original view(s) are still repainted with onDraw() thus the content (the
> background thread is rendering all the time) is missing. It's called from
> the deep android internals so I don't believe I trigger it somehow - it's
> just a reaction on the invalidate().
> Well, it is covered with blank rectangle but I can see the actual content
> under that rectangle.
> BTW that looks like a thread condition over there as sometimes (very rarely)
> I can see the content for a few moments which then becomes covered with
> background color.
>
> So far I also tried to:
> a) setWillNotDraw(true);
> b) unset the background color of the view
>
> Interestingly that in a sample application (a SurfaceView in a RelativeView)
> the b) approach does help and since that we don't have such a problem there.
>
> So the problem now could be read like this (I'm starting to think there is
> no way to peek events from the queue, right? :) :
> How to switch the SurfaceView's onDraw() method off?
> Any cluea of what can make it been called also appreciated.
>
> Thanks,
> Andrei
>
>
> 07.07.2011 17:18, Mark Murphy пишет:
>>
>> On Thu, Jul 7, 2011 at 9:11 AM, andrei-dmitriev
>> wrote:
>>>
>>> why there is no a way to poll or peek the message from the event queue?
>>> I want it to implement the break for the routine running on the UI
>>> thread.
>>> private void longRoutine() {
>>> while (flag){
>>> if (queue.peekMessage() != null) {
>>> return;
>>> }
>>>
>>> }
>>> }
>>>
>>> Or am I missing something and actually a way exists?
>>
>> It's called a "background thread". All the cool programmers use them.
>>
>> Why do you think that you need longRoutine() to be on the main
>> application thread?
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Multi-touch pointer ids on Sony Xperia Play & spurious ACTION_DOWN events
>
> }
>
> break;
>
> case MotionEvent.ACTION_MOVE:
>
> {
>
> // There are reports that move touch evens can flood the
> system. The suggested
>
> // solution is to sleep after a move. I don't want to
> sleep unless I have to
>
> // since it could cause controls to be unresponsive. So
> instead I will only sleep
>
> // if we get more than one move event within a 60Hrz
> frame and then I will only
>
> // sleep as much as I need. It's very much along the
> lines of a update loop.
>
> long currentTime = System.currentTimeMillis();
>
> long elapsed = currentTime -
> m_LastMoveEventTime;
>
> if ( elapsed< 16L )
>
> {
>
> try
>
> {
>
> Thread.sleep( Math.max( 0, 16L - elapsed ) );
>
> }
>
> catch( InterruptedException e )
>
> {
>
> Thread.currentThread().interrupt();
>
> }
>
> break;
>
> }
>
> for( int index = 0; index< numPointers; ++index )
>
> {
>
> ptrId = event.getPointerId( index );
>
> if ( ptrId>= 0 )
>
> {
>
> pe = (PointerEvent)m_PointerEvents.alloc();
>
> if ( pe != null )
>
> {
>
> pe.owner = m_PointerEvents;
>
> pe.action = PointerEvent.ACTION_DRAG;
>
> pe.id = ptrId;
>
> pe.x = (int)event.getX( index );
>
> pe.y = (int)event.getY( index );
>
> m_App.getGame().postUIEvent( pe );
>
> //Log.v( "POINTER", te.toString() );
>
> }
>
> }
>
> }
>
> m_LastMoveEventTime = currentTime;
>
> }
>
> break;
>
> }
>
> return true;
>
> }
>
> Leigh
>
> On 5/17/2011 2:01 AM, Jeffrey Brown wrote:
>
>
>
>
>
>
>
>
>
> > Pointer IDs are arbitrary integers. The only guarantee is that they
> > will be unique for a given finger as long as that finger remains down.
> > Once the finger goes up, the id may be reused for a different finger,
> > or it may not. It really depends.
>
> > The problem with spurious ACTION_DOWN events is strictly a software
> > issue, not hardware. It happens when applications filter or modify
> > the stream of touch events in a manner that causes them to become
> > incomplete or inconsistent. The bugs can be quite subtle.
>
> > Jeff.
>
> > On Mon, May 16, 2011 at 3:56 PM, MichaelEGR wrote:
> >> ugh! Thanks for posting this message as this is a gnarly one and an
> >> example of ODM fragmentation if pointed IDs are not indexing correctly
> >> to the proper point data at least. I never was impressed by the
> >>multitouchAPI and always thought it wasn't thought out well and
> >> simply just tacked onto MotionEvent. Dirty as you say it is correct. I
> >> also wasn't pleased with the lack of documentation and unclear
> >> contract. Perhaps this lack of documentation led to this potential ODM
> >> fault. As for spurious ACTION_DOWN events this could be from varied
> >> quality of touchscreen hardware too.
>
> >> So from my reading of your post you are saying that pointer IDs are
> >> not recycled and that the data of subsequent pointer IDs is not
> >> correct at the specified array index?
>
> >> Not looking forward to coming up with a solution for my platform /
> >> middleware / custom event system and certainly am not excited if I
> >> need to buy an Experia Play just for this, but w/ talking with Robert
> >> G. it sounds like button support on this device is a bit wacky too. If
> >> I understand correctly button presses don't generate key events? Hrm;
> >> I hope that
[android-developers] Re: Multi-touch pointer ids on Sony Xperia Play & spurious ACTION_DOWN events
Pointer IDs are arbitrary integers. The only guarantee is that they will be unique for a given finger as long as that finger remains down. Once the finger goes up, the id may be reused for a different finger, or it may not. It really depends. The problem with spurious ACTION_DOWN events is strictly a software issue, not hardware. It happens when applications filter or modify the stream of touch events in a manner that causes them to become incomplete or inconsistent. The bugs can be quite subtle. Jeff. On May 16, 3:56 pm, MichaelEGR wrote: > ugh! Thanks for posting this message as this is a gnarly one and an > example of ODM fragmentation if pointed IDs are not indexing correctly > to the proper point data at least. I never was impressed by themultitouchAPI > and always thought it wasn't thought out well and > simply just tacked onto MotionEvent. Dirty as you say it is correct. I > also wasn't pleased with the lack of documentation and unclear > contract. Perhaps this lack of documentation led to this potential ODM > fault. As for spurious ACTION_DOWN events this could be from varied > quality of touchscreen hardware too. > > So from my reading of your post you are saying that pointer IDs are > not recycled and that the data of subsequent pointer IDs is not > correct at the specified array index? > > Not looking forward to coming up with a solution for my platform / > middleware / custom event system and certainly am not excited if I > need to buy an Experia Play just for this, but w/ talking with Robert > G. it sounds like button support on this device is a bit wacky too. If > I understand correctly button presses don't generate key events? Hrm; > I hope that is not the case as I hate to have to waste $500+ to fix > these kinds of issues. Likely I'll pick one up, fix the issues, then > sell it. > > Regards, > --Mike > > On May 16, 12:58 pm, Mario Zechner wrote: > > > > > > > > > A user reported an ArrayIndexOutOfBoundsException today in ourmulti-> > > touchhandler. We store x/y/touchState on a per pointer id basis in an > > array. Dirty? Yes, but it worked on all devices so far. Usually > > pointer ids are handed out like 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] Re: Multi-touch pointer ids on Sony Xperia Play & spurious ACTION_DOWN events
Pointer ids should be considered to be arbitrary non-negative integers. The framework currently makes some assumptions about the range of these ids, but applications must not, lest they be broken sometime in the future. Imagine a device that supports 60 simultaneous finger touches. It could happen. :) Moreover, the order in which pointer ids are assigned is completely arbitrary. It happens to be the case that on most devices, the first pointer id assigned is 0. However the first pointer id could be anything. This is especially the case when the Honeycomb touch splitting feature is enabled (as it is by default for new applications). Suppose the user puts two fingers down within two different scrollable list views. The first finger might have id 0 and be delivered to a scrollable list view on the left. The second finger might have id 1 and be delivered to a scrollable list view on the right. From the perspective of the right hand list view, the first pointer id it received was 1, not 0. So I'm sad to say that many applications are making incorrect assumptions about pointer id values. One common bug is to conflate the meaning of the pointer id and pointer index values... crash! I strongly recommend that you track pointers using a sparse data structure like a map or android.util.SparseArray. Now let's talk about MotionEvent.ACTION_DOWN. The framework guarantees that motion events will always be delivered to a window in a consistent sequence: down/move/up, down/cancel, down/pointerdown/move/pointerup/up. However, the framework cannot work around buggy views that drop or corrupt part of the motion event stream before passing motion events down to their children. I've seen some custom views that do bad things like eat all multitouch events, or intercept some part of the gesture without canceling the rest. OnTouchListener implementations can also be problematic if they consume part but not all of a gesture. Views downstream may receive weird sequences of events as a result. As a defensive coding practice, views should be implemented to always reset themselves to a known ground state before handling ACTION_DOWN. In this way, they can recover in case some of their ancestor views fail to pass along the ACTION_UP or ACTION_CANCEL as would be expected. Likewise, bad things can happen during a gesture such as a pointer id mysteriously vanishing from the event without a an ACTION_POINTER_UP ever have been seen (because it was consumed somewhere else). Views should always check the result of MotionEvent.findPointerIndex and handle the case where a pointer went missing. Otherwise, the application may crash when it tries to access a pointer with index -1. Clearly if any of these things happen, there's a bug somewhere (probably in the app). It might not be very obvious though. With a little case, the app should be able to recover gracefully. Hope that helps, Jeff. On May 16, 12:58 pm, Mario Zechner wrote: > A user reported an ArrayIndexOutOfBoundsException today in > ourmulti-touchhandler. We store x/y/touchState on a per pointer id basis in an > array. Dirty? Yes, but it worked on all devices so far. Usually > pointer ids are handed out like this: > > first finger goes down -> pointer Id 0 > second finger goes down -> pointer id 1 > second finger lifted > second finger goes down -> pointer id 1 > second finger lifted > second finger goes down -> pointer id 1 > > This works on all phones and some discussions in this group also point > out this exact behaviour. Sadly, MotionEvent is underdocumented so it > seems this was an assumption after all, not a rule all manufacturers > would follow. On the Sony Xperia Play the following behaviour is > observed. > > first finger goes down -> pointer Id 0 > second finger goes down -> pointer id 1 > second finger lifted > second finger goes down -> pointer id 2 > second finger lifted > second finger goes down -> pointer id 3 > > Is this a bug in the Xperia touch driver or is this actually wanted > behaviour? Did we all (and there are a couple of people i know of > having this issue) created faulty apps based on a wrong assumption? > > On a related note: The MotionEvent documentation has a new addition > which reads like this: > > "The view implementation should be prepared to handle ACTION_CANCEL > and should tolerate anomalous situations such as receiving a new > ACTION_DOWN without first having received an ACTION_UP for the prior > gesture." > > The handling of ACTION_CANCEL is a no-brainer of course. What is > making me a bit nervous is the fact that spurious ACTION_DOWN events > can now happen. It is not clear whether this will only happen if a > parent View consumed the accompanying ACTION_UP event or if this is > behaviour to be expected even in single View applications. > > Any pointers would be appreciated, no pun intended. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this gro
Re: [android-developers] Re: Multi-touch pointer ids on Sony Xperia Play & spurious ACTION_DOWN events
Pointer IDs are arbitrary integers. The only guarantee is that they will be unique for a given finger as long as that finger remains down. Once the finger goes up, the id may be reused for a different finger, or it may not. It really depends. The problem with spurious ACTION_DOWN events is strictly a software issue, not hardware. It happens when applications filter or modify the stream of touch events in a manner that causes them to become incomplete or inconsistent. The bugs can be quite subtle. Jeff. On Mon, May 16, 2011 at 3:56 PM, MichaelEGR wrote: > ugh! Thanks for posting this message as this is a gnarly one and an > example of ODM fragmentation if pointed IDs are not indexing correctly > to the proper point data at least. I never was impressed by the > multitouch API and always thought it wasn't thought out well and > simply just tacked onto MotionEvent. Dirty as you say it is correct. I > also wasn't pleased with the lack of documentation and unclear > contract. Perhaps this lack of documentation led to this potential ODM > fault. As for spurious ACTION_DOWN events this could be from varied > quality of touchscreen hardware too. > > So from my reading of your post you are saying that pointer IDs are > not recycled and that the data of subsequent pointer IDs is not > correct at the specified array index? > > Not looking forward to coming up with a solution for my platform / > middleware / custom event system and certainly am not excited if I > need to buy an Experia Play just for this, but w/ talking with Robert > G. it sounds like button support on this device is a bit wacky too. If > I understand correctly button presses don't generate key events? Hrm; > I hope that is not the case as I hate to have to waste $500+ to fix > these kinds of issues. Likely I'll pick one up, fix the issues, then > sell it. > > Regards, > --Mike > > On May 16, 12:58 pm, Mario Zechner wrote: >> A user reported an ArrayIndexOutOfBoundsException today in our multi- >> touch handler. We store x/y/touchState on a per pointer id basis in an >> array. Dirty? Yes, but it worked on all devices so far. Usually >> pointer ids are handed out like 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 > -- 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] What is "Failed to finish input event. Check logs for details." Runtime crash?
What else appears in the log? Usually this message is preceded (or shortly followed) by a log entry to the effect that the input event has already been finished or the input channel was closed, or something. Jeff. On Mon, Feb 28, 2011 at 9:06 AM, Pink wrote: > Hi, > > I am working on ginger bread. > > I am porting an application which was running properly on Foryo to > GingerBread. > > While close one of my application activities i am getting RunTime > exception. > > Can any body help me? > > > The logcat as follows. > > java.lang.RuntimeException: Failed to finish input event. Check > logs for details. > 03-01 01:15:51.583 E/AndroidRuntime( 422): at > android.view.InputQueue.nativeFinished(Native Method) > 03-01 01:15:51.583 E/AndroidRuntime( 422): at > android.view.InputQueue.access$100(InputQueue.java:26) > 03-01 01:15:51.583 E/AndroidRuntime( 422): at android.view.InputQueue > $FinishedCallback.run(InputQueue.java:165) > 03-01 01:15:51.583 E/AndroidRuntime( 422): at > android.view.ViewRoot.finishInputEvent(ViewRoot.java:2064) > 03-01 01:15:51.583 E/AndroidRuntime( 422): at > android.view.ViewRoot.handleMessage(ViewRoot.java:1890) > 03-01 01:15:51.583 E/AndroidRuntime( 422): at > android.os.Handler.dispatchMessage(Handler.java:99) > 03-01 01:15:51.583 E/AndroidRuntime( 422): at > android.os.Looper.loop(Looper.java:123) > 03-01 01:15:51.583 E/AndroidRuntime( 422): at > android.app.ActivityThread.main(ActivityThread.java:3661) > 03-01 01:15:51.583 E/AndroidRuntime( 422): at > java.lang.reflect.Method.invokeNative(Native Method) > 03-01 01:15:51.583 E/AndroidRuntime( 422): at > java.lang.reflect.Method.invoke(Method.java:507) > 03-01 01:15:51.583 E/AndroidRuntime( 422): at > com.android.internal.os.ZygoteInit > $MethodAndArgsCaller.run(ZygoteInit.java:842) > 03-01 01:15:51.583 E/AndroidRuntime( 422): at > com.android.internal.os.ZygoteInit.main(ZygoteInit.java:600) > 03-01 01:15:51.583 E/AndroidRuntime( 422): at > dalvik.system.NativeStart.main(Native Method) > > > Thanks in advance. > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- 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] Manually Dispatch Key Event
You need to set the MetaState flags of the KeyEvent for the comma to META_SHIFT_ON. However, I strongly discourage injecting key events if at all possible since it tends to be brittle. For example, you are probably assuming that shift-, produces < but there is no guarantee that the keymap will be defined that way. Jeff. On Feb 17, 2011 12:31 PM, "Ankur Avlani" wrote: > > Hi All, > > I am trying to Manually dispatch Shift and Comma key from Android to my webview, my code is as follows: > > KeyEvent event1 = new KeyEvent(KeyEvent.ACTION_DOWN,KeyEvent.KEYCODE_SHIFT_LEFT); > boolean isFlag = dispatchKeyEvent(event1); > KeyEvent event2 = new KeyEvent(KeyEvent.ACTION_DOWN,KeyEvent.KEYCODE_COMMA); > dispatchKeyEvent(event2); > KeyEvent event3 = new KeyEvent(KeyEvent.ACTION_UP,KeyEvent.KEYCODE_SHIFT_LEFT); > dispatchKeyEvent(event3); > But the issue is, its sending the key one by one, i want it to send "Shift," key event to webview. Any ideas what needs to be corrected?. I tried googling, but couldnt find any relevant solution. > > Any inputs are appreciated. > > Thanks, > Anlkur > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
