hello, Brent!

how can I help you today?

Hi Mark.

I'm trying to use your camera library for an app.

Trying to present a square preview...

and then a square picture.

that's not really what the library is aiming for

oh. So any advice on how to do that?

it's just to be able to take a basic picture, without having to rely on shaky ACTION_IMAGE_CAPTURE stuff

hmm.

with respect to the preview, I haven't the foggiest

ok. so can you suggest an approach?

ok

with respect to the photo, you'd have to do your own cropping logic

yeah, that's my stratgy

strategy

e.g., find the shortest axis, then crop the edges of the longer side so both axes match

also note that my library is going to have to get overhauled

yeah, makes sense

as android.hardware.Camera is now deprecated

because of 5.0?

right

yes

so I'll need to rework matters to be less reliant on things like Camera.Parameters

though the camera2 has no backward compatibility, right?

correct

so I'll need to use both APIs

ouch

but it means that my library's API can't be exposing Camera.Parameters

as that won't be used in some cases

oh, so that will be a big change

I'll be writing a blog post about all of this sometime next week, I think

at least in the way that some people are using the library, i assume

yes, it will be a total rewrite, pretty much

and I'll be scaling back the use cases to focus on the itch that I need to scratch, which is taking basic pictures

(and videos)

ok. I'm actually able to get your preview to be square just by putting a mask over it

in a framelayout

if that works for you, cool

I can see that being OK for TextureView

hopefully it works for SurfaceView as well, if you're supporting Android 4.0 and below

but the resulting picture is different from what i see in the preview even accounting for e masking. (I'm not supporting below 4.0).

*the masking

different in what way?

I take a picture of an object, and have it fill the preview widthwise, but the picture has space on the sides

as if it actually took a wider view than the preview indicated.

oh, well, that's rather likely to be the case

the preview aspect ratio and the picture aspect ratio are almost never the same

i did that test in CWAC Demo from your repo, too, same outcome.

OH

so i have to make them the same?

you can't "make them the same", as that's determined by camera hardware, not you

the available sizes for the preview and the picture do not all have to have the same aspect ratio

so... can i account for that in my cropping then?

well, that depends

i can find out what the aspect ratios are and do some adjustment?

will that differ from device to device, though?

my suggestion for the cropping is to chop off an equal amount on both ends of the longer side

let's suppose, for example, that the picture is landscape, and so the longer side is the horizontal axis

the longer side is not the only side on which I'm seeing extra space in preview vs. taken picture

understood

ok

please proceed :)

the cropping to make things square will take care of only that side that is being cropped

ok. is the other side hopeless?

I have no idea how you would ensure that the preview exactly matches the picture, as even beyond aspect ratios, the bitmaps are determined by the camera hardware, not you

for all we know, the camera will return real previews and images of clowns for the picture

ye of little faith :)

no, I have plenty of faith in the power of clowns

fair enough

i asked a question about all of this on SO.

I think I might have even seen that one

I got one answer. Can you take a quick look and see if you think it's reasonable?

got a link?

I have been trying to implement the answer, but having trouble. Yes:

well I didn't see that one

i thought maybe not, since I thought you might respond

in the future, use commonsware-cwac as the tag

if you had

ok

as is noted in the project README

didn't notice that. will do next time

"in getPictureSize() must pick one of the resolution with same ratio as your preview size. " -- that is overly optimistic

in theory, it would

sorry

in theory, it would work

in practice, there's nothing to guarantee that there is such a match

hmm. seems weird.

but not entirely surprising

with respect to the rest, let's just say that's why my next library is going to be a lot simpler and aim for really simple scenarios

apparently the makers of the Instagram app have accomplished what I'm trying to do

yes, and they have a whole team working on this, and more money than either you or I have

speak for yourself (no, you're right, it's true)

so I have no doubt that there's ways of doing this sort of thing, but it's not my cup of tea

ok

to put it another way, if more than 1% of your app functionality is tied up in using the camera, my library (current and future) isn't really what you're looking for

ok. if i could capture the preview and use that, I'd be fine, I think, but i saw in another SO answer from you that that's not available

it's not exposed by my library

do you know if I can get it from the Android camera API?

collecting preview frames via a callback is certainly possible

ok

Vine, for example, actually doesn't record a video -- they stitch together a video from preview frames

yeah, I think i saw other SO posts explaining how to do it

there's a "preview callback" hook in android.hardware.Camera

biggest headache, IIRC, is that the previews come in YUV, not JPEG

ok. i guess that's what I'll go for, to avoid the differences between preview and taken picture.

i think the SO answers address how to handle the YUV

i thought they also say there are other possible formats?

anyway, not your problem

I don't think we have a ton of control over preview frames in the android.hardware.Camera API

android.hardware.camera2 has some more power here, for compatible devices

also note that the raw preview frames won't be square, unless you happen to choose a square preview size (which may not exist on any given device)

I'd turn them into something i could crop

so I'd use my mask to make a square preview

then capture the whole preview (not square)

(so the first step would be to show a square preview to the user)

and then crop the preview and show it in another activity

that's what I'm thinking at this point

sounds reasonable

sounds somewhat straightforward, but i had no idea what i was getting myself into when I started this

so who knows what clowns will jump out at me now

ok, well, I guess I can let you go, unless you have any other nuggets of wisdom to share (aside from "get out of Android programming" :)

(I know you'll probably stay here, but I'll leave and stop bombarding you with questions)

well, it's a quiet chat room tonight

