howdy, Chaitanya!

hello

how can I help you today?

hi Mark

well this is my first time trying out the office hours

I don't know the scope of the questions, but I thought I'd try one

I was implementing a CWAC today

ViewSwiper

and noticed a large time difference between my swipe gesture and the actual view flip

well, the flip will not begin until the gesture is complete

that is inherent in the way GestureDetector works

yes, I did mean the time difference from the point I finish my swipe. it takes a full second or more to flip

what are the views you are flipping between?

in other words, what are the immediate children of the ViewSwiper?

previously I had implemented viewFlipper with a custom GestureListener. Admittedly that had a slight lag too...around 0.5 seconds.

there are 3 grid views of 12 icons each

what you are probably seeing is the time to render all that

particularly depending on how the icons are being handled, that could be a bit slow

you might consider using Traceview to get a firmer grasp on where the time is being spent

thank you, i'll give that a try

also, long term, you should probably consider ViewPager from the Android Support package (formerly known as the Android Compatibility Library)

on the same topic, I think I should try to implement ViewPager to have an immediate effect

that is the long-term direction for horizontal-swipes-to-move-between-things

haha yes

I need to cover ViewPager sometime soonish

that would be very helpful indeed

well thank you for your time Mark. have a good weekend

you too!

howdy, Adam!

Hi Mark!

how can I help you today?

I have a concept-y question about Fragments and being properly modular.

I'm working on an application that seems to have a clear architecture when I think about it using Activities.

For example, one part involves editing text.

If a user wants to use a different text editor for that part, it's easy to do so.

I don't do anything special as a programmer to enable that.

If they want to use a different part for "processing the text", as long as the other programmer looks at my intents/documentation, they can make something that drops right in.

However, I seem to get lost thinking about it using Fragments.

if you want to have that sort of drop-in replaceability (is replaceability a word?), you will continue to have activities be your interface

fragments are simply an organizational tool to help you make a single code base support multiple screen sizes

One thing I was thinking of doing was making an activity for each conceptual piece, and then making a "jumbo activity" that looks nice on big screens.

On phones, it would work nearly exactly the same as it does now, but using fragments would possibly make it easier for me to make the "tabletactivity"

yes

Awesome. I'm not too far off the mark then.

however, you can't embed a third-party activity as a fragment in some activity of yours

if your text-editing portion would be a full-screen activity regardless of screen size, you can stick with your existing plan

if, however, your text-editing portion would logically be only part of a screen on a tablet (e.g., to the right of a ListFragment), then you will be stuck with solely your own text-editing solution

Would it be wrong to have an option for tablets to force the "loosely coupled activities" from happening, as compared to the integrated activity that has a bunch of fragments?

um, I didn't follow that

On phones, I plan on using fragments, but with most activities only having one fragment.

makes sense

If I don't do anything special, the same thing will happen on a tablet.

well, the point of bothering with fragments in the first place will be do something special

e.g., load a layout with multiple fragments in it

However, most nice Android 3+ applications will watch for the larger screens, and change the layout so I can reuse those fragments and show more than one.

right

The downside for my application of the "more than one fragment screen" is that it isn't as easy for third parties to integrate themselves in.

also right

I suppose I could offer the option to users to not use that "more than one fragment screen"

in principle, yes

you have to ask yourself whether the resulting UX will be worth it

Yeah. If I expect that to be common, I might as well ignore fragments all together.

at least for that area of the app

Is this something that other people are wondering about?

integration like you're aiming for is an under-utilized feature of Android

dealing with tablet screen sizes is an under-utilized feature of Android, though growing

hence, the intersection of those two is not that popular

ha

understood

in an ideal world, this would be a bigger problem, strange as that sounds

I've written a few apps, not many, and never had a use for the loose-integration stuff I'm doing with this one

but this one is unique with the ones I've written in that it has an "open workflow"

and the intent system seems to be a really powerful way to allow the entire community to do what they want

Alright, I think that's it. Thanks!

happy to help!

Hi all

howdy, David!

I've got another question for you.

