hello, Harlan!

how can I help you today?

Hi Mark.

Hang on a sec., gathering our question here.

We are writing a BroadcastReciever that needs to talk to our Application class where we have a method that needs to get called but we're not sure how to get a handle to the Application class instance.

Are we going about this the wrong way?

call getApplicationContext() on the Context passed into onReceive()

So we don't worry about this from SO: "Although in current Android Activity and Service implementations, getApplication() and getApplicationContext() return the same object, there is no guarantee that this will always be the case ..."

hi all

(hello, Gabriele -- I will be with you in a moment!)

Harlan: well, I'd use getApplicationContext() consistently, but other than that, I think the answerer's concerns are over-blown

ok, that's what we need to know on that one. I do have some UI questions but you're welcome to get Gabriele in the meantime.

Gabriele: your turn! do you have a question?

I'm extending FragmentStatePagerAdapter, I don't understand if getPageTitle is called before, after getItem (or "randomly"), because my idea was to store a String inside the fragment and get this string as a title

but if it's called before, I still don't have the fragment (and so, no String)

I would not rely upon the order of getItem() versus getPageTitle()

however, you can lazy-create the fragment in either of those places, and use the lazily-created fragment in the other place

IOW, if getPageTitle() is called for a position, and you don't have the fragment for that position yet, go make it

if getItem() is called for a position, and you don't have the fragment for that position yet, go make it

then the order will not matter

ok, so you would create fragment anywhere

thanks

Harlan: back to you! do you have another question?

I have a UI question. In HTML we work hard to build one "layout" that works across many device sizes. In Android, it doesn't appear that this strategy works if your UI is anything beyond trivial. Is that the case?

IMHO, it works roughly as well on Android as it does on HTML, insofar as any given UI may or may not intrinsically scale well arbitrarily

the *mechanics* of doing it in Android usually involve separate layout files, compared to CSS media queries

OK, that makes sense and on that note, I have another question but maybe you get Gabriele next.

OK

Gabriele: back to you! do you have another question?

not for now, thank you

OK, if you come up with another question, just let me know

Harlan: over to yoU!

er, you!

I guess I'll ask my next one. I see information about using different folders for different layout sizes. Most info shows using mdpi, hdpi, xhdpi etc., or else small, medium, large, xlarge but I see little info about combining these two even though I understand its possible to do so.

If you're desiging an application to work on many devices of unknown sizes and dpi, what sort of layouts should I be creating?

using density qualifiers (e.g., xhdpi) for anything but drawable resources is a serious code smell

I saw this combination on a SO post:

and that person doesn't work for me

:)

if that person did, we'd have a serious conversation

So then my question is, what would you expect to see in my folder?

first, for new app development, I'd focus on the -swNNNdp, -wNNNdp, and -hNNNdp qualifiers, rather than the old -small, -normal, -large, and -xlarge ones

small, medium, large, and xlarge, and then perhaps landscape for each?

ok

like CSS media queries, the -swNNNdp family allow you to define your own points at which you adopt a new layout

whereas the original set of four were fixed by the framework

and, since -swNNNdp and kin were added in Android 3.1 or 3.2, they're generally available

ok, and NNN represents device width or DPI or neither.

We're only supporting 4.x

density-independent pixels

so -w800dp says "use this layout for screens whose current width is 800dp or larger"

-sw800dp says "use this layout for screens whose 'smallest width' is 800dp or larger"

what are the sw and the h?

ok, I see you were typing.

where 'smallest width' is whichever is the shorter axis of the device, regardless of orientation

-h is for current height, if that makes more sense as how you'd decide which layouts to use

Do I need folders for portrait mode or is the omission of "land" assumed to be portrait?

-wNNNdp and -hNNNdp are intrinsically orientation-dependent

which means -w is for landscape?

no, -w means "current width"

and the current width depends upon orientation

for example, take the master/detail pattern

when the screen size is wide enough, you want to use a list on the left and detail on the right

ok, so if you go this route you don't really need to use port or land qualifiers.

but on smaller sizes, you want to only show one at a time

usually, it doesn't matter whether they're holding the device in portrait, landscape, at a 45-degree angle, behind their back, etc.

it only matters whether the width is big enough

and that's where -wNNNdp comes into play

similarly, CSS media selectors focus on width, not orientation

(unless I missed something when I last poked at CSS media selectors...)

ok, that makes sense. And that really does clear up something that's very confusing right now. I've got about 6 android books now and none of them tell me what you've just been telling me.

well, you have one Android book that tells you this :-)

see my chapter on resource sets and configuration changes

and suggest improvements if you think it didn't cover this well enough!

Great! Is it possible to get your book in paper? I figure at almost 3000 pages I might have to have local freight bring it in?

I do not publish it in print

you are welcome to print it yourself, but if a tree walks up to you and bops you on the head in response, don't blame me :-)

overall, then, you use res/layout/ and res/layout-land/ for your base layouts, then override them in res/layout-wNNNdp/ or other variations

and you leave the density qualifiers for drawables

Question on a different topic. I see your book has quite a bit of information about Android Studio and Gradle. I've been reading and hearing from other people that Android Studio isn't ready for production use yet. I'm assuming you don't feel that way about it. Can you comment on that?

sigh

at the 2013 Google I|O Conference, Google indicated that they would be supporting Eclipse indefinitely

at the 2014 Google I|O Conference, Google indicated that they may not support Eclipse all that much longer

Android Studio has its issues, though the current beta is fairly solid

2800-page books steer like battleships

When we say it has issues, does it have entire pieces missing that prevent you from producing a working app?

oh, no

many firms have been using Android Studio for production work since last fall

