[Seminar] [Android Apps (Now with Jelly Beans!)]
[Jordan Jozwiak] [Harvard University]
[This is CS50.] [CS50.TV]
>> Hello everyone, and welcome to the Android Apps (Now with Jelly Beans!) Seminar.
It's called Now with Jelly Beans, of course, because
the latest version of the OS is called Jelly Bean.
When I talked about Android last year and did this basically same seminar
I was presenting the design patterns and stylistic choices for Gingerbread,
even though Ice Cream Sandwich had come out at the time,
and this is something we'll talk about going forward a little bit.
Android, of course, has some issues with fragmentation,
so the latest Google operating system is usually
not really going to become common among the users for potentially up to a year, unfortunately.
>> But disregarding that, we'll talk about plenty of reasons why
Android is much better than iOS.
Okay, we'll talk about Android versus iOS,
some design paradigms, how you'll get set up in just one slide,
and the big difference between this and last year is I just want to
zoom through some conceptual things working with
the operating system and then go into a really basic example.
In fact, just the example that Google describes for building your first app,
and we'll go through it together and just describe.
>> I know many of you have only coded in C, so Java is already going to be
a different perspective, and this way you'll get your feet wet
and feel a little more comfortable with it hopefully.
A quick summary, Android versus iOS.
In Android there's this one-time developer fee of $25,
none of this $100 per year thing.
There are no restrictions, which means that if I want to submit an app,
I just submit it, and there's no approval process like there is for iOS.
You get to develop with Java using Eclipse,
which is cross platform, so it doesn't matter if you have a Mac,
Windows, or some Linux machine.
Of course, with iOS you have to use XCode on a Mac,
and Android is used by many more people,
so if you want your app to have some sort of visibility or perhaps
make a little money from advertisements
you're probably more likely to benefit from Android.
>> And one thing that's always been known about Android
is the extreme amount of customization, whereas iOS is very fixed in their ways
so that they can maintain security and control over every little aspect
of the design within their OS and the individual apps.
Android is very free form, and there's so many more possibilities.
Okay, some design paradigms.
Notice here just like iOS has tablets and iPhones and iPod Touches
they have to support, say, like a dozen devices if you want to support
historical things as well.
With Android you have to support hundreds of devices,
so there are some things that Google has been trying to implement
to make the user experience a little more consistent,
but we'll also talk about how this means that there are issues of fragmentation
that you constantly have to be aware of supporting.
Fragmentation means that there are many different operating systems,
many different phones with different hardware running Android all at the same time,
so this graph here goes back for about 6 months.
Yeah, 6 months, and you can see how the darkest band
on the bottom is Jelly Bean, which came out over the summer,
and you can see right now probably about 2% of the phones have it.
>> Ice Cream Sandwich came out over a year ago,
and a quarter of the phones have it.
There are still a lot of phones that are using OS version from years ago.
One thing that Google has tried to do to make the user experience
a lot more consistent across apps is starting with Honeycomb,
which is the tablet version, then Ice Cream Sandwich and Jelly Bean,
they're really trying to emphasize use of this action bar,
which is what you can see at the top here,
everything right here, including this little settings button.
It's the design choice.
Now, whenever you see the 3 dots it means click on this,
and there will be a drop-down menu, which has some sort of settings.
This only shows up because I clicked on this button.
This is something that they're trying to use to make apps a little more consistent
across the board and so the user has a better sense of uniform experience.
>> Okay, so in case you haven't done this already or if you're watching at home
then you can follow these steps to set up your coding environment.
It will involve going to the website here.
You can Google installing Android SDK
and follow some descriptions there.
They tell you everything.
They have you install the SDK, download Eclipse Classic version,
even though, of course, we're coding in Java.
They recommend this one, and then this ADT, the Android Development Tools,
is a plugin that you install into Eclipse which allows you to
have a much more streamlined experience with Android within Eclipse.
It will give you some graphical user interfaces
for designing the views, and it will give you much more support
and the ability to launch with the emulator and all that sort of thing.
Application framework.
>> I want to talk about how the projects within Android are structured,
and then we'll go into a quick example, and hopefully
you can ask questions at any point and feel comfortable by the end of it.
We have some jargon first.
An activity is like the screen you see when you launch an app.
The entire experience is the activity itself,
so you could think of it as a screen or a view,
but it's actually the source code side of it.
We still call the actual interface part of it a view.
It's sort of like how in pset 7 we had the controller and then the view.
The activity is more or less the controller,
and the view is what we're doing in terms of the XML
that is associated with that activity.
Fragments are something that's implemented in Ice Cream Sandwich going forward.
It's just an idea of taking parts of the view or the activity
and dividing them into separate areas so that we can
make our code more usable for these many different devices
that we have to support, and it's just a way of trying to
also factor out more code.
Services are background things like playing music or navigation directions potentially.
Content providers, these are APIs within the operating system
that allow you to access shared data such as contact information,
and then an intent is something we'll use when we want to launch
a new activity from our current activity.
>> Hello Android, this is going to be a project that we'll talk about.
I'll actually do it for you, and then we'll do a thing where we click a button
with some text and launch a new activity.
Very straightforward, but I want to go through
what will go into a project like this.
When you make the new project you'll see within Eclipse
there's this project called Hello Android.
Then there are a whole bunch of folders here.
The ones you're really concerned with are the source folder,
the resource folder, the res, and to some extent the libs folder for libraries.
And just so we're on the same page with that
if you were to create a new project,
you can do this right here, so if I want to call it HelloAndroid,
and then it automatically does a whole bunch of the information for us.
The package name is supposed to be a unique identifier
that would normally be associated with the website, if you had one.
>> For example, I will call this net.cs50.helloandroid.
And I already have made this project once.
Okay, sorry. Let's call it HelloCS50.
And then it will ask things like what sort of icon do we want to make.
This is all because of the Android Developer Tools interface,
the plugin that we added to Eclipse, so we can choose things like
what icon we want, and that would go into that depth if we want.
But in the end, just make the project,
and everything shows up right here.
As I showed on the other screen,
we have the source folder, and I'll talk about what all this means soon,
but you can see that immediately it takes us to the HelloCS50 screen.
There are some buttons over here for adding text and text field layouts.
It's sort of like XCode but unfortunately not quite as streamlined.
But the clips will be your friend and ADT in particular for doing this.
>> Okay, the source folder is where
the Java files are held, and this is actually the launch of your program.
It's basically like the controllers.
The resource folder or the res is where we'll keep screen layouts,
images, sounds, text, animation and everything else, libs, obviously, libraries.
And the Manifest, it's the way that the Android system knows
how to interact with your app.
It tells it about permissions and what activities will actually be run.
It's all the essential information that's necessary to run your app.
The source folder is—if we expand it as you can see right here.
And an example that a code would look—this is the default code.
As we called it, MainActivity.
By default, we get onCreate, which is a function that's called when this activity loads,
so you want to call onCreate (savedInstanceState).
This will restore any bits of information
in case the app was paused.
>> There's a whole activity life cycle chart which you can look at
when you get a little more in-depth in it,
but the most important line of code there is this setContentView function
which will load the resource file for the layout.
Then what onCreate here is basically doing is it's saying
when I create this activity I want to load this layout.
And we'll talk about what that layout is in a second.
If we were to launch that here it looks exactly like this,
and by default because we have Eclipse doing this and ADT doing it for us
this is all boilerplate code that's created for us,
and we can move on and change things as we like.
The resource folder, like I said, this is where we hold all layouts,
drawables in terms of any sort of images—
they're called drawables—and then sound files, menus.
It's a way of a whole bunch of XML in a nice sorted fashion.
As you can see, there are .hdpi, ldpi, mdpi and xhdpi folders for the drawables.
These are different screen densities, so high density pixel per inch,
low density, medium density, extra high density.
>> This is, again, so we can support all these different devices,
and ideally, you will have different images for each different resolution.
Layouts are where we include all the different layouts that will be used in different activities.
They could also include layouts for fragments,
which means partial activities basically.
If you want to do something cool like whenever you rotate the phone
you want it to have a different layout you can do layout-landscape as a different folder,
and Android automatically has a whole bunch of these rules within the resource folder,
so it will know to look at different folders based on the current setup of the phone,
what sort of hardware you're using.
Similarly, this values-v11 here and values-v14
and the default values folder this is for—
well, values by itself, this will be the default values across all versions of the operating system.
On the other hand, v11 and v14 correspond with Honeycomb
and Ice Cream Sandwich, respectively.
Again, these are ways that—within these folders are different strings
and styles, so you can customize the appearance of your app
or potentially even its functionality, although that would probably be a bad idea,
based on the version of the operating system.
>> And I talked about all this here.
Again, drawable, raw, layout, values.
The defaults, if we go into Hello Android or Hello CS50 right now
it will look just like this.
It will say hello world.
As you can see right here with the Android text
the text for this text view, which is basically just a label,
is what we would call it in iOS.
It has this funny notation @string/hello_world.
This is so we can—we attempt to extract all of the strings,
all of the hard-coded strings in Android into a separate folder,
which happens to be in values.strings.
If we look here, we can see that we have a hard-coded string saved here
for hello world, and it's called hello world, and this is sort of a
common design decision across many platforms that you want to—
strings are the sort of things that we want to potentially be able to change.
We don't want to control F in our source code file in our XML.
We want to be able to change this whenever we get the chance.
>> This XML file, strings.xml, is a way of extracting
hard-coded strings that would otherwise be in our layout resources
or in our source code.
The Manifest is where we keep this essential information about the application.
It includes the package name. That has to be a unique identifier.
Unlike the App Store for iOS the names of the applications
don't have to be unique, and you can in fact change the name of your application
after you submit it, so if I start out with Angry Birds,
and then I make an update, and I don't want to release a new version
I guess I could call it Angry Birds 2 while I'm on the same release cycle.
It would just show up as an update.
The only thing that has to be unique is this package name,
which not many people will see.
Well, you'd only see if you were looking at the source code or if there is some sort of error.
The components include activities, so we have to declare
any sort of activity we use.
This is a permission sort of thing.
>> Because Android doesn't have this rigorous application process
for submitting apps instead they just do everything based off of permissions
and declaring things in the Manifest.
The SDK version is also important.
We can set use as SDK minimum version something.
Obviously, you want to create code
and design for the newer operating systems.
Perhaps not the newest, maybe not Jelly Bean.
Maybe you want to design primarily for Ice Cream Sandwich,
although they are pretty much the same in terms of design decisions
and the actual libraries and APIs.
But rather than have people
of the original Android version—like Donut way back when—
who still happen to be using that try to download your application and then say
it doesn't work on my phone you can set the minimum version
and have it be Gingerbread or Ice Cream Sandwich
or whatever you feel comfortable submitting.
And this is an example of the Manifest. We can look at the actual one in a bit.
>> Okay, we'll just go forward with the demo now.
This is the demo if you Google Android build your first app or something like that.
We'll go through everything that's going on in there,
and sorry, just for a reference who here knows Java to any extent?
Okay, so Java is new coding language for most people coming out of CS50.
Briefly, to go over again what it says here,
what we want to do is rather than adjust this hello world application
that all it does is it launches and it says hello world
and it says hello CS50 at the top because that's the activity name
we're going to attempt to make a text field and a button
so that when we press this button it will take the text
from the text field and launch a new activity, and it will say
whatever that text said in the activity, and this is relatively simple.
It's not very interesting. You wouldn't want to release any app like this.
But it demonstrates some important design things.
>> We'll have to interact with the Manifest, with the layout files,
with the source code, and you can see how to launch one activity from another.
We'll start with the layout for our first activity,
which I know it's kind of small,
but as you can see right now, all it is is it has our logo that we created,
the activity name, and it says hello world in the center.
Instead, I'm first going to make this into a linear layout,
a relative layout, and these are all things
you could look up and are worth going over at some point in terms of the layouts.
It's a lot like HTML.
We said it's not really worth knowing in terms of a programmatic sense,
but there are so many different layouts you can control,
and it's just like CSS in terms of styles.
>> There's a lot going on just in terms of the aesthetics here,
and yeah, it's worth learning, but it's the sort of thing you should look up
as you go and you feel like you need something new.
I can take advantage of some of the ADT tools here at least to start off with.
I'll make a text field, and I will make a button.
Put them right next to each other.
They already resize appropriately.
Sorry, again, coming back to the difference between linear layout and relative layout,
a linear layout gives a little more functionality
in terms of filling space and making sure
we position things horizontally or vertically.
The big difference between a linear layout and a relative layout
is the relative layout positions everything relative to other views,
and the good thing about it is that it takes less time to draw
because the operating system looks at all the code and says this goes
relative to this here, here.
It means it makes fewer measurements than a whole bunch of nested linear layouts,
which I would have to do if I wanted things to go vertically here.
>> I already have some things going horizontally, so I would need a different linear layout
to nest them vertically, but if I were doing a relative layout I could say
keep this to the left, this to the right and these things below.
But because I want them to fill right now I'm going to use a linear layout,
and you can see it already does a lot of these things for us.
All views need to have a property of width and height,
and this happens to have a weight of 1, and this has a weight of 1
so that it fills the entire space.
But the width and height are most important.
This ID field right here is not important within the actual layout
unless we're using a relative layout and saying we can reference
one view position in reference to another.
If we had a relative layout we could say position this below this one
or above this ID, but this ID will be important
when we're using it in our code because we can reference
these individual views in this way.
>> And then you can see the tag requestFocus, which is something you probably saw in pset 7.
There was an auto focus tag or something along those lines for one of the fields.
And one thing, of course, we can do just like in HTML,
and notice one of the nice things about ADT is that it autocompletes here.
Maybe not as nicely as it did in XCode, but it does nonetheless,
and we could say hint and then give it some sort of string
like write a message,
and if I give it a moment, also notice that I get a little error here
saying that we should use a string resource for this,
so if I let it do some of the hard work for me
I can select this string, do refractor Android and extract Android string.
I can give it that name, write a message,
and what it did now is it replaced that hard-coded string
with a reference to the string in the string's .xml file,
which means now this is here.
>> And I know that seems a little trivial and like extra work at this point,
but when you have a whole bunch of things, a whole bunch of strings,
that's really important, and particularly for localization
because as I mentioned earlier, Android is a very globally used operating system
that you can simply do values-en or values-sp
or something for English or Spanish or other languages.
And then you probably haven't had this experience yet
since we didn't do much JavaScript in terms of web programming,
but we can also do this field called onClick for the button,
and this is a way of referencing within our layout
that we want a certain function to be called in our source code.
I'm going to call this sendMessage,
and in order to make this work that means in the main activity here
I will have to create a function that is public
so that it can be accessed by the layout.
It's void because you just don't want it to return anything.
We'll call it sendMessage, and it takes a view,
which is a sort of context that we can anchor this method
to that individual view when we're running it.
>> And I don't know if you noticed—well, you wouldn't have noticed,
but at this point right here
this view is a type that has not yet been included,
and of course, you all know from CS50 about not including types.
The nice thing about IDE's like Eclipse is that
if you forget to include a type it will underline with a little red squiggly
and then give you the option to import the view.
A quick way of doing that is control shift O, and it will import
all the files that it needs to.
Now that we have this function sendMessage,
which is going to send message from the MainActivity to a new activity,
we're going to have to use an intent to launch the new activity from this one,
so we'll probably want to create a global constant or also particularly a public constant
that will help us know how we're going to reference the string
because when we create an intent we're not just calling a new activity,
but we can also give it a bundle of information.
A bundle is actually the term that Android uses,
and it's a way of saying give it extra data, which it can't be of a very sophisticated data type,
but we can definitely include booleans or strings or ints.
That sort of thing.
>> Feel free to ask about any of these qualifiers here,
public, final, static.
Public is the important one.
It means that we can access this variable from other source code files
such as when we create a new activity.
We can reference the string within this file.
If it's private, it means it's limited to this individual file here.
But we'll call this something like extra message.
Now we have made this function, and if we click the button, this function will be called.
But we haven't done anything, obviously, with the function.
What we want to do now is create a new activity,
the activity that will actually be launched.
In Eclipse we can say new, Android activity, blank activity.
We can give it a name.
Let's call it our result activity.
And then this hierarchical parent field is a way of specifying
how the activities are related to each other.
Because this one will be launched from the other activity
we should specify that it has the parent main activity.
>> And I could have clicked on the next field there, which would have told us
some optional fields that it was also including,
but the nice thing about ADT, again, is that if I scroll down here
in the Manifest remember that all of this really was included by default
when we originally created the project,
and now because we used this create a new activity rather than just
adding our own class file because we went through their GUI for doing this
it already added all of this to the Manifest for us,
which just means that now the operating system won't complain
when we try to launch this activity.
And it also, of course, gave it a label, which also shows up in strings.
It does a lot of things on the back end for us.
Anyway, now that we have this result activity as well,
the actual source code file in the source folder,
and you can see—to briefly touch on this—
because we told it about this hierarchical parent
it gave this field android.r.ide.home in this onOption selected thing.
>> What this is basically saying is there's a menu button now
that in the top left corner of the screen
if I go back to the PowerPoint where we first talked about action bar
because of the hierarchical parent now there's a little arrow back here
and this is clickable so we should be able to—after we actually run this app—
go back, and it's a way of saving us a little bit of code there.
Now within this—well, it seems to be complaining about that for a moment.
Let's comment that out.
Now, in order to actually interact with these 2 activities,
we have to create an intent which includes all of this data.
In sendMessage now I'm going to cruise through some bits of code
and explain that as I go.
An intent, as I said, is a way to launch one activity from another.
Intent is the type. We're creating a variable myIntent.
>> And this is actually an object, which is why we have to call new.
It's common Java usage there, which might take a little bit of getting used to.
This means we're using the activity or the class MainActivity,
and intent in that way takes the activity it's going from
and the activity it's going to, which we call ResultActivity,
and that is its own class.
Include that.
And then as I mentioned before, we gave that ID to the edit text field
and the text view, so in order to programmatically capture
the text that exists in the editText
we use this function called findViewByID,
which is similar to something that you'll use when trying to get fields from the DOM.
Perhaps David talks about this in lecture.
But it's just a way of getting those—that's why we tag these things with those fields.
Id.editText1.
It's already autocompleting for me there.
>> And then we'll also include—this editText now that we have the field
within our program, all that findViewByID did was basically
you could think of it as give us a reference to that editText.
Now we want to get the string or the message
within that editText which we can do by using the—
you could think of editText as a struct—
we call it an object in Java—with a whole bunch of different methods
or fields and attributes attached to it.
When I say editText. it gives me the chance to access
a method such as getText, which will get the current text
in that editText and then convert that explicitly
to a string, and we have saved the message.
Now we actually want to do something with that intent we created just moments ago.
I will put extra as it's called in the intent,
which, again, like I said before, this is a way of creating the bundle
with a whole bunch of data.
Extra message is our tag so we know what we're saving this under,
and then I'm including the message.
>> And then we can actually start the activity by giving it the parameter myIntent.
And this will actually launch the activity, so now since I upgraded to Windows 8
there might be some errors that show up briefly, but try to ignore them.
And this is the Android emulator.
Hopefully the code will actually pop up in a moment.
Again, ignoring all those little things.
But the Android emulator you can emulate any version of the operating system
from the earliest ones, Donut, Gingerbread.
This is Jelly Bean 4.1.
But as you can see right now, this is something we made.
This has the MainActivity, the editText, the button.
I can type something here, but what are we missing at this point?
We made the field in the MainActivity that's going to send the message
to the other activity, but at this point
we haven't done anything in the other activity, so it's not going to receive anything.
Let's finish up that part before we move on.
>> This result activity, what we'll need to do is we'll need to do is we'll need to—
we can also reference the intent within this activity,
so we have to capture the intent, which is really simple.
It's a function included in the activity class,
so we can just say "Get the message from the intent."
"Intent myIntent = getIntent."
And this will give us—now myIntent is an object,
which is a reference to the intent that led us to this activity.
MainActivity calls and gives extra information to result activity.
Result activity now looks at the intent that led it here,
and we can access the message that we created in the other one,
getStringExtra, and this will autocomplete for me.
And then remember, the way we tagged that bit of data
was by giving it this field right here, this public string,
which is the tag for the string we actually included.
>> If I say MainActivity.Extra_Message
it's right there, and this is sort of like the parameter name
when we passed code from the controller to the template,
when we'd say title arrow something.
It's the same sort of idea there.
Now, remember this.
We also had this auto created or auto generated code
for result activity, which includes the text view in the middle
that says hello world.
We could potentially make that bigger.
Let's do that first.
We could make it 40 density independent pixels.
Let's see, that's super huge. That will be okay.
And then in order to reference this individual text view within our code
we'll need to give it an ID,
and in order to do that we say @+id, which means we assign it ID.
If we just said @id it would assume we're referencing an ID that already exists,
and let's call this our resultTextView.
And notice that in XML there's no need for semicolons or anything.
Everything is within these tags.
It's very similar to HTML in a lot of senses.
>> It takes a little bit of getting used to, but eventually you'll feel pretty comfortable with it.
Let's update the text for our result text view,
and as we did when we were getting that edit text field in our other activity
in MainActivity here we will also likewise—
we'll find the view by the ID.
And R, in case I didn't mention this before, is the reference to our resources folder,
and then ID is a reference to everything in the resources folder, all the IDs,
and resultTextView.
And just as before, resultTextView is an object,
which means it has all these properties associated with it.
When we use getText for the edit text for this text field or the text view
we can actually use setText,
and then we already found the message from the intent,
so I can say message, and this will actually set the message.
>> It take a moment to launch, and then we can see whether or not it crashes,
but any questions about that process right there, that sort of interaction?
In many ways it's straightforward.
The reason I'm going through something relatively simple
is, again, because you get to see the interaction between the layout,
the source code, how you reference things
and maybe get a little exposure to how Java works there.
If I actually type something in here, like ohai, and then I click the button,
it launches a new activity, and that text view says ohai.
That's very simple, but hopefully after that example
you sort of see how this interaction works, and now that mess of files
on the left side for all these project folders, hopefully you know where to look now.
This is your source code area.
>> Layout is really the only thing you'll deal with until you include images
and the drawables or whatever, and values, that will include strings,
as we mentioned, and then styles is something that's sort of like CSS.
Address it when you want, but until you feel comfortable with adding extra flair
to your application there's no need to worry about it too much.
Just to wrap up one other thing you will definitely want to include—
assuming you want to integrate cool features and save yourself some extra coding—
would be to include 3rd party libraries.
Here's the little Android guy with the Sherlock Holmes hat.
This is an action bar Sherlock library,
which basically means that action bar you saw earlier,
which is now standard in Ice Cream Sandwich and Jelly Bean,
if you want to bring that sort of user experience to users on older versions
and save yourself from worrying about how the user is going to navigate
on older versions when that thing isn't there you can include this library
and then you just have to reference—rather than the default Android
libraries for the action bar, you reference this support library.
>> Things like Scoreloop, it's great if you're going to include a game.
It lets you add leader boards and achievements to games.
Admob is a way of putting ads into your applications
in case you want to make a little bit of money off of it.
Of course, there is Facebook and Twitter for integrating there
if you want to share things easily, et cetera.
Dropbox, likewise, and Google Analytics is that chart looking one there.
That will be very important if you actually want to see who is interacting
with your app or who it is, how they interact, et cetera.
Google, by default, tells you a lot of statistics about who has installed your app
and what phones they have, what operating system versions they have.
But if you want to see who is using it on a daily basis and how they use it
then you'll want to include some sort of tracking system like that.
>> When you're ready to distribute your app
I don't need to go into that in too much depth.
Click on the link here, Google Play.
It used to be the Android market.
They rebranded everything with Google Play,
so now you submit to that.
It's very straightforward.
You have to include a description, some screenshots.
Like I said, there's no approval process like iOS.
And where to go from here?
I showed you a really simple example.
Hopefully if it seems terribly simple
then that's probably a good sign.
If you at all felt a little bit confused or unsure about exactly what I was typing
that's also fine, but from here go to Google Guides.
This is a great place to start.
It will talk you through what they expect in terms of the application design,
how the users normally interact with it.
It's much more free form than iOS, I'd say,
which it seems like table views are—I don't know, that's their bread and butter.
Everything is a table view sliding up and down.
With Android they definitely encourage people to look at it from
a whole bunch of different perspectives.
>> When you include the software development kit in this ADT
by default you have a whole bunch of sample projects in Android.
Right here, Android, Android Sample Project.
If I click on that, then I can choose a version for which of the sample projects apply.
There's a whole bunch of different things here.
It starts off with action bar compatibility,
accelerometer play, backup and restore, Bluetooth, gesture builder.
JetBoy is a sample game they give you, as is LunarLander.
There are a whole bunch of sample applications here,
and they're all targeted at different aspects of Android's API,
and the idea is that as you make your application
you don't need to learn everything about Android to make an Android app.
You only have to learn about the parts that you're actually going to use.
Look at these sample libraries.
Feel free to copy and paste the code and reapply it.
It's a great thing to look at more difficult code
and try to understand it, which is of course why in CS50
we often give you large amounts of source code.
Look at some of these if you're going to use similar libraries
and then apply it to your own code.
And of course, there are tutorials.
Search for tutorials.
I found a lot of good ones online which can bring you up to speed
with what fragments really are and how you can use them.
>> Some of these new design things, like fragments,
you really don't have to be worried about unless you're making a
pretty large in scope project.
They are things that Google is trying to phase in.
Stackoverflow is of course your friend.
Hopefully I sold you a bit on Android,
realizing it's much more easy to approach in terms of just the coding language.
Java is I'd say much easier to understand than Objective-C.
Android is growing I think much more than iOS.
I mean, the data is there too, aside from what I think.
It's going to be around for a while,
and they are a few years behind in terms of their design cycles,
so it's sort of understandable that they're still working through some of these
consistency questions, like this action bar is a new thing for them still,
sort of creating similar user experience across all their apps.
Hopefully you can go forward now and open up Eclipse
and make your own Android apps.
>> Does anyone have any questions before we wrap up about anything?
I can tell you the answer is 42.
Well, happy coding everyone, and good luck.
[CS50.TV]