Re: [android-developers] Re: Handling asynchronous events and blocking

[Studio LFP]

Nice, I'll have to play with that too.  I never ran into any exceptions 
because I use touches very little in the game I am playing around with.

Steven
Studio LFP
http://www.studio-lfp.com


On Monday, October 24, 2011 7:16:47 AM UTC-5, TreKing wrote:
>
> On Mon, Oct 24, 2011 at 1:20 AM, Peter Webb  wrote:
>
>> This must be a very common problem, and I would expect a simple standard 
>> solution. As I mentioned, on other platforms I have used a guaranteed atomic 
>> process (file creation)as a semaphore for synchronisation, but I doubt that 
>> is the recommended solution for Android ...
>>
>
>
> http://developer.android.com/reference/java/util/concurrent/package-summary.html
>
>
> -
> TreKing  - Chicago 
> transit tracking app for Android-powered devices
>
>

-- 
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: Handling asynchronous events and blocking

[Peter Webb]

ConcurrentLinkedQueue. Exactly what I want. Thankyou.

On Oct 24, 11:16 pm, TreKing  wrote:
> On Mon, Oct 24, 2011 at 1:20 AM, Peter Webb  wrote:
> > This must be a very common problem, and I would expect a simple standard
> > solution. As I mentioned, on other platforms I have used a guaranteed atomic
> > process (file creation)as a semaphore for synchronisation, but I doubt that
> > is the recommended solution for Android ...
>
> http://developer.android.com/reference/java/util/concurrent/package-s...
>
> ---­--
> TreKing  - Chicago
> transit tracking app for Android-powered devices

-- 
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: Handling asynchronous events and blocking

[TreKing]

On Mon, Oct 24, 2011 at 1:20 AM, Peter Webb  wrote:

> This must be a very common problem, and I would expect a simple standard
> solution. As I mentioned, on other platforms I have used a guaranteed atomic
> process (file creation)as a semaphore for synchronisation, but I doubt that
> is the recommended solution for Android ...
>

http://developer.android.com/reference/java/util/concurrent/package-summary.html

-
TreKing  - Chicago
transit tracking app for Android-powered devices

-- 
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: Handling asynchronous events and blocking

[Peter Webb]

I can certainly create (say) a LinkedList of events which acts a queue
of instructions for my main loop.

My issue is that after processing an event, I have to remove it from
the queue.

According to 
http://download.oracle.com/javase/1.4.2/docs/api/java/util/LinkedList.html
: "Note that this implementation is not synchronized. If multiple
threads access a list concurrently, and at least one of the threads
modifies the list structurally, it must be synchronized externally. (A
structural modification is any operation that adds or deletes one or
more elements; merely setting the value of an element is not a
structural modification.)".

This page then goes on to describe how to force an exception if two
threads both try and update a LinkedList simultaneously. This doesn't
solve the problem, it just tells you that it has happened.

This must be a very common problem, and I would expect a simple
standard solution. As I mentioned, on other platforms I have used a
guaranteed atomic process (file creation)as a semaphore for
synchronisation, but I doubt that is the recommended solution for
Android ...



On Oct 24, 4:28 pm, Studio LFP  wrote:
> I figure you are running a thread that does all the processing as not to
> block the UI thread. If so, one of the ways I've been doing it is to add
> something like...
>
> public static LinkedList uiEvents;
>
> ... to a helper object and then check the length of it every time through
> the processing loop. You can either call length() on this or you can keep up
> with the count yourself which might be a bit faster.
>
> In whatever view you are catching touches, just insert the MotionEvent into
> this list. This should leave the UI thread clear and let the processing
> thread get the touches as time allows.
>
> Once I process the first event, I remove the event from the list and
> continue. I tend to only process one per frame so I don't cause hitching in
> the movement. If you are running about 30 fps, most people won't be able to
> touch faster than the ~33ms they have between frames anyways.
>
> I use a LinkedList so it keeps the touches in the order I insert them so I
> don't have to worry about out of order touches.
>
> Just one idea, someone else may have a more effective one, but hope that
> helps.
>
> Steven
> Studio LFPhttp://www.studio-lfp.com
>
>
>
> On Sunday, October 23, 2011 11:42:50 PM UTC-5, Peter Webb wrote:
>
> > I don't even know if this is an Android question or a Java question.
>
> > I am developing a simple game using Lunarlander as a starting point.
>
> > Input is through OnTouch events. This changes the game's state - eg a
> > touch event may cause some gameplay object to be instantiated.
> > Obviously I don't want this to occur in the middle of processing.
>
> > How do I best synchronise the OnTouch events with the main game loop?
> > In other environments I have used an "atomic" event (such as creating
> > a dummy file) as a semaphore to work out when game objects can be
> > safely read and written. What should I do in Android?- Hide quoted text -
>
> - Show quoted text -

-- 
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: Handling asynchronous events and blocking

[Studio LFP]

I figure you are running a thread that does all the processing as not to 
block the UI thread. If so, one of the ways I've been doing it is to add 
something like...

public static LinkedList uiEvents;

... to a helper object and then check the length of it every time through 
the processing loop. You can either call length() on this or you can keep up 
with the count yourself which might be a bit faster.

In whatever view you are catching touches, just insert the MotionEvent into 
this list. This should leave the UI thread clear and let the processing 
thread get the touches as time allows.

Once I process the first event, I remove the event from the list and 
continue. I tend to only process one per frame so I don't cause hitching in 
the movement. If you are running about 30 fps, most people won't be able to 
touch faster than the ~33ms they have between frames anyways.

I use a LinkedList so it keeps the touches in the order I insert them so I 
don't have to worry about out of order touches.

Just one idea, someone else may have a more effective one, but hope that 
helps.

Steven
Studio LFP
http://www.studio-lfp.com


On Sunday, October 23, 2011 11:42:50 PM UTC-5, Peter Webb wrote:
>
> I don't even know if this is an Android question or a Java question. 
>
> I am developing a simple game using Lunarlander as a starting point. 
>
> Input is through OnTouch events. This changes the game's state - eg a 
> touch event may cause some gameplay object to be instantiated. 
> Obviously I don't want this to occur in the middle of processing. 
>
> How do I best synchronise the OnTouch events with the main game loop? 
> In other environments I have used an "atomic" event (such as creating 
> a dummy file) as a semaphore to work out when game objects can be 
> safely read and written. What should I do in 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