[android-developers] Re: DatePicker in a fragment
The solution I came up with was to subclass DialogFragment, returning
a DatePickerDialog in onCreate()
@Override
public Dialog onCreateDialog(Bundle savedInstanceState) {
return new DatePickerDialog(sContext, dateSetListener,
sDate.get(Calendar.YEAR), sDate.get(Calendar.MONTH),
sDate.get(Calendar.DAY_OF_MONTH));
}
I implement DatePickerDialog.OnDateSetListener.onDateSet() in my
DateDialogFragment.
private DatePickerDialog.OnDateSetListener dateSetListener =
new DatePickerDialog.OnDateSetListener() {
@Override
public void onDateSet(DatePicker view, int year, int monthOfYear,
int dayOfMonth) {
Calendar newDate = Calendar.getInstance();
newDate.set(year, monthOfYear, dayOfMonth);
//call back to the DateDialogFragment listener
sListener.dateDialogFragmentDateSet(newDate);
}
};
I also define a listener interface in my DateDialogFragment for the
calling Activity/Fragment to implement.
public interface DateDialogFragmentListener{
public void dateDialogFragmentDateSet(Calendar date);
}
As you can see above, I fire my DateDialogFragmentListener from the
DatePickerDialog's listener.
I wrote about it in more detail with entire source here:
http://www.kylebeal.com/2011/11/android-datepickerdialog-and-the-dialogfragment/
On Nov 11, 1:55 pm, Kyle wrote:
> I am attempting to use a datepicker dialog based on the example
> athttp://developer.android.com/resources/tutorials/views/hello-datepick
> This is obviously for an activity, but I'm trying to implement the
> same functionality in a fragment. Using the code from the example
> won't work. By this, I mean the following code snippet does not
> actually open the dialog:
>
> ...
> mPickDate = (Button) mRootView.findViewById(R.id.button_leave_date);
>
> // add a click listener to the button
> mPickDate.setOnClickListener(new View.OnClickListener() {
> public void onClick(View v) {
> mActivity.showDialog(DATE_DIALOG_ID);
> }});
>
> ...
>
> After reading various sources online, I know "showDialog" is
> deprecated and the recommendation is to use the DialogFragment.
> However, is there an option to generate a date picker dialog with this
> implementation? I've been unable to find any good examples of anyone
> trying this - so if there are resources available to merge the
> (deprecated) example on the Android Developer web site with an actual
> DialogFragment implementation, I would really appreciate it.
--
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: Troubles with SurfaceView's surfaceCreated/Destroyed
Thank you, I will try to implement this when I have time. I now
understand where my confusion was stemming from. I was under the
impression that each time the CupView Activity was resumed, a new
CupView object was created thus creating a new CupThread. However I
now see that is not the case, the CupView object is not destroyed and
recreated, thus no new thread to call start() on.
On Apr 1, 11:34 am, Streets Of Boston wrote:
> Do *not* use volatile variables. They are not guaranteed to be atomic.
> It's just a compiler hint.
>
> Instead, use synchronized blocks:
>
> class MyThread extends Thread {
> boolean mPaused;
> boolean mStopped;
>
> public void run() {
> ...
> ...
> mStopped = false;
> mPaused = true or false, depends on your application.
> while (!mStopped) {
> if (waitForResume())
> break;
>
> // do your thing.
> ...
> }
> }
>
> public void stopThread() {
> syncrhonized(this) {
> mPaused = false;
> mStopped = true;
> this.notify();
> }
> // optionally, code an extra 'join()' statement if the caller
> needs
> // to wait until the thread has completely finished.
> }
>
> public void pauseThread() {
> syncrhonized(this) {
> mPaused = true;
> this.notify();
> }
> }
>
> public void resumeThread() {
> syncrhonized(this) {
> mPaused = false;
> this.notify();
> }
> }
>
> private boolean waitForResume() {
> synchronized(this) {
> if (mStopped)
> return false;
>
> while (mPaused) {
> this.wait();
> }
>
> if (mStopped)
> return false;
> }
> }
> ...
> ...
>
> }
>
> Then code that needs to control your thread, just call
> myThread.pauseThread() or myThread.resumeThread() and stops the thread
> entirely by calling myThread.stopThread();
>
> Note: you could replace 'this' with another object to use for
> synchronization.
>
> On Apr 1, 10:06 am, Tom wrote:
>
> > Try this:
>
> > Create a set of volatile variables (toPause, isPaused, toStop,
> > isStopped).
>
> > Outside the thread, in the methods mentioned previously, set or clear
> > the appropriate variables.
> > Inside the thread, be checking the appropriate variables to determine
> > if the thread needs to be paused or stopped.
>
> > Put the use of the variable within synchronized blocks.
> > Use wait and notify to avoid busy polling.
--~--~-~--~~~---~--~~
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: Troubles with SurfaceView's surfaceCreated/Destroyed
Thank you for your suggestions, however according to the API, there is
no way to pause or resume threads. Only start them, then join them
(which eventually kills it). All related methods for pausing and
resuming have been deprecated it seems.
On Mar 31, 11:07 pm, Streets Of Boston
wrote:
> I haven't read through all your code, but you should not call
> thread.start() in your surfaceCreated method.
> Instead, create and start your thread asap and have it paused when
> necessary.
>
> When 'onPause()' or when surfaceDestroyed is called, pause your thread
> (CupThread).
> When 'onResume()' or surfaceCreated is called, resume your thread.
> Only stop and terminate your thread when 'onDestroy()' is called.
>
> Take a look at the OpenGL Cube example from the API demos.
> I think the class is called RenderThread.
> It creates and starts the thread when the activity is created, stops
> it when the activity is destroyed.
> It pauses the thread on surfaceDestroyed, it resumes it on
> surfaceCreated. This also makes sure that your CupThread does not eat
> CPU-cycles when your app moves to the background. If you don't pause
> the thread when your app is in the background, your phone will eat a
> lot of CPU cycles basically doing nothing --> battery drain -->
> unhappy customers.
>
> Pausing and resuming threads should be done using synchronized blocks,
> wait() statements and notify() statements.
>
> On Mar 31, 10:35 pm, kbeal10 wrote:
>
> > This is where the thread variable is declared.
>
> > private Context mContext;
> > /** The thread that actually draws teh animations. */
> > private CupThread thread;
> > private TextView mStatusText;
>
> > public CupView(Context context, AttributeSet attrs){
> > super(context,attrs);
>
> > //register our interest in hearing about changes to our
> > surface
> > SurfaceHolder holder = getHolder();
> > holder.addCallback(this);
> > mContext = context;
> > setFocusable(true);
> > // create thread only; it's started in surfaceCreated()
> > }
>
> > I'm sorry for the confusion about "exiting" in rollDice(). Indeed, I
> > am not exiting here, but starting another Activity.
>
> > I believe, as you mentioned, this is a case where the original
> > activity is still there, and then being re-displayed. However,
> > CupView's surfaceDestroyed() is called when I start the other Activity
> > in rollDice(). This means that when the Activity holding CupView
> > resumes I should be able to create a new thread and start it. I am
> > aware you can't call start() on the same thread twice, but since
> > surfaceDestroyed() is called that thread is terminated with the .join
> > () call. A new thread is then created and started in surfaceCreated().
>
> > I will post the full code to both the Activity holding the CupView, as
> > well as the CupView in the following post.
>
> > On Mar 31, 10:17 pm, Dianne Hackborn wrote:
>
> > > I don't think you've included enough code. Where is this 'thread'
> > > variable
> > > defined? Where do you clear it after finishing the thread?
>
> > > I am also confused by the comment saying you "exiting" the activity in
> > > rollDice -- you aren't calling finish, you are just starting another
> > > activity, so the original activity is still there, and its window will
> > > just
> > > be re-displayed when it is shown again.
>
> > > The only thing I can think of is that you aren't handling the case where
> > > your window is hidden and then shown again, causing surfaceCreated to be
> > > called a second time on the same SurfaceView, but again there isn't enough
> > > code here to really tell what is happening.
>
> > > Also you do know that you can only call Thread.start() once on a
> > > particular
> > > thread object, right?
>
> > >http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#start()
>
> > > On Tue, Mar 31, 2009 at 6:46 PM, kbeal10 wrote:
>
> > > > I'm writing a game using two different SurfaceView's (RollView and
> > > > CupView) in two different activities. Both SurfaceView's heavily
> > > > resemble the LunarLander demo.
>
> > > > The RollView SurfaceView is working fine. When leaving the Activity,
> > > > RollView's surfaceDestroyed() is called, kil
[android-developers] Re: Troubles with SurfaceView's surfaceCreated/Destroyed
insicWidth()/2,
mCupImage.getIntrinsicHeight()/2);
mRotation=1;
}else{
canvas.rotate(-3,
mCupImage.getIntrinsicWidth()/2,
mCupImage.getIntrinsicHeight()/2);
mRotation=0;
}
}
mCupImage.setBounds(getLeft(), getTop(), getRight(),
getBottom());
mCupImage.draw(canvas);
canvas.restore();
}
//-
public void pause() {
synchronized (mSurfaceHolder) {
setState(STATE_PAUSED);
}
}
//-
public void unpause() {
setState(STATE_RUNNING);
}
//-
public void setState(int mode){
synchronized (mSurfaceHolder){
mMode = mode;
}
}
}
//-
/** Handle ot the application context, used to e.g. fetch Drawables.
*/
private Context mContext;
/** The thread that actually draws teh animations. */
private CupThread thread;
private TextView mStatusText;
public CupView(Context context, AttributeSet attrs){
super(context,attrs);
//register our interest in hearing about changes to our surface
SurfaceHolder holder = getHolder();
holder.addCallback(this);
mContext = context;
setFocusable(true);
// create thread only; it's started in surfaceCreated()
}
//-
public CupThread getThread(){
return thread;
}
//-
/**
* Installs a pointer to the text view used for messages.
*/
public void setTextView(TextView textView) {
mStatusText = textView;
}
//-
/* Callback invoked when the Surface dimensions change. */
public void surfaceChanged(SurfaceHolder holder, int format, int
width, int height){
thread.setSurfaceSize(width,height);
}
//-
/* Callback invoked when the Surface has been created and is read to
be used. */
public void surfaceCreated(SurfaceHolder holder){
// start the thread here so that we don't busy-wait in run()
// waiting for the surface to be created
Log.d("MyApp","cup view surface created");
thread = new CupThread(holder, mContext, new Handler() {
@Override
public void handleMessage(Message m) {
mStatusText.setVisibility(m.getData().getInt("viz"));
mStatusText.setText(m.getData().getString("text"));
}
});
thread.setRunning(true);
thread.start();
}
//-
/* Callback invoked when the Surface has been destroyed and must no
longer be touched.
* WARNING: after this method returns, the Surface/Canvas must never
be touched again!
* (Unless its REALLY asking for it.)
*/
public void surfaceDestroyed(SurfaceHolder holder){
// we have to tell thread to shut down & wait for it to finish,
or
else it might touch
// the Surface(wouldn't want that!) after we return and explode
(ahhh!).
Log.d("MyApp","cup view surface destroyed");
boolean retry = true;
thread.setRunning(false);
while (retry){
try{
thread.join();
retry = false;
}catch(InterruptedException e){
}
}
}
}
On Mar 31, 10:41 pm, kbeal10 wrote:
> This is the main Activity of my app. The one holding a CupView.
>
> package my.package;
>
> import my.package.CupView.CupThread;
> import org.openintents.hardware.SensorManagerSimulator;
> im
[android-developers] Re: Troubles with SurfaceView's surfaceCreated/Destroyed
mShaking = true;
mCupThread.setState(mCupThread.STATE_SHAKING);
}
if (mShake==0&&mShaking){
mShaking = false;
mCupThread.setState(mCupThread.STATE_RUNNING);
}
mLastX = x;
}
}
public void onAccuracyChanged(int sensor, int acc){}
};
// now connect to simulator
SensorManagerSimulator.connectSimulator();
// now enable the new sensors
mSensorManager.registerListener(mAccellListener,
SensorManager.SENSOR_ACCELEROMETER);
}
}
On Mar 31, 10:35 pm, kbeal10 wrote:
> This is where the thread variable is declared.
>
> private Context mContext;
> /** The thread that actually draws teh animations. */
> private CupThread thread;
> private TextView mStatusText;
>
> public CupView(Context context, AttributeSet attrs){
> super(context,attrs);
>
> //register our interest in hearing about changes to our
> surface
> SurfaceHolder holder = getHolder();
> holder.addCallback(this);
> mContext = context;
> setFocusable(true);
> // create thread only; it's started in surfaceCreated()
> }
>
> I'm sorry for the confusion about "exiting" in rollDice(). Indeed, I
> am not exiting here, but starting another Activity.
>
> I believe, as you mentioned, this is a case where the original
> activity is still there, and then being re-displayed. However,
> CupView's surfaceDestroyed() is called when I start the other Activity
> in rollDice(). This means that when the Activity holding CupView
> resumes I should be able to create a new thread and start it. I am
> aware you can't call start() on the same thread twice, but since
> surfaceDestroyed() is called that thread is terminated with the .join
> () call. A new thread is then created and started in surfaceCreated().
>
> I will post the full code to both the Activity holding the CupView, as
> well as the CupView in the following post.
>
> On Mar 31, 10:17 pm, Dianne Hackborn wrote:
>
> > I don't think you've included enough code. Where is this 'thread' variable
> > defined? Where do you clear it after finishing the thread?
>
> > I am also confused by the comment saying you "exiting" the activity in
> > rollDice -- you aren't calling finish, you are just starting another
> > activity, so the original activity is still there, and its window will just
> > be re-displayed when it is shown again.
>
> > The only thing I can think of is that you aren't handling the case where
> > your window is hidden and then shown again, causing surfaceCreated to be
> > called a second time on the same SurfaceView, but again there isn't enough
> > code here to really tell what is happening.
>
> > Also you do know that you can only call Thread.start() once on a particular
> > thread object, right?
>
> >http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#start()
>
> > On Tue, Mar 31, 2009 at 6:46 PM, kbeal10 wrote:
>
> > > I'm writing a game using two different SurfaceView's (RollView and
> > > CupView) in two different activities. Both SurfaceView's heavily
> > > resemble the LunarLander demo.
>
> > > The RollView SurfaceView is working fine. When leaving the Activity,
> > > RollView's surfaceDestroyed() is called, killing the thread. If I then
> > > re-enter that Activity, the thread is recreated in RollView's
> > > constructor and then started in surfaceCreated().
>
> > > However in CupView the thread never seems to go away. SurfaceDestroyed
> > > is being called, but upon reentering the Activity I get the following
> > > error:
>
> > > java.lang.IllegalThreadStateException: Thread already started.
>
> > > This thrown is in surfaceCreated() at the thread.start() call.
>
> > > The difference between the two, and apparently the problem, is that in
> > > the RollView Activity I call finish() when done. When leaving the
> > > CupView Activity, I'm doing a startActivityForResult
> > > (i,ClassWithRollView.class);..not calling finish().
>
> > > This is because after leaving the RollView, I want to return to the
> > > CupView. Below
[android-developers] Re: Troubles with SurfaceView's surfaceCreated/Destroyed
This is where the thread variable is declared.
private Context mContext;
/** The thread that actually draws teh animations. */
private CupThread thread;
private TextView mStatusText;
public CupView(Context context, AttributeSet attrs){
super(context,attrs);
//register our interest in hearing about changes to our surface
SurfaceHolder holder = getHolder();
holder.addCallback(this);
mContext = context;
setFocusable(true);
// create thread only; it's started in surfaceCreated()
}
I'm sorry for the confusion about "exiting" in rollDice(). Indeed, I
am not exiting here, but starting another Activity.
I believe, as you mentioned, this is a case where the original
activity is still there, and then being re-displayed. However,
CupView's surfaceDestroyed() is called when I start the other Activity
in rollDice(). This means that when the Activity holding CupView
resumes I should be able to create a new thread and start it. I am
aware you can't call start() on the same thread twice, but since
surfaceDestroyed() is called that thread is terminated with the .join
() call. A new thread is then created and started in surfaceCreated().
I will post the full code to both the Activity holding the CupView, as
well as the CupView in the following post.
On Mar 31, 10:17 pm, Dianne Hackborn wrote:
> I don't think you've included enough code. Where is this 'thread' variable
> defined? Where do you clear it after finishing the thread?
>
> I am also confused by the comment saying you "exiting" the activity in
> rollDice -- you aren't calling finish, you are just starting another
> activity, so the original activity is still there, and its window will just
> be re-displayed when it is shown again.
>
> The only thing I can think of is that you aren't handling the case where
> your window is hidden and then shown again, causing surfaceCreated to be
> called a second time on the same SurfaceView, but again there isn't enough
> code here to really tell what is happening.
>
> Also you do know that you can only call Thread.start() once on a particular
> thread object, right?
>
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#start()
>
>
>
> On Tue, Mar 31, 2009 at 6:46 PM, kbeal10 wrote:
>
> > I'm writing a game using two different SurfaceView's (RollView and
> > CupView) in two different activities. Both SurfaceView's heavily
> > resemble the LunarLander demo.
>
> > The RollView SurfaceView is working fine. When leaving the Activity,
> > RollView's surfaceDestroyed() is called, killing the thread. If I then
> > re-enter that Activity, the thread is recreated in RollView's
> > constructor and then started in surfaceCreated().
>
> > However in CupView the thread never seems to go away. SurfaceDestroyed
> > is being called, but upon reentering the Activity I get the following
> > error:
>
> > java.lang.IllegalThreadStateException: Thread already started.
>
> > This thrown is in surfaceCreated() at the thread.start() call.
>
> > The difference between the two, and apparently the problem, is that in
> > the RollView Activity I call finish() when done. When leaving the
> > CupView Activity, I'm doing a startActivityForResult
> > (i,ClassWithRollView.class);..not calling finish().
>
> > This is because after leaving the RollView, I want to return to the
> > CupView. Below is relevant code:
>
> > /** This where I'm exiting the Activity with the CupView **/
> > private void rollDice(){
> > if (mMode==IN_PROGRESS){
> > // create a new intent for the roll dice view
> > Intent i = new Intent(this,RollDice.class);
> > mRollCount = mRollCount + 1;
> > if (mRollCount == 3){
> > mTurnCount += 1;
> > }
> > if (mTurnCount == 13){
> > setState(GAME_OVER);
> > }
> > i.putExtra("my.package.RollCount", mRollCount);
> > i.putExtra("my.package.GameID",mGameID);
> > startActivityForResult(i,ROLL_DICE_ACTIVITY);
> > }
> > }
>
> > /** This is CupView's surfaceCreated/Destroyed **/
>
> > //-
> >
[android-developers] Troubles with SurfaceView's surfaceCreated/Destroyed
I'm writing a game using two different SurfaceView's (RollView and
CupView) in two different activities. Both SurfaceView's heavily
resemble the LunarLander demo.
The RollView SurfaceView is working fine. When leaving the Activity,
RollView's surfaceDestroyed() is called, killing the thread. If I then
re-enter that Activity, the thread is recreated in RollView's
constructor and then started in surfaceCreated().
However in CupView the thread never seems to go away. SurfaceDestroyed
is being called, but upon reentering the Activity I get the following
error:
java.lang.IllegalThreadStateException: Thread already started.
This thrown is in surfaceCreated() at the thread.start() call.
The difference between the two, and apparently the problem, is that in
the RollView Activity I call finish() when done. When leaving the
CupView Activity, I'm doing a startActivityForResult
(i,ClassWithRollView.class);..not calling finish().
This is because after leaving the RollView, I want to return to the
CupView. Below is relevant code:
/** This where I'm exiting the Activity with the CupView **/
private void rollDice(){
if (mMode==IN_PROGRESS){
// create a new intent for the roll dice view
Intent i = new Intent(this,RollDice.class);
mRollCount = mRollCount + 1;
if (mRollCount == 3){
mTurnCount += 1;
}
if (mTurnCount == 13){
setState(GAME_OVER);
}
i.putExtra("my.package.RollCount", mRollCount);
i.putExtra("my.package.GameID",mGameID);
startActivityForResult(i,ROLL_DICE_ACTIVITY);
}
}
/** This is CupView's surfaceCreated/Destroyed **/
//-
/* Callback invoked when the Surface has been created and is read to
be used. */
public void surfaceCreated(SurfaceHolder holder){
// start the thread here so that we don't busy-wait in run()
// waiting for the surface to be created
Log.d("MyApp","cup view surface created");
thread.setRunning(true);
thread.start();
}
//-
/* Callback invoked when the Surface has been destroyed and must no
longer be touched.
* WARNING: after this method returns, the Surface/Canvas must never
be touched again!
* (Unless its REALLY asking for it.)
*/
public void surfaceDestroyed(SurfaceHolder holder){
// we have to tell thread to shut down & wait for it to finish,
or
else it might touch
// the Surface(wouldn't want that!) after we return and explode
(ahhh!).
Log.d("MyApp","cup view surface destroyed");
boolean retry = true;
thread.setRunning(false);
while (retry){
try{
thread.join();
retry = false;
}catch(InterruptedException e){
}
}
}
So why is the thread saying its already started when surfaceDestroyed
() has been called?
A possible workaround is to call finish() on the CupView Activity in
the rollDice() method above. This doesn't seem to follow common
paradigm though. Any other solutions, comments? All help is
appreciated.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: Performance of multiple threads.
Thanks Boston, but I'm doing the app in 2D. I would've liked to have done 3D (and probably my prof.) but the added complexity didn't mesh with the time constraints of a college student. On Mar 9, 12:17 pm, Streets Of Boston wrote: > I did the same with my app, The Gube, an OpenGL app. > > It took me a while to figure out how to translate swipes of finger > into the rotation of the entire rubik's cube or to have a swipe > initiate the rotation of just one layer. > > If your app is OpenGL (3D) as well, let me know if you need some help > on this (translating onTouch events into motions/gestures in 3D > space). > > On Mar 9, 10:51 am, kbeal10 wrote: > > > I agree, having more than 2 threads seems to break from the > > traditional paradigm, which is part of the reason it didn't seem like > > a good answer. > > > Since I wouldn't be able to have a ViewGroup in it's own thread, I > > suppose the best solution is to create a SurfaceView that handles > > drawing all of the dice. This is the way I had started, but liked the > > idea of each die being a View in order to handle onTouchEvents. > > Instead, the dice would simply be Drawables. Selecting one would mean > > getting the coords of the onTouchEvent, and determining if that is on > > top of a die. > > > On Mar 9, 4:14 am, Stoyan Damov wrote: > > > > U, I don't want to sound insulting in anyway but being a complete > > > newbie in game programming I can *assure* you you're about to do > > > something fundamentally wrong. > > > Your game only needs 2 threads - the UI (main) thread, and a secondary > > > which runs your game loop. > > > If you are a newbie as well, you'll need to read a couple of books, or > > > at least a dozen of articles on game programming before even thinking > > > of creating your own game. > > > > Cheers > > > > On Mon, Mar 9, 2009 at 5:38 AM, kbeal10 wrote: > > > > > I'm currently designing a game that will be displaying several dice. I > > > > would like to know the wisest course of action. The dice will extend > > > > View (or SurfaceView), so that each will be able to be touched, etc. > > > > My question is should I: > > > > > A.) Spawn one child thread to draw all of the dice (up to 6). I would > > > > do this by writing a class that extends ViewGroup or one of the > > > > Layouts and having it create a new thread. Or... > > > > > B.) should I spawn a new thread for each die? Each die would extend > > > > View, or possibly SurfaceView and have its own thread to perform the > > > > onDraw() (i.e. the LunarLander example). > > > > > Which solution would yield better performance/responsiveness? Would up > > > > to 6 child threads be necessary, or a detriment? > > > > > I'm asking because I understand how I would implement the B.) solution > > > > already. It closely follows the LunarLander example and I have already > > > > implemented another section of the game in the same fashion. Other the > > > > other hand, creating up to 6 child threads seems like it may be a bit > > > > much on resources. However, I am unsure how I would implement a > > > > ViewGroup that does its work in a child thread.- 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: Performance of multiple threads.
I agree, having more than 2 threads seems to break from the traditional paradigm, which is part of the reason it didn't seem like a good answer. Since I wouldn't be able to have a ViewGroup in it's own thread, I suppose the best solution is to create a SurfaceView that handles drawing all of the dice. This is the way I had started, but liked the idea of each die being a View in order to handle onTouchEvents. Instead, the dice would simply be Drawables. Selecting one would mean getting the coords of the onTouchEvent, and determining if that is on top of a die. On Mar 9, 4:14 am, Stoyan Damov wrote: > U, I don't want to sound insulting in anyway but being a complete > newbie in game programming I can *assure* you you're about to do > something fundamentally wrong. > Your game only needs 2 threads - the UI (main) thread, and a secondary > which runs your game loop. > If you are a newbie as well, you'll need to read a couple of books, or > at least a dozen of articles on game programming before even thinking > of creating your own game. > > Cheers > > On Mon, Mar 9, 2009 at 5:38 AM, kbeal10 wrote: > > > I'm currently designing a game that will be displaying several dice. I > > would like to know the wisest course of action. The dice will extend > > View (or SurfaceView), so that each will be able to be touched, etc. > > My question is should I: > > > A.) Spawn one child thread to draw all of the dice (up to 6). I would > > do this by writing a class that extends ViewGroup or one of the > > Layouts and having it create a new thread. Or... > > > B.) should I spawn a new thread for each die? Each die would extend > > View, or possibly SurfaceView and have its own thread to perform the > > onDraw() (i.e. the LunarLander example). > > > Which solution would yield better performance/responsiveness? Would up > > to 6 child threads be necessary, or a detriment? > > > I'm asking because I understand how I would implement the B.) solution > > already. It closely follows the LunarLander example and I have already > > implemented another section of the game in the same fashion. Other the > > other hand, creating up to 6 child threads seems like it may be a bit > > much on resources. However, I am unsure how I would implement a > > ViewGroup that does its work in a child 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 -~--~~~~--~~--~--~---
[android-developers] Performance of multiple threads.
I'm currently designing a game that will be displaying several dice. I would like to know the wisest course of action. The dice will extend View (or SurfaceView), so that each will be able to be touched, etc. My question is should I: A.) Spawn one child thread to draw all of the dice (up to 6). I would do this by writing a class that extends ViewGroup or one of the Layouts and having it create a new thread. Or... B.) should I spawn a new thread for each die? Each die would extend View, or possibly SurfaceView and have its own thread to perform the onDraw() (i.e. the LunarLander example). Which solution would yield better performance/responsiveness? Would up to 6 child threads be necessary, or a detriment? I'm asking because I understand how I would implement the B.) solution already. It closely follows the LunarLander example and I have already implemented another section of the game in the same fashion. Other the other hand, creating up to 6 child threads seems like it may be a bit much on resources. However, I am unsure how I would implement a ViewGroup that does its work in a child 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 -~--~~~~--~~--~--~---