if you have questions, go right ahead

well, I'd love to try to implement this right now and have you hold my hand while i do it, but I'm not nearly adept enough to do anything that fast :)

I'm trying to think of something else to ask you about, but can't off the top of my head

no worries

there will be more office hours chats in the future :-)

yeah, though maybe not this quiet. Can we schedule another Thanksgiving right after your next one?

sorry, not my department

your next office hours are not for another couple of weeks?

is that right?

i don't have the schedule in front of me.

no, I have a 7:30pm US Eastern one scheduled for next Tuesday

though I just added that to the calendar yeseterday

oh, ok, that's good

here's something else i can ask you about.

I'm using Ion, having learned about it from your book

here's an SO question I asked about it that has me kind of worried:

bit nervous about his changing the API, though of course I can just stick with one library version

well, changing APIs between major versions is perfectly reasonable

obviously, the bigger the change, the bigger the headache

yeah, i suppose it can't be avoided

my book sample is on an old Ion due to bugs in Ion, where I was having difficulty using a newer version

but I do need to update it sometime

i guess I'm more concerned about the x.+ gradle dependency

my general rule is to only use + on the patchlevel (e.g., 21.1.+)

as any library author who puts a breaking API change in a patchlevel should be slapped with a trout

well, i think in his readme he says use 2.+ now.

that's his opinion :-)

authors are welcome to make their own suggestions

and you, the developer, need to make the choice that you're most comfortable with

yeah. sure. no rules set in stone.

yes. i'll probably just stick with something fixed.

presumably he recommends 2.+ because he wouldn't make breaking changes without going to version 3, but no, I'm not sure I'm comfortable with that, and it probably doesn't matter much

so long as you check back from time to time to see if an update (with bug fixes, etc.) is worth taking on

the value of + is in the automatic upgrading

if you manually check frequently enough, you don't need automatic upgrading

Right. I don't really understand how the gradle dependency stuff works. Does something just get downloaded once to my project?

that depends on whether or not you are using the + wildcard

right. i guess the + tells it to check

if you have compile "com.foo:bar:1.2.3", that version will be downloaded on the first build

and you'll stick with that until you edit the build.gradle file

makes sense

if you have compile "com.foo:bar:1.2.+", then Gradle will check for updates on the first build of each day

i see

and download the latest if your project has an older one

there's a command-line switch you can use to force a dependency check (--force-dependencies?)

ok. well, I'm about ready to wrap up. any quick advice on becoming a better Android dev? I'm the only Android dev for a small company, making apps for their clients.

not working with more experienced people much

that's a rather broad question

I've been taking the Udacity course

i know

so don't worry about being able to provide much

or anything

yeah, I don't have a great way to answer that across the board

right. different for everyone. i'll keep at it and with time I learn

ok. well, i really appreciate your time tonight and all the work you've done with your book and otherwise.

happy to be useful!

have a good night and a happy Thanksgiving!

you too!

Thanks. Bye.

hello, EGHDK

how can I help you today?

I made a custom adapter extends array adapter but I got an error that there is no default constructor. What tells a class that there is no default when the docs show that there are a bunch

there may be "a bunch", but none may be a default constructor

"The default constructor is the no-argument constructor automatically generated unless you define another constructor"

If I made the array adapter class how would I specify that one of them is default?

Oh. Hmm... That's interesting.

most likely, the right answer is that you implement a constructor, chaining to the superclass constructor

So another activity being killed question. I know I've tried to comprehend this multiple times with you. But let me try to shape the question this way. What events would happen for the bundle in onCreate to not be null?

1. configuration change (e.g., screen rotation)

2. process is terminated, but the user returns to your app while it is still in the recent-tasks list

those would be the big ones

There would be a valid bundle even if the process is killed?

in scenario #2 above, yes

the reason why a Bundle is used is that a Bundle can be passed across process boundaries

and so a core OS process maintains the state of the activities in the back stack for each task that is in the recent-tasks list

How? I thought if the process is killed all 4 possible components are dead.

they are

Oh

however, processes can be created as well as killed

if we did not create them, there would be nothing *to* kill

So the activitymanager holds onto bundles for us?

and, if the user elects to go back into an app, where that app still has a task on the recent-tasks list, Android will effectively resume the task

well, I can't say whether it is literally activitymanager

something in a core OS process does

Gotcha. Okay. I didn't know that. So I can have activityA go to activityB then go home and force close the app. Then go to recents and the bundle will be valid for both activities?

yes

well, actually, no, due to the "force close" bit

if you mean "Force Stop" -- the button in Settings -- that wipes out the recent-tasks entry

Force close clears the entry?

Oh ok thanks

but if the process is terminated more naturally (e.g., low-memory reclamation), or even through DDMS, Activity B will get its Bundle back when Android restores the task

and, if the user presses BACK, then Activity A will be created and get its Bundle back

So if my activity is open and I open a ton of other activities what will happen? Will I get an oom? Or will it start to kill earlier activities?

Activities are not "killed"

processes are killed

Destroyed?

the only reason an activity is destroyed is because something called finish() on it, whether programmatically (e.g., you actually call finish()) or based on user input (e.g., user presses BACK)

if you keep creating new activities, you will eventually get an OutOfMemoryError, as you will run out of heap space

Okay, out of time. May follow up next time. On a train now so I decided to give mobile commonsware a chance. Hahaha thanks again

the next chat will be next Tuesday, also at 7:30pm US Eastern

Happy holidays

you too!