howdy, icecreamman!

hello. i just received my subscription this morning via email from you in fact

I think I commented on one of your SO questions this morning as well, though I forget which one

regardless, how can I help you?

ah, yep. thats why i am here. i didn't see that anyone had responded yet. it is just been very frustrating trying to learn these things without guidance.

i will run through your example in the link and see if it works out better

now i also have all of these great pdf resources to hopefully help my understanding

ah, yes, that question

it's sure not obvious where your code as listed is going wrong

(for the purposes of the transcript, the question is http://stackoverflow.com/questions/3879159…)

are you trying this in the emulator or a device?

this is all emulator

build 2.2 i believe

well, the Maps/NooYawk sample definitely works there

anything unusual about your icon?

nope, its the one straight from the tutorial. the only thing that i thought was weird is i have no explicity 'drawable' folder - there exist drawable-hdpi, drawable-mdpi, etc... but the icon does show up under my generated resources file, and it does appear if i don't pass a context to the itemizedoverlay constructer

its just very weird

make a res/drawable/ directory and put it in there

ha, funny thing is, i already tried that to no avail :(

I don't understand the "it does appear if i don't pass a context to the itemizedoverlay constructer" part

you aren't using that parameter anywhere, at least in the code you have in the SO question

well, except in the Dialog constructor, which won't be triggered until after the icon is displayed

gotcha. so midway through the MapActivity i have the following line:

and i believe 'this' is the context of the application?

'this' is the Activity

in Java, it refers to the current object

akin to self in Ruby

or self in Smalltalk

ahh. duh. so i *believe* that the ItemizedOverlay requires a reference to the entire context (this is like a process id if we are talking about threads, no?).

so by passing it the activity, i am doing something incorrect...?

ItemizedOverlay itself does not

Context is a superclass of Activity

and it has nothing much to do with process IDs

in your HelloItemizedOverlay implementation, you are:

1. accepting the Context as a parameter in the constructor

2. storing that in a data member of your HelloItemizedOverlay

3. using it in the constructor of your AlertDialog.Builder

all of that is fine, but I can't quite see how that would impact whether the icon is visible

I'm going to take a guess that you're new to Java as well as Android?

yes, sadly.

that's OK

however, you may want to spend a bit of time playing with Java outside of Android first

Android is plenty weird on its own :-)

agreed

here is a blog post with a list of the topics of importance in Java for Android developers: http://commonsware.com/blog/2010/08/02/jav…

welcome, dhaupert!

Hi Mark, thanks for having this and for the great helpful book!

icecreamman: regardless, try the Maps/NooYawk sample app, see if it runs for you

ah thank you. well i am going to spend the next while scouring all of resources. the sample app seems to be more extensive, so that should be a good starting point. have a great day

dhaupert: how can I help you today?

I have been struggling with the android:launchMode options, which aren't really covered in the book and the description Google provides sent me in the wrong direction.

yeah, someday I'll add an chapter on manifest tricks to the Advanced Android book

soooooooooo much needs to be written...

My app has a hierarchy of activities such that if Android decides to kill one of them, the rest are pretty much of no use

I was hoping for a mode where I could say 'if you have to kill any activity, kill the whole task'. But I don't see that being possible.

no, Android is designed around lots of independent activities

key here being "independent"

if they are so tightly coupled that they should live and die as a whole, make them a single activity

think of it as a "UI transaction", if you will

or, come up with a model to make them be more independent

so have a single activity but change the content view around

?

yes, or use a ViewFlipper, whichever fits better

I will check into ViewFlippers- never heard of that.

think of it as being like TabHost, minus the tabs

or like a CardLayout in Swing

several children, only one of which is visible at a time

also supports animations on transitioning between children

and a few other fun features to boot

That sounds like exactly what I needed.

(trying to remember what my other question was!)..

take your time -- nobody else here at the moment

Just looking at viewflipper and it doesn't seem like you can control which view to show- more like a load and forget type of animation.

methods on the superclass

setDisplayedChild()

ah

showNext()

showPrevious()

it's possible you could just use a ViewAnimator -- I had been thinking that was abstract, but it looks like it's not

Of course at this point I have the app just about done so it would involve converting a lot of screens from being activities.

How does the concept of View translate over from what was already an activity?

well

in your case, the simplest thing to do is probably:

Step #1: create a new activity that will represent the combined UI

Step #2: give it a layout file that is just a full-screen ViewFlipper

Step #3: In onCreate(), call addView(getLayoutInflater().inflate(R.layout.something)) on the ViewFlipper, for each of the layouts from your independent activities

Step #3a: you may need to change some of the widget IDs in those layouts, if you used the same names

(I try not to)

Step #4: Copy over the guts of the other activities into the new one

e.g. event handlers, other lifecycle methods

Step #5: update your manifest to have the new activity be the LAUNCHER one

Step #6: test, test, test

Step #7: nuke the old activities

you could combine all the layouts into one

or you could use <include> in the new activity's layout to avoid the addView() calls

so I couldn't keep each of the former activities as some sort of separate class? It would get kind of messy having them all in the same class

if the code is that tightly coupled, I'd argue the implementation should be in one spot

(btw, howdy, Ciaran H!)

however, you could try some sort of lifecycle method dispatch mechanism

know which child is alive and route onStop() and etc. to the right one, or to all children, as appropriate

(btw, howdy, Frank S!)

hi mark

dhaupert: so, there is definitely a cost to combining them

Howdy Mark!

let me take some questions from the newcomers, and I'll swing back to you if you have a follow-up question in a bit

Ciaran: do you have a question?

yeah, thinking of a class variable that points to the active view. Seems like there are tradeoffs to doing it, but definitely worth the investment of some experimentation. I don't have the option of a re-design as there are project requirements to match the flow of an iPhone app which is very hierarchy based.

I am designing a custom graphing widget. my question is would it be best to have a view for the graph itself and a surface view on top of that to do the graphing?

what do you mean by "the graph itself"?

I don't know the difference between that and "do the graphing"

I want it to graph accelerometer data

i already have an activity that does it i just want make a widget so i can have multiple instances of it and use it for various applications

like a button

that's all fine

but I don't understand the difference between "the graph itself" and "do the graphing", and why those would be separate things

oh ok

in your activity, how do you "do the graphing" today?

i mean i know the x and y of the graph are static so i dont need to redraw them everytime

so that would be a view and the surface view will do the plotting

i have a seperate thread that does the on draw

i guess the standard way to draw with a surface view

yeah, I don't think games, for example, are sticking fixed pixels on one layer and relying on alpha compositing to combine them

I suspect that is slower than just drawing it yourself

so, I'd just make your reusable widget either a subclass of SurfaceView or something that holds a SurfaceView

ok thats what i have so far

i have it extending surface view

(not even sure if you need it to be a SurfaceView -- I thought you could just draw on a Canvas supplied to onDraw() of a regular View, but, again, 2D graphics is not my area of expertise)

yeah i tried just a canvas but it wipes clean after every draw

the surface view saves state

:: shrug ::

OK

like I said, not my area of expertise

ok thank you anyway

Frank: got a question?

kinda

if I'm collecting real time data

"real time"

would you say write it to a file and flush the file to a database

or the database is fast enough todo an insert for every new data point

transactions on the database will be your bottleneck

as will doing the flush to the file

I'd batch them up in RAM and write a bunch of entries at once, if you can

if you have to do it one at a time, writing to the file and flushing the file to disk, then converting it into the database after the collection period is over, is probably fastest

OK Cool. We are able to buffer those values in RAM

and then flush RAM to file

and then when the time is right, insert the file into the db

thanks for the advice

if you can buffer, it may be you can go straight to the DB -- you're effectively amortizing the transaction overhead

but, there is less overhead for a simple file write

yeah there is a buffered writer

since there's no transaction log, rollback capability, etc.

yeah. It's a cloud database so I'm not totally worried about the integrity of the data

flat file is probably the simplest and fastest, then

swinging back around...

dhaupert: got another question?

Will do. I'll start with that piece first. Thanks mark

Thanks Mark, still trying to think through the logistics of the viewflipper stuff. Feel free to go back to the others for now..

OK

Ciaran: got another question?

I believe I am good till Tuesday.. Tahnks again

Thanks*

Frank: got another question?

How much notice do you need to get the waresubscriptions for the students taking the mobile programming course at FSU?

not much

We are 100% teaching it in the spring and applied to get an actual course listing

once the course listing is in your catalog, shoot it my way for verification

then, once enrollment is closed (or close to closed) for the semester, give me a headcount, and I can generate the coupons

ok. I believe we are capping the class at 30. I will look it up in the registery now

I'd like a couple of days at least before class begins, just in case I am traveling and have infrequent Internet access

will do

Thinking through this ViewFlipper stuff- thinking of using an arraylist as kind of a pseudo view stack, where I would keep the class references in the array and can push and pop by adding to or removing from the array. Then for each activity lifecycle function, I'd just pass that onto the top item in the array. Then I can keep all of my code separate. Does that seem sound to you?

even simpler: use setTag() and getTag() for the children of ViewFlipper

setTag() to associate your quasi-activity with the child

getTag() to get it back later

you can then use getDisplayedChild().getTag() to get at the object

a Tag can ben pretty much anything, right? Even a pointer to a class

any Object

that way, you don't have to worry about your array getting out of sync

good idea!

Appreciate your help Mark. Thanks again.

any last questions from anyone?

no sir talk to you Tuesday

yes, two more chats scheduled for next week

have a pleasant weekend, all!