Office Hours — Today, January 22

← Thursday, January 15

Jan 22
3:50 PM
Mark M.
has entered the room
Mark M.
turned on guest access
4:00 PM
Michael s.
has entered the room
Michael s.
Hi Mark, I just subscribed. My question for you is how do you recommend "export" Android Studio projects for others to use? I don't mean creating the apk, but creating something for others to use or work on in AS. Like your code samples for instance. I have seen recommendations to just zip the whole AS project directory, but that seems to have a bunch of unnecessary cruft.
Mark M.
howdy, Michael!
pretty much you would "export" what is recommended to go in version control
which means you would strip out build/, .idea/, .gradle/, the .iml file, etc.
4:05 PM
Michael s.
Can you point me towards a resource or page with what is recommended?
Mark M.
http://stackoverflow.com/a/17803964/115145
though I use the roster listed in my earlier chat comment
I'm not an OS X guy, so I don't have to worry about .DS_Store
and the entire .idea/ directory and the project's .iml file are generated from the Gradle build scripts, so they are all output, not input
Michael s.
Is it necessary to create the gradle wrapper or is that created automatically?
Mark M.
that depends a bit on where the project came from
if you create a new project in Android Studio, it creates a wrapper for you
Michael s.
I see.
Mark M.
the official line is that it all (gradlew, gradlew.bat, and all of gradle/) goes in version control
my line is: the official line is idiotic from a security standpoint
Michael s.
lol
Mark M.
I only put gradle/wrapper/gradle-wrapper.properties in version control,
and even that I strongly recommend that people look at the file and see if the distributionUrl makes sense
as that is where the Gradle comes from
Michael s.
Where do other people put them?
Mark M.
what is "them"?
Michael s.
View paste 
Sorry, you said "
I only put gradle/wrapper/gradle-wrapper.properties in version control,"
Where else would you put them?
Mark M.
sorry, I still do not know what "them" is
Michael s.
radle/wrapper/gradle-wrapper.properties
Mark M.
that's where it goes
4:10 PM
Michael s.
I see.
Mark M.
there are other files that make up the whole Gradle wrapper, though
gradlew, gradlew.bat, and gradle/wrapper/gradle-wrapper.jar
I do not put those in version control
and nobody should ever use them, unless they completely trust the source of those files
Michael s.
Now I understand. Of those files, the only one you put in version control is gradle/wrapper/gradle-wrapper.properties.
Mark M.
right
and that's the only one that Android Studio actually uses
the rest are for command-line builds using ./gradlew
and I use my own standalone installation of Gradle for that
so I control where it comes from
Michael s.
Maybe I should have explained my situation a little more. I am a teacher and I want to give my students an Android Studio project to start with and that they then build upon.
Mark M.
OK
Michael s.
Am I correct your would recommend doing this via Git just like the sample code from your book. The .gitignore would leave out the cruft.
Mark M.
if your students are sufficiently git-aware, sure, that'll work
Michael s.
If not?
Mark M.
if you read through the book, you'll see that I have 19 tutorials integrated in there
Tutorial #2 does exactly what you describe: have students import a starter project
in my case, while that starter project happens to be in the book's git repo, I also distribute ZIP files
https://github.com/commonsguy/cw-omnibus/releases
partly, that avoids people having to learn git just to use my code
partly, that deals with the fact that my repo is for the whole book and therefore is, um, large
Michael s.
Yes I see that.
Mark M.
what's in the ZIP file is what is in the corresponding directory in the repo: https://github.com/commonsguy/cw-omnibus/tree/m...
Guido
has entered the room
4:15 PM
Guido
Hello everyone!
Mark M.
Michael: let me take a question from Guido, and I will be with you again in a bit
Guido: your turn! do you have a question?
Guido
Hi Mark, yes :-)
I'm a beginner.... I've gone through the core chapters of the book
Mark M.
great!
Guido
and now I wanted to look into the new stuff in Lollipop
I started with the recyclerView and my understanding is that Google made it in such a way that is very flexible, but us developer have to work more on the details
Mark M.
that is an understatement
I am working on a RecyclerView chapter for the next book update
Guido
that's great, as far as I saw on the internet, many had their own implementation, but many are a bit "dirty" and there is no guideline yet, so I was going to ask what are your thoughts
but you replied already :-)
Mark M.
thoughts regarding what, specifically?
Randall M.
has entered the room
Guido
over the last two days I had been looking how to implement the itme selection
4:20 PM
Guido
*items selection
Mark M.
(Randall: hello! I will be with you shortly!)
Randall M.
Thanks Mark, no problem.
Guido
and perhaps implementing ripple and the new animations that have been introduced
Mark M.
yeah, that is all stuff that I need to get to in the RecyclerView chapter
Guido
given that your new version is in a month or so, is there any approach you would suggest? or is it too early?
Mark M.
partly, it's a bit early -- I have poked and prodded at RecyclerView a bit over the past few months, but nothing substantial
partly, that's probably a bit big of a topic for the chat
I mean, covering the animations alone might run 20 pages in the book
Guido
View paste 
haha :-)
yes, perhaps you are right.....
Mark M.
so, I can't really help you on that -- sorry!
let me take questions from the others, and I'll be back with you in a bit
View paste 
Randall: your turn! do you have a question?
Guido
Sure no problem
4:25 PM
Randall M.
Yeah, so I'm trying to implement a ViewPager, in a fragment that's going to be overlaid onto an existing Activity/Fragment.
I got the overlay working with a placeholder view, and now that I'm putting in the ViewPager, which requires the support stuff, now stuff that was working is broken. I need a little push to get past the support/standard differences, I think.
Mark M.
if by "requires the support stuff", you mean the backport of fragments, ViewPager supports either the backport or native fragments
Randall M.
But ViewPager itself requires the support library, no?
Mark M.
well, the Android Support package is made up of many things
ViewPager lives in both the support-v4 and support-v13 artifacts
you would use one of those
specifically, if your minSdkVersion is 13 or higher, you probably want the support-v13 one
and support-v13 has flavors of FragmentPagerAdapter and FragmentstatePagerAdapter that work with native fragments
both artifacts have flavors of FragmentPagerAdapter and FragmentStatePagerAdapter that work with the fragments backport
Randall M.
So, what does the import look like, then? When Android Studio asks for auto-insert the import for me, I only get the normal and v4 versions offered.
4:30 PM
Mark M.
the import of what? the normal and v4 versions of what?
Randall M.
View paste 
import android.support.v4.app.Fragment;
import android.support.v4.app.FragmentManager;
import android.support.v4.app.FragmentStatePagerAdapter;
Mark M.
by "normal" you mean android.app.Fragment?
Randall M.
Yeah.
Mark M.
OK, well, those are the two fragment implementations
if you want normal fragments, use android.support.v13.app.FragmentPagerAdapter
if you want to use the backport, use android.support.v4.app.FragmentPagerAdapter
the v13 edition lives only in support-v13; the v4 edition lives in both support-v4 and support-v13
Randall M.
When I replaced my working placeholder (simply an ImageView) with the ViewPager in the fragment I'm going to be inserting, the method in my Activity that displays the overlay now doesn't compile.
View paste 
	private void showHelp()
	{
		HelpFragment fragment = new HelpFragment();

		FragmentTransaction fragmentTransaction = this.getFragmentManager().beginTransaction();
		fragmentTransaction.add(R.id.mainMenuFragment, fragment);
		fragmentTransaction.commit();
	}