go right aehad

er, ahead

Lets say I have a library that someone is building with their project. Is there anyway to get the application Context and the top viewgroup without passing information to the library?

not really

there's absolutely no way to arbitrarily get views, such as the top ViewGroup

some people are creating true singletons out of the Application singleton (i.e., static data member to access the instance), though I'm a trifle nervous about that

(no solid reason for the nervousness, just a feeling)

Hmm, I have been passing the ViewGroup to my library and looping though them all using .getparent until I get the WindowDecor.

But I was trying to find a different way.

well, there's an ID for that, though I forget it off the top of my head

android.R.id.context

or content

I cant remember either off the top of my head.

yeah, I think it's content

given the Activity, findViewById(android.R.id.content) gives you the DecorView

Yeah, but calling (ViewGroup)findViewById(android.R.id.content); doesn't work inside the activity.

however, you can't get it from an Application

Always returns null.

you'd have to wait until after setContentView()

Ah,

Well since my library doesn't really display anything I never call setContentView().

howdy, scottt!

hello! no questions today; just lurking.

then don't call your library until after setContentView()

or something like that

It is being called after the activity setContentView();

oh well.

I would expect that to work

FWIW, here's a sample project where I use android.R.id.content: https://github.com/commonsguy/cw-advandroi…

it's a sample from the next edition of the Advanced Android book, showing how to use setRetainInstance(true) with dynamic fragments for maintaining state across configuration changes

My last question is, do you know if it is possible to have a button/menu "float" above the application that the library is part of.

ohhh

well, that's really the application's job

the library has no way to know where it might be safe to display something

hmm

Alright thanks.

if anyone has any questions, chime in

he he, i'm finalizing a contract for my first non-trivial professional android dev gig. it's basically tweaking and production-izing a mostly-done system and perhaps staying around to manage on-going dev

congrats!

Mark, does each activity have its own Window Decor?

thanks!

beats me

DecorView I should say

hmm

off the cuff, my guess is "yes", but I've never examined them that way, and I'm not sure I would rely upon whatever the current behavior is

I'm not relying on it yet, just been testing it all out.

Using TapJacking to send all motionevents to the library in the application and send back the information.

Trying to allow it to record the interaction for testing applications.

oh, wait, this is your testing library

Cant figure out how to stop/start the recording.

Thats why I thought of the floating menu.

Yes this is my testing library.

well, the problem there is -- what if the menu is above something that needs to be tested?

Well, I am going to have it either A.) Be moving able B.) Allow you to like pull it and have it flip from being on the bottom to being on the top.

Question is though, how to I keep it on the screen.

I tried to do it in the tapjacking service but that didn't work at all.

actually, that would appear to be the right answer, though

what didn't work with that approach?

How would you do it though TapJacking?

Tapjacking involves adding a View to the Window

most tapjacking involves that being transparent

it doesn't have to be

Well when I could click a box or somthing that I had drawn on the tapjacking layout it wouldn't notice that it was a button.

right

and, AFAIK, it doesn't have to be just a plain View

though I haven't tried anything else (e.g., RelativeLayout holding a Button that would be your toggle)

Hmm I tried that but I couldn't get the button listener to get any hits.

if you tried an OnClickListener, that's not surprising

Well not the relativelayout but I did inflate a button on the view.

it won't respond as a normal widget AFAIK

but touch events should register

just as they do on the transparent tapjacking view

What, just in the touchEvent test to see if that area was touched

right

Yeah I guess that is one way.

Sweet thanks, that a good idea.

Would I be able to use an xml layout to draw it?

I haven't tried using a LayoutInflater from a service that way

you can try it, but it might not work

I'll give it a shot.

Thank you Mark!

happy to help!

we're running low on time -- any other questions?

No I am good thank you.

What's the meaning of life?

life has no meaning, because life is merely a breakfast cereal, or possibly a board game

lol! i was expecting "42"

no, that's how many roads must a man walk down

later, everyone

(btw, i'm going to steal that response)

you're welcome to it

have a pleasant weekend, all!

u2