Because Eclipse has issues too, to be honest. Quite a number of them methinks.

absolutely

and right now, I'd consider them roughly tied on bug count

similarly, Android Studio has some features that Eclipse lacks, and vice versa

I'm weary of things breaking and Lint screaming only to find out that several Cleans and restarts clear up the problem.

well, you'll have a bit of that in Android Studio too, though it seems to be less frequent

the bigger thing, from the standpoint of the book, is that I felt that I had to start covering Android Studio now, rather than wait for 1.0, given Google's waffling on Eclipse

all else being equal, I would have preferred to wait

all else being equal, I would prefer to have hair

We did have another question regarding updating the UI frequently. We have a timer where we may want to display seconds on the screen. The issue is not so much ow to do this, but rather, will it cause performance issues for us to be doing this? The code just uses a local date variable so it's not making db calls.

um, well, that will depend a bit on how frequently you are doing things

I think we have it at 500 ms right now

that shouldn't be a problem, so long as it is only when you are in the foreground

personally, I use postDelayed() "loops" for this, as it saves a thread and related hijinks

I think we are doing it from main_activity, which I thought "dies" when a screen is changed or the application is "minimized".

no

or, at least, not necessarily

an activity is destroyed when something calls finish()

such as the default BACK button behavior

if you start another activity, that does not destroy the original activity

if the user presses HOME, that does not destroy the activity that had been in the foreground

so what sort of class are you doing the postDelayed() from, your activity or something else?

activity or fragment

it's good for light loose time-based UI updates, like elapsed time counters and such

there's a sample app from the book demonstrating it

cool

We have an ActionBar where we'd like to have some dynamic text centered, with menu buttons on the right that are always showing (for certain screen sizes).

I've messed with adding a TextView using code but don't like the limited ability to center it.

Do we need to use a Custom Layout for our ActionBar to make this work?

personally, I wouldn't do that

in terms of how to implement it, I have no idea

Any comment on why you wouldn't do it that way?

it goes against the design guidelines

and I try to only violate the design guidelines where it's a clear advantage for the user

I'm assuming we could probably come up with a different design that doesn't need the text centered, but it seemed to me the alternative was to have it right next to the menu items.

have it replace your title, then

This happens to be our Project Name so the user doesn't expect it to look like a menu option.

or don't put it in the action bar

ok, I think I could make either of your suggestions work.

that definitely sounds like it should be the action bar title

or go with "App Name: Project Title" as the action bar title, if you feel you need to show both bits of text

(though that'll get wordy on phones in portrait mode)

yeah. Can we use something to detect device width in code? I'm sure, can't say I've looked for it though.

DisplayMetrics will have the resolution

Configuration should have the classic screen-size buckets (small/normal/large/xlarge)

If we're only supporting 4.x, do we need to use ActionBarSherlock?

no

go with the native action bar

ok

Mark, I have some difficult, sometimes, to *find* what of the features I use, are compatible with a specific version of Android

e.g. I want to check from android studio if the project I'm developing is using something not compatible with an old version

how can I do?

Gabriele: usually that is indicated in the JavaDocs

yes but I should check call by call if it is compatible

no way to check automatically the entire project? TT

well, Lint tells you if you are using something that is newer than the minSdkVersion

that automatically runs when you save the file

so changing my minSdkVersion it should me what it's wrong

tell*

thank you

your minSdkVersion should be set to the oldest version of Android that you are supporting

yes

your compileSdkVersion is what you are compiling against

Lint will tell you if you are using something newer than the minSdkVersion but within the compileSdkVersion

if either of you have another question, go right ahead

Mark, it seems that figuring out which Layout type to use is almost as much an art as a science. Is there any good information available somewhere on how to design more advanced layouts and which containers to choose and why?

um, well, "more advanced layouts" covers a lot of ground :-)

I'm looking for a handdrawn wireframe to upload here. Hang on...

The file includes three wireframes. The one in question is the first one.

Some design changes are now underway that call for some overlapping elements. Namely something that sits in the middle on top of the two "halves", at the top.

Which I think will call for a FrameLayout

?

I only use FrameLayout as a placeholder for dynamic fragments

I use RelativeLayout in cases where I need Z-axis ordering

ok. Should we use Linear for the child layouts within the Parent RelativeLayout?

possibly

Mark, I'm storing reference of fragments, anyway it seems that I like these reference to be inside activity (because there are life cycle calls), but I need inside the viewpager's adapter, too, where should I store them?

(ops sorry)

Harlan: I cannot tell you, from a glance at a wireframe, exactly how to implement it

ok, no problem. I think we'll be able to figure it out. We currently have it working on the target device.

Gabriele: personally, this is part of the reason why I wrote ArrayPagerAdapter, so I can more readily get back fragments that are the pages

what ArrayPagerAdapter is?

I'm also scared of memory leaks, by passing fragment reference

it is a more flexible PagerAdapter implementation than either FragmentPagerAdapter or FragmentStatePagerAdapte

er, FragmentStatePagerAdapter

it is covered in the Advanced ViewPager chapter in the book

thank you, I will read about it

Mark I think you answered all the questions I had for today. Let me code a while and I'm sure I'll have more.

OK

I guess I do have one more. Is there a particular wireframing tool which you are happy to recommend?

I've been going with hand drawings which works oKI

OK

I do not use a wireframing tool, so I don't have a recommendation

ok

any last questions?

Not from me, thanks for you help.

OK, that's a wrap for today's chat

the chat transcript will be published on http://commonsware.com/office-hours/ shortly

thank you Mark, see you next time :)

the next chat is tomorrow at 9am US Eastern Time

have a pleasant day!