Mark M.
make sure you are not mixing and matching implementations
if you are using support.v4. fragment classes, *always* use support.v4 fragment classes
if you are not using support.v4 fragment classes, *never* use support.v4 fragment classes
Randall M.
It can't resolve the add() method now.
Mark M.
what is your import for FragmentTransaction?
Randall M.
Ah: import android.app.FragmentTransaction;
Mark M.
that will only work if HelpFragment inherits from android.app.Fragment
4:35 PM
Mark M.
again, you need to sychronize your fragment implementation
pick one (support.v4 or normal) and stick with it across the board
since ViewPager can work with either (given the right adapter class), ViewPager should not influence your decision
Randall M.
Yeah, it extends Fragment, which is now v4.
Mark M.
let me take questions from the others, and I'll be back with you in a bit
Michael: your turn! do you have another question?
Randall M.
OK, thanks...I'll work on the changes...
Mark M.
Michael: if you come up with a question, chime in and let me know
Guido: your turn! do you have another question?
Guido
yep....
i prepared it so I'm going to paste it to save time
View paste (12 more lines) 
I'm looking into the NavigationDrawer.

The example on the google training page seems like it's always instantiating a new fragment and replacing any existing one, am I right?

/** Swaps fragments in the main content view */
private void selectItem(int position) {
    // Create a new fragment and specify the planet to show based on position
    Fragment fragment = new PlanetFragment();
    Bundle args = new Bundle();
    args.putInt(PlanetFragment.ARG_PLANET_NUMBER, position);
    fragment.setArguments(args);

    // Insert the fragment by replacing any existing fragment
    FragmentManager fragmentManager = getFragmentManager();
    fragmentManager.beginTransaction()
...
4:40 PM
Mark M.
personally, I would probably reuse the fragments, unless I had a strong reason not to
I do not know why specifically they elected not to do that here
usually, a navigation drawer has a modest number of entries, so there are only so many fragments
Guido
exactly that is what I thought...
or perhaps I missed some other detail, but I don't think so
Mark M.
now, one case where reusing fragments won't work is if you want to use the same instance for multiple bits of data
in this case, they could say that rather than N PlanetFragment instances, there is only one, that they update with new data
there, you wouldn't run replace() transactions at all, except if there is no fragment already around
conversely, if for some reason you had a nav drawer with dozens of entries, you might have heap concerns
and so allowing fragments to be garbage-collected may prove necessary
so, there is no "one size fits all" approach
Guido
I see, that's a good point
4:45 PM
Mark M.
the downside of the documentation is that they typically only present one solution and may not offer guideance for when that solution is/is not appropriate
that's one of the reasons why I recommend people get a good book on Android app development :-)
let me take questions from the others, and I'll be back with you if there is time
Randall: your turn! do you have another question?